No tengas miedo del código | Re-pensando los proyectos Legacy

La mayoría de los desarrolladores de software invertimos la mayor parte del tiempo trabajando sobre código escrito por otras personas y no creando algo completamente desde cero, por lo que, probablemente, hayas escuchado el término Legacy o, quizás, hasta trabajado en código considerado como tal. Si aún no tuviste la oportunidad, no te preocupes, lo mejor está por llegar.

Para aquellos que no están familiarizados con el término aplicado a proyectos, podríamos definirlo de forma amplia como un proyecto que se ha vuelto muy difícil o casi imposible de mantener o extender.

Algunas características comunes (aunque no determinantes) que comparten muchos proyectos de este tipo son su antigüedad, dimensión, documentación y el hecho de que son heredados.

Personalmente creo que todos están estrechamente relacionados, dado que un proyecto que vive al menos un par de años tiene la necesidad de incluir nuevas funcionalidades, lo que aumenta su tamaño y a su vez el mismo uso lleva a la indefectible aparición de errores y hotfix.

Estos se enfrían y terminan siendo partes formales del código, aunque nunca documentados y como “soluciones temporales”, dejan solo a los testigos de aquel suceso como propietarios únicos de ese conocimiento, el cual, paradójicamente, nunca heredamos cuando entramos al proyecto.

“Hotfix, bugfix y soluciones temporales que no sean documentadas siempre terminan como conocimiento perdido”

Todos estos factores incrementan poco a poco, y cada vez más rápido la entropía del sistema hasta el punto que introducir una nueva funcionalidad o corregir un nuevo error es más cercano a un espectáculo de equilibrismo que al desarrollo de software. Todos los que desarrollamos software, desde el área de desarrollo, producto, infraestructura o calidad tenemos parte de responsabilidad sobre esto, tanto de generarlo como de corregirlo.

Existen muchas estrategias para abordar los diferentes problemas que podemos encontrar en estos proyectos, en especial, metodologías para la reconstrucción y saneamiento del código fuente. En este artículo me gustaría abordar especialmente la eliminación de la cultura Legacy, la cual considero la piedra angular, tanto para corregir uno existente, como para prevenir caer en ellos.

El verdadero legado

Cuando hablo de cultura Legacy me refiero, específicamente, a aquellos comportamientos o prácticas que permiten mantener los proyectos con un constante incremento del caos enmascarado en una especie de status quo.

El verdadero legado de estos proyectos es, en realidad, las personas y procesos que hicieron que el sistema llegue a ese estadio pero, muchas veces, no tenemos en cuenta eso, llevando las mismas prácticas de un sistema a otro. Los sistemas no son propensos a costumbrismos.

Si no logramos generar un cambio en la raíz de estos procesos, posiblemente solo seremos capaces de generar sistemas Legacy, sin importar qué tan nuevos sean.

Divertido y Significativo

Uno de mis pasatiempos favoritos de niño era desarmar cosas, siempre estaba tratando de entender cómo funcionaban y experimentar cómo mejorarlas, por lo que para mí, trabajar en sistemas Legacy, es divertido por naturaleza, y aunque no pueda ser para todos así, en general tenemos una motivación para hacer lo que hacemos y este no debería ser un caso diferente.

Es común que personas que trabajan algún tiempo en estos sistemas, o que recién se encuentran con uno, prefieran trabajar en un sistema nuevo o con la última tecnología, y el no hacerlo, puede generar frustraciones. Sin embargo, no tenemos que olvidar que al final del día, nuestro trabajo sigue siendo resolver problemas, de la mejor forma que esté a nuestro alcance.

Creo que es importante que puedas encontrar algo significativo en el trabajo que haces, sea lo que sea que signifique para vos. Para mí, cada problema es un reto y una oportunidad para hacer que el sistema sea mejor y tener mayor control.

Mantenimiento

Dentro de los comportamientos mas comunes que podemos encontrar en proyectos de software, tenemos el de primar la velocidad para entregar funcionalidad por sobre la calidad en el código fuente y/o la documentación. Esto puede ser algo difícil de argumentar en contra dado que, especialmente en empresas enteramente dedicadas a ofrecer software, esa nueva funcionalidad puede ser el diferencial respecto a sus competidores.

Si consideramos nuestro sistema como el motor de nuestro negocio, si constantemente lo utilizamos sin darle un mantenimiento apropiado, cada vez será más difícil mover cada uno de sus engranajes hasta detenerse completamente.

Si priorizamos el valor agregado del producto y la velocidad para entregar por sobre la calidad, será mas difícil y más lento realizar ajustes o introducir nuevas funcionalidades, lo que eventualmente será una desventaja respecto a nuestros competidores.

Paradójicamente, elegir velocidad sobre calidad, dejando a esta última como el coste de oportunidad obvio, nos llevará a perder también velocidad a lo largo del tiempo, dejando a ambas opciones como coste de la alternativa.

Es importante encontrar el equilibrio apropiado para entregar funcionalidad lo suficientemente rápido sin dañar la calidad, y entender que el tiempo usado en mejorar los recursos (código fuente, documentación, etc.), es una inversión, no un gasto.

High quality software is cheaper to produce — “Is High Quality Software Worth the Cost?” Martin Fowler

Red de seguridad

Uno de los grandes problemas a los que se enfrenta un desarrollador a la hora de trabajar en código fuente Legacy es el miedo, que se presenta en diferentes formas pero, especialmente, el miedo al cambio (aunque muchas veces es simplemente la ley del menor esfuerzo como abordaré más adelante).

La falta de tests y documentación o comentarios como “esto no debería funcionar…” o “ ver si rompe en producción ” — los cuales que me he encontrado personalmente en códigos productivos — pueden hacer que el simple hecho de pensar en introducir un cambio mínimamente más grande del necesario , desate un ataque de ansiedad.

Es cierto que pueden existir muchos riesgos asociados a un cambio o un nuevo feature, pero esto es igual en los sistemas Greenfield. ¿Qué pasa si la arquitectura propuesta no escala? ¿Qué pasa si el sistema no resuelve una funcionalidad correctamente? Sin importar donde estén los riesgos, tenemos alguna alternativa para contenerlo. En el caso de los sistemas de software Legacy, posiblemente la herramienta más útil que tengamos es el Peer-Review.

Dijimos que los sistemas Legacy usualmente son grandes y antiguos, pero no todos los sistemas con esas características deben considerarse como tales. El Kernel de Linux, cumple con esas características, sin embargo, con más de 14 millones de líneas de código, tiene solo 0.39 de densidad de defectos, siendo mejor que la media de muchos productos comerciales.

Esto quizás puede ser atribuido a la comunicación abierta y sincera que prima en los desarrollos de código abierto, donde todos los cambios son revisados por otros desarrolladores, lo cual no solo incrementa la calidad del código fuente, sino la información compartida a todos los involucrados.

Es importante perder el miedo a criticar y/o que nuestro código sea criticado. No somos nuestro código y todos los involucrados en cada proyecto comparten un mismo objetivo: mejorar el producto.

Anti-natural

Existe una hipótesis de que, desde un punto de vista biológico/evolutivo, estamos programados a realizar el menor esfuerzo o el camino de menor resistencia. Esto puede llegar a ser beneficioso en el desarrollo de software para mantener ciertas estructuras previamente establecidas debido a que solo debemos continuar con él mismo patrón una vez que se ha invertido tiempo en desarrollar una arquitectura apropiada. Sin embargo, en sistemas Legacy se produce el efecto contrario, dado que esa estructura puede no existir, ser incorrecta o no ser escalable.

Este es el motivo por el cual creo que, una de las cosas más importantes a la hora de trabajar en este tipo de proyectos, es movernos en contra de nuestra propia naturaleza y recorrer un “extra mile” preguntándonos: ¿creo que esta es la mejor forma? ¿puede mejorarse? ¿debo continuar con esta práctica?

Haz un plan

Lo primero que hacemos una vez que entendemos que nuestro proyecto se ha convertido en Legacy es hacer un plan de cómo vamos a cambiarlo por uno nuevo. No necesariamente es un mal inicio, pero no puede ser el único plan que tengamos, ya que nuestro negocio no va a parar para que podamos tomarnos el tiempo de desarrollar un nuevo sistema.

Usualmente, los equipos que trabajan en la nueva versión, se ven obligados a introducir nuevas funcionalidades solicitadas por el cliente o corregir errores reportados en ambos sistemas, haciendo que el mismo siga creciendo y, peor aún, que lo haga con un acta de defunción ya firmada como invitación al caos, su calidad comienza a descender aún más y más rápido.

Creo que los primeros planes deberían estar enfocados en evitar que tu sistema siga incrementando su entropía y en cómo reducirla. Respecto a los planes de reemplazo, quizás tomar las decisiones importantes lo más tarde posible nos sea de utilidad.

Porque? Por que cuando retrasas una decisión, tienes mas información cuando llegue el momento de tomarla.

— “Clean Architecture” Robert C. Martin

Ninguno de estos puntos serán la solución a todos los problemas, sin embargo espero que conocerlos y entender el impacto que pueden tener te ayuden a perder el miedo a tu código y comenzar a transformar tu Legacy en un software moderno del que puedas estar orgulloso.