Herramientas para el análisis del código legado

El código legado, legacy o heredado solía definirse como cualquier código que corresponde mantener a alguien que no lo escribió originalmente. En la actualidad, no son muchas las aplicaciones a medida que se escapen a esta definición. Sucede incluso con las aplicaciones desarrolladas por la propia compañía, o mantenidas por la que hizo el desarrollo original. En estas últimas, las personas que crearon el código fuente están inmersas en otros proyectos.

Posiblemente, una definición más cercana al concepto original es que el código legado es aquel que resulta difícil de modificar porque su funcionamiento es desconocido. Esto incluye una diversidad de casos pero, en general, es código sin documentar o pobremente documentado. Tampoco suele contar con test unitarios. Y en muchas ocasiones, no sigue las pautas de diseño más extendidas en la actualidad.

Para poder llevar a cabo este mantenimiento, es preciso analizar antes el código. Salvo para llevar a cabo cambios muy simples, conocer la arquitectura, la imbricación de sus componentes y las limitaciones de estos, es fundamental para poder prever las implicaciones de un cambio determinado. Este tipo de aplicaciones, además, suelen ser monolíticas, lo que complica conocer el alcance de un cambio.

Antes de empezar a analizar el código legado

Hay algunos requisitos previos a tener en cuenta antes de comenzar el análisis. El primero de ellos es entender qué objetivos se pretende conseguir. No es lo mismo analizar la aplicación en un proyecto a medio plazo para reemplazarla que hacerlo para llevar a cabo tareas de mantenimiento. Tampoco es lo mismo que la puesta al día de una aplicación que se desea que siga operativa a largo plazo.

En todo caso, será imprescindible recopilar la información disponible: tanto documentación técnica como manuales de usuario, documentación de requisitos iniciales y de las modificaciones que ha sufrido la aplicación. Esta puede aportar una visión histórica de la vida del software y explicar por qué se han tomado determinadas decisiones.

En relación con esto, es importante tener en cuenta que, en caso de existir repositorios, interesa conservar todas las versiones del código. También ver cómo se ha modificado para dar respuesta a determinadas necesidades que no estaban contempladas inicialmente.

También será necesaria una copia de la base de datos, total o parcial, que permita entender el sistema en funcionamiento. En muchos casos, partes de la aplicación especialmente complejas o que se esperaba que tuviesen más importancia apenas son utilizadas. En caso de que el proyecto persiga sustituir el código legado por una nueva aplicación, es probable que gran parte de esa complejidad desaparezca.

Un caso típico de esto último son las agendas integradas en muchas aplicaciones heredadas. Agendas hechas a medida de los datos contenidos que han dejado de utilizarse por resultar más prácticas las incorporadas en las soluciones ofimáticas y los clientes de email. En estos casos, deshacerse del código que ya no se utiliza y proyectar conectores que permitan disponer de la información en la nueva aplicación puede ser sencillo y reducir los costes de mantenimiento.

Cómo analizar una aplicación de código legado

Pero ¿cómo estudiar una aplicación con miles y miles de líneas de código? El tiempo necesario para hacerlo de forma artesanal exige dedicar muchos recursos y tiempo a ello. Generalmente esta tarea se aborda porque se trata de una aplicación en uso sobre la que es necesario llevar a cabo modificaciones en el corto plazo, por lo que no se trata de una estrategia viable.

Para ello, existe una diversidad de herramientas que nos permitirán tener una buena idea del estado del código legado y ayudarnos a abordar un proyecto de transformación de este en plazos viables y evitando muchas, aunque no todas, de las posibles sorpresas que un proyecto de estas características puede deparar.

Lo primero que deberemos utilizar es una herramienta de análisis estático de código. Entre ellas, algunas de las más populares son Helix QAC (para aplicaciones C y C++) o Klocwork (que añade a estos dos lenguajes C# y Java). Hay herramientas disponibles para la mayoría de los lenguajes, por lo que deberemos utilizar la que más se ajuste al software a analizar.

Estas aplicaciones nos darán información sobre el software a diferentes niveles: a nivel unitario, nos informarán del funcionamiento de partes del código aislado del resto del mundo: datos, benchmarks, sistema… es un análisis básico, pero necesario y que nos puede dar una buena idea de la arquitectura general del código legado.

A nivel de tecnología, se pueden analizar las interacciones entre estas partes del código para detectar potenciales errores. Por ejemplo, un método que pueda generar una salida que entrega a una instancia de otra clase que pueda producir un error. En esos casos, será necesario adaptar la clase para que haga las validaciones oportunas, o incluso derivarla para procesar los datos en ese caso específico.

Análisis a nivel de sistema

A nivel de sistema, se incorporan otras unidades como el entorno, bases de datos, etc. En este punto se pueden utilizar herramientas que no analizan tanto el código como el funcionamiento de este en determinadas tareas: así, es posible detectar componentes del software que generan un número elevado e innecesario de peticiones a una base de datos.

De esta manera se ralentiza la aplicación de código legado. Pueden mejorarse optimizando y racionalizando las consultas. Incluso pueden resolverse problemas de rendimiento o seguridad incorporando nuevos elementos de forma más o menos transparente. Entre ellos, cachés en bases de datos en memoria o sistemas de autenticación basados en tokens.