La vuelta de las vacaciones del verano nos permite reanudar esta serie de posts sobre el uso de SonarQube con aplicaciones de tipo Legacy, en este caso la primera versión de Word publicado por Microsoft en 1990.

Nos planteamos la siguiente hipótesis: Microsoft acaba de ser comprada y su nuevo propietario le pide, como consultor de calidad, recomendar una estrategia para esta versión de Word.

No creas que esto nunca sucede: empresas de software cambian de manos todos los días, y la I+D y el código del software están en el corazón de esas adquisiciones.

En concreto, es necesario responder a las siguientes tres preguntas:

• ¿Cuál es el coste de transferir la aplicación a un nuevo equipo de I+D? Esta es la pregunta que surge cada vez que se quiere externalizar una aplicación Legacy a una empresa de servicios.
•  ¿Cuánto le costaría a refactorizar la aplicación para mejorar la calidad y reducir los costes de mantenimiento? Cualquier software Legacy se caracteriza por su deuda técnica elevada. Un refactoring reduciría los intereses de esta deuda, y por lo tanto los costes de la transferencia de conocimientos a un proveedor externo y / o los costes de mantenimiento.
• ¿Cuál sería el coste de reingeniería de esta aplicación? Refactoring a menudo significa replantear el diseño o la arquitectura de la aplicación. ¿Por qué no aprovechar esta oportunidad para hacer una migración a otro lenguaje, más reciente, menos difícil de mantener?

Obviamente, no sólo debes tratar de responder a estas tres preguntas, pero también proponer un plan de acción para cada una de estas estrategias.

En posts anteriores, hemos visto cómo analizar este código Legacy con SonarQube y los resultados obtenidos en términos de métricas – tamaño (LOC), complejidad (CC), comentarios y duplicaciones, así como varios defectos Blocker, Critical, Major et Minor.

También se verificó la existencia de componentes ‘monstruos’: funciones y programas grandes y complejos, con un alto número de violaciónes de las buenas prácticas de programación, particularmente en términos de legibilidad y comprensión del código.

Código Legacy

¿Qué es código Legacy ?

Originalmente, es una aplicación heredada de una generación anterior de programadores,  desarrollada en un lenguaje de una generación anterior y que se ejecuta en una plataforma (hardware, sistema operativo, …) también vieja o no más soportada. Se refería a código Cobol Mainframe principalmente.

Hoy en día, las generaciones de programadores más jóvenes utilizan esta expresión más a menudo para aplicaciones antiguas (más de 5 a 10 años) y / o sin interfaz web y / o escrita en lenguajes no orientados a objeto (C, Forms, PowerBuilder, Visual Basic, etc.)

En todos los casos, el término ‘Legacy’ evoca un código difícil de entender, con una deuda técnica grande y escasa y anticuada documentación .

Modificar y Rezar

De acuerdo con Michael Feathers, autor famoso de un libro muy recomendado – «Working Effectively with Legacy Code» – el código Legacy se caracteriza por la ausencia de pruebas.

En el capítulo ‘2 – Working with Feedback’ de su libro, describe un proceso muy común, especialmente en los departamentos de I+D de las empresas de software: «Modificar y Rezar» (para que sigue funcionando). Cuando tiene que realizar una evolución, el desarrollador planifica cuidadosamente su trabajo, primero se asegura de que entiende completamente el código que modificar y los posibles impactos, el implementa los cambios, compila y luego comprueba que funciona correctamente, y realiza algunas pruebas adicionales aquí y allá en las áreas potencialmente afectadas para asegurarse de que no se ha roto nada. Luego trasladará su evolución a un equipo de testers que realizarán una serie de pruebas de regresión y otras pruebas más o menos automatizadas, para garantizar el comportamiento correcto de la aplicación.

En el mejor de los casos, estas pruebas se realizarán durante la noche, y los desarrolladores conocerán los resultados al día siguiente, así que si el código es válido, o al menos validado. En la mayoría de los casos, todos los cambios de la semana se pondrán a prueba en el fin de la semana, con un poco de prueba manual adicional, y la validación del código nuevo sólo se realizará la semana siguiente.

Otra práctica que sigue siendo común hoy en día entre los proveedores de software es definir:

• una fecha de lanzamiento de una nueva versión del software, por ejemplo, el 15 de octubre;
• un período de desarrollo en el que se implementan los cambios, por ejemplo, hasta el 20 de septiembre;
• un período de control de calidad (entre el 20/09 y el 15/10) durante el cual todas las solicitudes de cambio se congelan, la nueva versión va a las manos del equipo de QA, ningún nuevo desarrollo se pone en marcha y los desarrolladores se dedican exclusivamente a la corrección de los problemas descubiertos por QA.

Encubrir y Modificar

Otra forma de trabajar según Michael Feathers es realizar una cobertura de pruebas unitarias para proteger nuestro código de las consecuencias de los cambios, como una red de seguridad. ¿Cuáles son los beneficios de una buena cobertura de pruebas?

• Tienes una serie de pruebas que se ejecutan cada vez que realizas un cambio, con éxito la mayoría de las veces. A veces te equivocas, por ejemplo cambiando la lógica de una condición, y una o más de las pruebas fallan. Corriges el error en un minuto: el feedback es instantáneo, sin necesidad de esperar hasta mañana, la semana o la fecha de la fase de control de calidad para ver si los cambios realizados en el código han introducido un bug o una regresión.
• Debes cambiar este método o una función muy grande y compleja. Esta es una oportunidad para hacer una refactorización y hacer un ‘split’ (dividir) este método en varios otros más simples. Pero temes que un cambio rompa lo que funcionó antes. «No lo arregles si no está roto» se dice a menudo (“Don’t fix it if it ain’t broke”): que es por desgracia la mejor manera de desarrollar nuevo código Legacy encima del código Legacy existente. Si tienes pruebas unitarias, no solamente tú mismo pero también todo el equipo tendran una mayor confianza en los cambios. Puedes mejorar el código existente como evitar la inflación de la deuda técnica, y sobre todo trabajar con la agradable sensación de desarrollar código de calidad en lugar de añadir nuevo peso a la carga ya bastante pesada sobre tus hombros.
• Realizas algunas nuevas pruebas unitarias para cubrir tu desarrollo y probarlo. Cualquier modificación futura que haría un otro miembro de tu equipo será más fácil, más rápida y más segura.

Contrariamente a lo que pudiera pensarse, el desarrollo de las pruebas unitarias no significa el doble de trabajo o desarrollar más lentamente. El código para estas pruebas suele ser muy sencilla, y si representa una carga de trabajo adicional, en realidad no es tan importante en comparación con los beneficios. También es una práctica cada vez más común, hasta el punto de que la ausencia de pruebas se considera uno de los siete pecados capitales del desarrollo.

De todos modos, la escritura de código no es el coste más importante: un desarrollador pasa más tiempo tratando de entender el código que tiene que cambiar en lugar de desarrollar este cambio. De hecho, ni siquiera se puede estimar el tiempo requerido para implementar un cambio si ya no conoces el código existente y lo que hace.

La razón por qué la legibilidad y la comprensibilidad del código son una de las fuentes más importantes de los altos costes de mantenimiento es el hecho de que el tiempo dedicado a la programación es insignificante en comparación con el tiempo necesario para entender lo que el código hace y cómo implementar los cambios sin introducir un defecto.
Pero si ya tiene las pruebas unitarias, usualmente muy simples, muy legibles, puedes reducir enormemente estas cargas.

Pero ¿qué pasa en nuestro caso, cuando nuestra aplicación Legacy ya no tiene esas pruebas unitarias? Esto es lo que veremos en el próximo post.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.