Casi todos hemos experimentado esa sensación de empezar un proyecto de cero. Es una experiencia única donde nos sentimos como un niño con un juguete nuevo.

En esos primeros pasos de un proyecto todo es paz y alegría. Es un gusto realizar cada tarea donde vamos tomando decisiones que van dando forma a nuestro proyecto.

Utilizamos las últimas versiones de librerías y frameworks. Desarrollamos a una buena velocidad.

Pero a medida que avanza el tiempo, esta forma de desarrollar rápido se va mermando, cada vez tardando más a medida que el código se va transformando poco a poco en un código difícil de mantener. Apareciendo así el código legado.

Cuando esto sucede, el coste del mantenimiento del proyecto se incrementa cada año que pasa.

¿Cómo llegamos a este punto? En este artículo vamos a ver algunos puntos clave.

Testing

La ausencia de tests es uno de los motivos por los que aparece el código legado.

Una de las principales características del código legado y que provoca más retrasos o errores es que es un código difícil de cambiar y propenso a errores.

Cuando escribimos código apoyándonos en tests puede ser utilizando TDD o no. En cualquier caso, tener una red de seguridad de testing hace que tengamos feedback temprano cuando se cometen errores. De esta forma se desarrolla de una forma más segura y fiable.

Haciendo un buen testing tanto de test unitarios como de integración, hace que tengamos que escribir código de forma que sea testable. Cuando un código es testable, como consecuencia será fácil de cambiar también en el futuro.

Escribiendo buenos tests, nos acercamos a tener un código que sea fácil de cambiar.

Mal diseño de software

Otro de los motivos por los que aparece el código legado es por un mal diseño de software.

¿Qué significa esto? Un mal diseño de software se produce cuando hay falta de cohesión y un exceso de acoplamiento.

Cada lenguaje nos proporciona herramientas en forma de tipos, funciones, clases que están pensados como una base sobre la que construir cualquier tipo de software. Es decir, están pensados de forma horizontal.

Sin embargo, nosotros desarrollamos software verticalmente para un negocio concreto. Es muy necesario que el código hable el lenguaje del dominio. Creando tipos específicos del dominio que encapsulen las reglas de negocio.

Cuando creamos tipos específicos del dominio, permanece junta la lógica relacionada, resultando menos propenso a errores y más fácil de mantener.

Por otra parte, es importante separar el código que controlamos del código que no controlamos. Es decir, separar el código que contiene la lógica de negocio del cliente, del código dependiente de librerías y frameworks.

Esto último nos permite adaptarnos mejor a la velocidad del cambio de la tecnología sin afectar al dominio de nuestro proyecto.

Tener un buen diseño de software facilita el testing, y el testing es esencial para tener un buen diseño de software.

Es como nadar y el agua, nos puedes hacer una cosa sin la otra.

Complejidad accidental

La complejidad accidental es otro de los motivos por los que el código se empieza a complicar de forma innecesaria.

La base de este problema es pensar demasiado en el futuro o la falta de experiencia, teniendo un código más complejo de lo necesario para resolver el problema.

La complejidad inherente al problema que estamos intentar solucionar es conocida como complejidad esencial. Sin embargo, el diseño, código o conjunto de herramientas usadas como solución para resolver ese problema es conocida como complejidad accidental.

La complejidad esencial no depende de nosotros, sino del negocio del cliente. Programar una pantalla que calcule el presupuesto de fabricar un libro tiene mayor complejidad esencial que una pantalla de login.

Sin embargo, las herramientas que decidimos utilizar para dar solución al problema como el diseño del código, librerías, algoritmos pueden añadir complejidad innecesaria. Esta complejidad accidental, si depende de nosotros.

Un ejemplo que me he encontrado varias veces, es utilizar librerías reactivas como rxjs, rxjava porque están de moda en módulos de la aplicación que no necesitan reactividad, añade complejidad accidental de forma innecesaria.

Otro caso típico es hacer un diseño pensando demasiado en el futuro que posiblemente no llegue nunca.

Desarrollar usando TDD ayuda a escribir un código más simple, mínimo y necesario para el presente.

El código difícil de leer

Las prisas, estrés o malos hábitos pueden hacer que escribamos código difícil de entender. Un código difícil de entender, con malos nombres, funciones o clases grandes, es otro de los motivos para que aparezca el código legado.

Tener la empatía de escribir código pensando que pueda ser leído e interpretado por personas ajenas al proyecto es fundamental.

Además, los primeros beneficiados seremos nosotros mismos en el futuro. Seguro que volveremos a ese código y agradeceremos haber puesto cuidado para que sea legible.

Refactoring como tarea

No somos máquinas y es inevitable por diferentes factores como estrés, distracciones o falta de conocimiento que escribamos código que necesite ser mejorado en el futuro.

El problema es ir acumulando y retrasando estas mejoras. Es mucho más saludable para el proyecto tener una cultura de refactorización diaria, continua y en pequeños pasos a medida que nos vamos encontrando código mejorable.

Una práctica que suelo utilizar yo, es dedicar unos minutos al principio del día para revisar el código del día anterior.

Falta de conocimiento para escribir código de calidad

Para mí, la más importante, hay una falta de desconocimiento de principios de diseño o arquitectura generalizado.

Seguimos demasiado centrados en librería y frameworks. Al igual que los lenguajes, las librerías están creadas de forma horizontal para resolver cualquier tipo de problema.

En los últimos 20 años no han parado de salir nuevas librerías y frameworks, pero seguimos escribiendo código que da pena y es difícil de mantener. Por lo tanto, la solución no parece ir por ahí.

Somos nosotros los que debemos hacernos cargo de nuestro código, añadiendo cierto criterio y poner orden en nuestro código de forma vertical.

Si quieres aprender a hacerlo, te puedes apuntar a la lista de espera de la próxima edición del curso de Clean Architecture:

Curso Clean Architecture en abierto - Lista de Espera

¿Te ha gustado esta newsletter?

El mejor regalo de agradecimiento que me puedes hacer es compartirla 👇

Te animo a que me des tu opinión, o me transmitas dudas en los comentarios de esta newsletter desde la web o respondiendo a este correo.

A veces tardo, pero siempre acabo contestando.