Código Legacy – Razones por las que cambiar el software

– Post escrito por María Morales (@MaMoralesMC) y Noemí Navarro (@nnsanchez92).

Como sabéis, nos gusta compartir con vosotros los libros que leemos y las cosas que consideramos importante de ellos y recomendarlo y en esta ocasión os queremos contar sobre el libro Working Effectively with Legacy Code de Michael Feathers.
En primer lugar, el término Código Legacy se utiliza para referirnos a aplicaciones antiguas, como por ejemplo el famoso Cobol sobre todo utilizado por los bancos o Fortran. Actualmente el término se utiliza también para referirnos aplicaciones que están desarrolladas en un lenguaje que es difícil de entender y que genera deuda técnica, o incluso para hablar de código heredado. Podéis leer más definiciones aquí.
El término fue utilizado por primera vez por el informático George Olivetti para describir el código mantenido por un administrador que no desarrolló el código. El término también puede significar código antiguo que necesitamos insertarlo en un código actual, más modernos con el fin de mantener esa parte, ya que la necesitamos, y no queremos perderla.
Michael Feathers define Codigo Legacy como “Legacy Code is code without test”. El principal problema con el código heredado es que no tiene pruebas y al no tener pruebas, no está diseñado para ser testeable, por lo que es muy difícil, por ejemplo aislar partes del código para hacer pruebas unitarias entonces es necesario refactorizar el código para hacerlo más testeable.
Según esta definición podéis ver que es todo lo contrario a lo que os contamos del Testing Ágil, por lo que en el post de hoy vamos a ver las razones por las que cambiar el software. Feathers, en el libro Working Effectively with Legacy Code, da cuatro razones principales, que son las que os contamos a continuación.

Añadir una función

Como es normal, desde la parte de negocio nos pueden pedir nuevas necesidades y por tanto funcionalidades, ya sean añadir nuevas funcionalidades, corregir algún error, etc. Todo lleva a lo mismo, a cambiar código y por tanto aparece lo realmente importante, el cambio de comportamiento.
El comportamiento es lo que marca la diferencia, no es lo mismo agregar un nuevo comportamiento, que esto a la parte de negocio le gusta bastante, que cambiar un comportamiento anterior y que puede que se pierda la confianza en el equipo de desarrollo.
Siguiendo con el ejemplo que pone Michael en el libro, si la parte de negocio quiere agregar un logo en la parte derecha y no estaba ya en la parte izquierda, se añade comportamiento, pero no se modifica, en cambio, si se cambia el logo de lado, entonces estamos modificando.
En cada caso hay que ver si se modifica el comportamiento o si se añade, y no siempre que añadimos código estamos añadiendo comportamiento, lo que es importante y es un gran reto en el desarrollo de software es mantener el comportamiento existente.

Corregir un error

Ya sabemos que cuando tenemos que hacer cambios y queremos mantener el comportamiento, esto implica riesgo, el cual podemos solventar con tres preguntas según Michael Feathers:

  1. ¿Qué cambios tenemos que hacer?
  2. ¿Cómo sabremos que lo hemos hecho correctamente?
  3. ¿Cómo sabremos que no hemos roto nada? Ya sabes esta pregunta es muy típica cuando existen miedos y resistencia al cambio (puedes leer más en este post sobre la resistencia al cambio).

Hay equipos que reducen el riesgo haciendo el menor número de cambios posible, por ejemplo evitando añadir clases y métodos ¿pero qué pasa si hacemos esto? que el código crece y crece y las clases se vuelven menos mantenibles, código spaguetti generando así deuda técnica (de la mala). Entonces el código se vuelve un Walking Dead, como dice Javier, y a todo el mundo le va a dar miedo tocarlo y hacer cambios.
Si hacemos un buen software desde el principio, usando técnicas y herramientas como TDD, BDD, integración continua, etc., tendremos un software de mejor calidad, más mantenible, en el que podremos hacer cambios sin miedo a romper nada.

Mejorar el diseño

Hay que diferenciar entre mejorar el diseño y cambiar el software, aunque se encuentran en estrecha relación.
Hay veces que hay que meter mano al software para hacerlo más mantenible por las razones que veíamos en el apartado anterior, y por tanto se altera la estructura del software pero sin cambiar el comportamiento, ¿a qué os suena esto? A la refactorización, que va de la mano de las pruebas de regresión.
No nos vamos a meter en el tema de la refactorización, pero os dejamos una serie de post que hablan de ella:

Optimizar el uso de recursos

Por último cuando optimizamos tenemos un objetivo diferente a la refactorización según Michael, ya que la optimización se intenta trabajar con los recursos utilizados como el tiempo o la memoria, y en la refactorización se trabaja sobre la estructura.

Acabando…

Aunque hablemos de cambiar el software lo que realmente queremos decir es que queremos preservar el comportamiento a pesar de esos cambios. Cada vez que queremos realizar un cambio en el código, hay que asegurarse que el código antiguo no va a fallar y todas las demás funcionalidades no van a ser afectados por este cambio específico que se está haciendo.
Es cierto que trabajar con código heredado puede ser frustrante a veces, por eso consideramos que Michael ha hecho una gran aportación a la comunidad con este libro de vital importancia para el mantenimiento de código heredado o legacy y sobre cómo hacer la refactorización en código sin pruebas y cómo introducirlas.
A medida que pasa el tiempo (tiempo en el que la tecnología evoluciona de manera exponencial), se convierte en legacy, por lo que será muy necesario tener en cuenta estas consideraciones que os contamos en el post.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba