Entender y modernizar codebases antiguas con IA

El legacy code sin tests no se puede reescribir sin más. Los characterization tests y los pasos pequeños hacen segura la modernización con ayuda de IA.

Qué hace especial al legacy code

El desarrollador de software Michael Feathers definió una vez el legacy code, de forma escueta, como "código sin tests". Precisamente eso es lo que lo hace peligroso de modificar: nadie, ni siquiera un agente de IA, puede comprobar si un cambio rompe el comportamiento cuando no hay tests que lo registren.

Primer paso: registrar el comportamiento, no mejorarlo

Antes de reestructurar nada, necesitas characterization tests. Son tests que anotan lo que el código hace AHORA MISMO, aunque parezca extraño o incluso erróneo. No son un juicio de calidad, sino una instantánea que protege los cambios posteriores.

Segundo paso: migrar de forma gradual

Reescribir todo desde cero es arriesgado: hasta que la nueva versión esté lista, nada funciona de forma fiable, y a menudo se pierde comportamiento antiguo sutil. La migración gradual es el enfoque más probado, un patrón conocido como "strangler fig": las partes nuevas crecen poco a poco alrededor del código antiguo, hasta que este último se puede apagar por completo.

Para qué son especialmente útiles los agentes de IA aquí

Un agente puede resumir rápidamente módulos grandes y sin documentar, y proponer posibles characterization tests, un trabajo que sin documentación suele costar mucho esfuerzo. Lo importante sigue siendo: primero entender y proteger, solo después cambiar.

EJEMPLO

Prompt: 'Este módulo de 1.800 líneas no tiene tests ni documentación. Primero resume qué hace a nivel funcional. Después escribe characterization tests para las cinco funciones más importantes que registren el comportamiento ACTUAL, aunque parezca extraño. Todavía no cambies nada de código.'

🛠️ EJERCICIO — PRUÉBALO TÚ

Toma un módulo sin tests y desordenado de tu propio proyecto (o de un proyecto open source) y protégelo con characterization tests antes de cambiar nada.

Haz que el agente resuma primero qué hace el módulo a nivel funcional, sin cambiar código.
Identifica junto con el agente entre 3 y 5 entradas o llamadas típicas y haz que escriba tests que registren las salidas actuales como valor esperado.
Solo después: haz un primer cambio pequeño y aislado, y comprueba si los characterization tests siguen en verde.

✅ AUTOEVALUACIÓN

☐ ¿Los tests cubren los caminos más importantes, no solo el caso más simple?
☐ ¿Registraste conscientemente el comportamiento ACTUAL, en vez de ya 'mejorarlo' al escribir los tests?
☐ ¿Sigue todo en verde después del primer cambio, o un test en rojo muestra exactamente qué cambió?

QUIZ RÁPIDO

¿Qué es un characterization test?