Plan de refactorización de código legado
Genera un plan por fases para refactorizar código legado sin romper funcionalidad existente, priorizando siempre la seguridad ante regresiones por encima de la velocidad del cambio.
Actúa como arquitecto de software con experiencia modernizando sistemas legados. Analiza el siguiente código legado y propón un plan de refactorización en 3-4 fases, priorizando reducir riesgo de romper funcionalidad existente por encima de la elegancia del resultado final. Para cada fase indica: qué cambiar, por qué es necesario ese cambio, qué tests deberían existir antes de tocar ese código, y una estrategia de rollback si algo sale mal tras el despliegue. Código o descripción del módulo: [PEGA AQUÍ EL CÓDIGO O DESCRIPCIÓN]
Caso de uso
Arquitectura de software
Refactorizar código legado sin un plan suele terminar en un cambio a medias que rompe algo en producción. Este prompt fuerza a pensar primero en tests de seguridad antes que en el cambio en sí, siguiendo el principio de no refactorices lo que no puedes verificar.
Por qué funciona esta estructura
La técnica central es invertir el orden natural en que la mayoría de desarrolladores aborda la refactorización: en vez de empezar por el código a cambiar, el plan empieza por la red de seguridad (tests) necesaria antes de tocar nada. Pedir también una estrategia de rollback por fase reconoce una realidad incómoda: incluso con buena planificación, algunos cambios en sistemas legados fallan de formas inesperadas, y tener un plan B reduce drásticamente el coste de ese fallo.
Antes vs. después
Antes: pedir refactoriza este módulo de facturación suele devolver una versión reescrita y más limpia del código, sin ninguna consideración de cómo migrar de forma segura ni qué tests deberían existir antes del cambio.
Después: con la estructura por fases, el plan empieza identificando que el módulo no tiene tests, por lo que la fase 1 consiste en escribir tests de caracterización que capturen el comportamiento actual (incluyendo casos raros como facturas con descuento del 100%), y solo en la fase 2 se aborda la refactorización real, con cada cambio validado contra esos tests antes de avanzar.
Variaciones útiles
- Para sistemas con alta criticidad (pagos, salud): añade una fase de despliegue gradual con feature flags que permita activar el código nuevo solo para un porcentaje pequeño de tráfico inicialmente.
- Para equipos con poco tiempo asignado a deuda técnica: pide que el plan incluya una versión mínima de fase 1 que se pueda completar en menos de una semana, en vez de un plan completo de varios meses.
- Para código sin documentación de negocio: pide que el plan incluya explícitamente una fase de entrevistas con quien conozca el contexto de negocio antes de tocar la lógica.
Qué IA usar
Claude tiene ventaja en este tipo de planificación arquitectónica compleja gracias a su capacidad de mantener mucho contexto de código y razonar sobre dependencias entre módulos. ChatGPT es una alternativa muy sólida, especialmente si necesitas iterar rápido generando distintas variantes del plan para comparar enfoques.
Publicidad
Conclusión
La fase más importante de cualquier plan de refactorización no es el cambio de código en sí, sino asegurar que existen tests que detecten si algo se rompió. Un plan de refactorización sin estrategia de rollback es una apuesta, no un plan de ingeniería serio.
Preguntas frecuentes
Explora más prompts en Programación y código o revisa nuestras guías de prompt engineering.
Prompts relacionados
Revisor de código con buenas prácticas
PremiumPide una revisión de código detallada señalando bugs, riesgos y mejoras de legibilidad. Funciona como un segundo par de ojos disponible en cualquier momento, útil tanto para revisiones rápidas como para preparar código antes de un pull request.
Generador de tests unitarios
Genera casos de prueba unitarios para una función, incluyendo casos límite habitualmente olvidados como valores nulos, vacíos o extremos que el camino feliz suele pasar por alto.
Documentación de función de código
Genera documentación clara (docstring/JSDoc) para una función a partir de su código, incluyendo parámetros, tipo de retorno y un ejemplo de uso listo para copiar.