El código legado solía definirse como el código que corresponde mantener a alguien que no lo escribió. Hoy esa definición se queda corta: pasa incluso con aplicaciones desarrolladas por la propia compañía, cuando quienes escribieron el código original ya están en otros proyectos. Una definición más útil es esta: código legado es aquel que resulta difícil de modificar porque su funcionamiento es desconocido, casi siempre por falta de documentación y de tests. Antes de tocar una sola línea, hay que analizarlo. Este artículo repasa qué preparar antes de empezar y qué herramientas de análisis de código legado ayudan a hacerlo en plazos razonables.
El código legado no es solo el código viejo: es el código que resulta difícil de modificar porque nadie entiende del todo cómo funciona. Suele estar sin documentar o mal documentado, casi nunca tiene tests unitarios, y muchas veces no sigue ninguna pauta de diseño reconocible hoy.
Para hacer cambios que no sean triviales, hace falta entender antes la arquitectura, cómo se relacionan sus componentes y qué limitaciones tiene cada uno. Estas aplicaciones además suelen ser monolíticas, lo que complica todavía más saber hasta dónde llega el alcance real de un cambio.
Hay algunos requisitos previos que conviene resolver antes de empezar el análisis. El primero es tener claro el objetivo: no es lo mismo analizar una aplicación para reemplazarla a medio plazo que hacerlo para mantenerla, o para ponerla al día y que siga operativa mucho tiempo.
Un caso típico: agendas hechas a medida dentro de aplicaciones heredadas que ya nadie usa porque los clientes de email y las suites ofimáticas hacen ese trabajo mejor. Detectar ese código muerto y sustituirlo por conectores sencillos reduce el coste de mantenimiento sin apenas esfuerzo.
¿Cómo analizar una aplicación con cientos de miles de líneas de código? Hacerlo a mano exige recursos y tiempo que casi nunca sobran, sobre todo si la aplicación sigue en uso y hay que modificarla a corto plazo. Aquí es donde entran las herramientas de análisis estático de código, como Helix QAC para C y C++, o Klocwork, que además cubre C# y Java. Hay opciones para casi cualquier lenguaje: la clave es elegir la que encaje con el software que vas a analizar.
Además, hoy la IA generativa ha cambiado este escenario al facilitar la comprensión del software, generar documentación, responder preguntas sobre el código e incluso identificar patrones y posibles problemas en cuestión de minutos. Sin embargo, la IA no sustituye al análisis estático, las herramientas de análisis estático siguen siendo un complemento imprescindible.
A nivel unitario, estas herramientas informan sobre el funcionamiento de partes del código aisladas del resto: datos, benchmarks, comportamiento del sistema. Es un análisis básico, pero necesario, y da una primera idea sólida de la arquitectura general.
A nivel de tecnología, permiten analizar las interacciones entre esas partes para detectar errores potenciales, como un método que entrega una salida que puede hacer fallar a otra clase. En esos casos hace falta adaptar la clase para que valide los datos, o derivarla para tratar ese caso concreto.
A nivel de sistema entran en juego otras piezas: el entorno, la base de datos, la infraestructura completa. Aquí las herramientas ya no analizan tanto el código como su comportamiento en tareas concretas, y permiten detectar, por ejemplo, componentes que generan un número innecesario de peticiones a la base de datos y ralentizan toda la aplicación.
Para este tipo de análisis se suele recurrir a herramientas de profiling o benchmarking generales, que estudian el uso de la base de datos, los recursos del sistema operativo y el acceso a la red.
Es el código que resulta difícil de modificar porque su funcionamiento es desconocido. Casi siempre está sin documentar, sin tests unitarios y sin seguir las pautas de diseño actuales, independientemente de su antigüedad.
¿Por dónde hay que empezar antes de analizar código legado?Por definir el objetivo del análisis: si es para mantenimiento, para sustitución o para poner al día la aplicación. Después toca recopilar documentación, conservar el historial del repositorio y conseguir una copia realista de la base de datos.
¿Qué herramientas de análisis estático de código se usan más?Actualmente, el análisis de código combina dos enfoques complementarios. Por un lado, la IA generativa facilita la comprensión del software, la generación de documentación y la exploración rápida de grandes bases de código. Por otro, las herramientas de análisis estático siguen siendo imprescindibles cuando se necesita obtener información precisa, verificable y determinista sobre el comportamiento del código.
Entre las herramientas de análisis estático más utilizadas se encuentran Helix QAC para C y C++, y Klocwork, que además soporta C# y Java. Existen soluciones equivalentes para la mayoría de lenguajes; lo importante es seleccionar la que mejor se adapte a la tecnología de la aplicación que se va a analizar.
¿Qué diferencia hay entre el análisis a nivel unitario y a nivel de tecnología?El análisis a nivel unitario estudia partes del código de forma aislada: datos, benchmarks, comportamiento. El análisis a nivel de tecnología va un paso más allá y estudia cómo interactúan esas partes entre sí para detectar errores que solo aparecen en esa interacción.
¿Qué se analiza a nivel de sistema en una aplicación legacy?El entorno completo: base de datos, infraestructura, patrones de acceso. Permite detectar, por ejemplo, componentes que generan peticiones innecesarias a la base de datos y ralentizan toda la aplicación.
¿Es igual analizar código legado para mantenerlo que para migrarlo?No. Si el objetivo es mantenerlo, el análisis se centra en entender riesgos y dependencias. Si el objetivo es migrarlo o sustituirlo, buena parte de la complejidad detectada puede acabar descartándose junto con el código que ya no se necesita en el sistema nuevo.