Durante el Global Software Architecture Summit en Barcelona, se habló sobre el “Legacy Code” y pudimos ver que existen muchas opiniones sobre el mismo. En vistas a esto, he decidido hacer un poco de investigación, leyendo libros sobre el tema y hablando con nuestro equipo de desarrollo para ver qué es exactamente y cuales son los acercamientos más comunes y adecuados para trabajar con Legacy Code.

Debo decir que durante esta investigación he visto varios programadores llamando “legacy code” al código que se encuentran cuando se unen a un proyecto, y el cual no les gusta. ¿Pero es correcto llamar a esto “legacy code”? En nuestra opinión, no. Si te unes a un proyecto con una base de código de 15 años de antigüedad que aún hace lo que se le pide y está libre de bugs, no la reescribas, nútrela. A los usuarios no les importa la antigüedad del código, les importa el software que funciona.

Un problema común de los desarrolladores de software es que siempre quieren reescribirlo todo, viviendo en un estado constante de sentir que su código se podría mejorar dramáticamente. ¿Pero recordáis esta famosa cita? “Es más difícil leer código que escribirlo”.

 

Así pues, cuales son las definiciones más comunes de Legacy Code:

  1. Todo el código es Legacy Code
  2. Código que no gusta a los desarrolladores
  3. Código que los desarrolladores no entienden por falta de documentación
  4. Código que los desarrolladores heredan
  5. Código construído usando prácticas y plataformas obsoletas
  6. Código sin tests unitarios
  7. Código que es muy arriesgado cambiar

En su libro “Working Effectively with Legacy Code”, Michael Feathers define el legacy code como código sin tests. ¡Y estamos totalmente de acuerdo con él!

Cierto es que las bases de código legacy están con frecuencia estrechamente acopladas, son excesivamente complejas y no se crearon con la idea moderna de buenos principios de diseño en mente. Ya sea porque los desarrolladores están trabajando con un legacy code que han heredado o uno que escribieron ellos mismos hace tiempo, seguramente hayan experimentado el dolor derivado de intentar cambiar un sistema grande y complejo que sufre de deuda técnica y no cuenta con la red de seguridad que te proporcionan los tests.


No puedes mejorar la base de código legacy de la noche a la mañana, pero puedes ir dando pasos para mejorarlo:

 

1. Testéalo
Una forma de comprender el código es crear tests unitarios y de caracterización.
Esto te ayudará a entender qué hace realmente el código, y te mostrará las zonas potencialmente problemáticas. Una vez entiendas el código, podrás hacer cambios con más confianza.

 

2. Repasar la Documentación
Repasar la documentación de los requerimientos originales te ayudará a entenderlos. Sin esta información, podrías provocar cambios de forma accidental que introduzcan comportamientos no deseados.

 

3. Reescribir el código solo cuando sea necesario
Lleva mucho tiempo y no siempre es necesario. Hazlo solo cuando sea la única opción.

 

4. Refactor
Es mejor hacer refactor del legacy code que reescribirlo. Y es mejor hacerlo de forma gradual. Pero recuerda hacer refactor del código que tenga tests unitarios, así sabes lo que tienes. Y haz tests tras cada refactoring para asegurarte que no se ha roto nada. Trabaja con una red de seguridad – integración continua, para poder volver a una build previa en caso de necesidad.

 

5. Haz cambios en distintos review cycles
No hagas demasiados cambios de golpe. Es una mala idea hacer refactor en el mismo review cycle en el que haces cambios funcionales.

 

6. Mantén el código limpio
Asegúrate de que el código que añades es limpio usando buenas prácticas y el principio DRY.

 

Libros de Legacy Code que te recomendamos


Si crees que tu código es “Legacy Code”, entonces te recomiendo leer estos libros, que seguro te ayudarán en tu vida diaria:

1. “Working Effectively With Legacy Code” por Michael C. Feathers, que contiene buenos ejemplos sobre cómo realizar cambios en la base de código.

2. “Refactoring: Improving the Design of Existing Code” por Martin Fowler. Este libro ofrece muchos consejos para hacer un refactoring efectivo.

Alvaro Garcia – nuestro Principal Engineer da su curso sobre Legacy Code en Apium Academy, si te interesa, haz click aquí