Mantenibilidad y entropía del software
Voy a iniciar una serie de posts sobre conceptos y teoría para escribir código mantenible. Empezaré por los conceptos más básicos y continuaré siguiendo un orden de complejidad que permita entenderlos todos e ir subiendo de nivel.
1. Mantenibilidad
Lo primero es entender qué es código mantenible y por qué es importante.
El código mantenible es aquel que permite a las aplicaciones crecer de manera sostenida en el tiempo porque es fácil de entender y de modificar.
Conviene recordar una cita de Joel Spolsky en su post Things You Should Never Do, Part I que dice así:
Somos programadores. Los programadores son, en su corazón, arquitectos, y lo primero que quieren hacer cuando llegan a un sitio es demoler el lugar y construir algo grandioso. No nos entusiasma la renovación incremental: retocar, mejorar, plantar flores.
Hay una razón sutil por la que los programadores siempre quieren deshacerse del código y empezar de nuevo. La razón es que piensan que el código antiguo es un desastre. Y aquí está una observación interesante: probablemente estén equivocados. La razón por la que piensan que el código antiguo es un desastre se debe a una ley fundamental y cardinal de la programación:
Es más difícil leer código que escribirlo.
Tendemos de manera natural a construir de nuevo el software porque nos cuesta menos que leer el código existente. Pero la cruda realidad es que si optamos por escribir por encima de leer vamos a recorrer el mismo camino espinoso que otros recorrieron anteriormente: cometeremos los mismos errores y al cabo de un tiempo nuestra aplicación volverá al punto de partida, con un código difícil de comprender y de cambiar.
2. Entropía
Este ciclo se va a repetir irremediablemente, tanto es así que tiene un nombre: entropía del software.
La entropía mide el nivel de desorden de un sistema. Dicho concepto proviene de la segunda ley de la termodinámica y se puede aplicar tambien a las aplicaciones de software:
A medida que se hacen modificaciones o se agrega nuevo código, este va perdiendo su estructura inicial y aumenta su entropía.
Si aumenta la entropía, disminuye la velocidad de programación. Cada nueva funcionalidad cuesta más tiempo y dinero de implementar, hasta llegar al punto que las horas invertidas en realizar una modificación no se pueden asumir.
Refactorizar el código para que sea más mantenible es la única manera de luchar contra la entropía. No hacerlo puede tener un coste de miles de euros o de cientos de miles dependiendo de la aplicación.
3. ¿Qué puedo hacer?
Comprender que es complicado leer código es el primer paso para revertir la situación. Además, necesitarás experiencia y conocimientos sobre principios, prácticas y patrones.
Pero todo de golpe no se puede conseguir, así que vayamos paso a paso y centrémonos en cosas sencillas que en este momento todos podemos asumir. Por ejemplo, dale la misma importancia tanto a la funcionalidad que desarrollas como a la mantenibilidad del código.
Programa como si el tipo que terminará manteniendo tu código fuera un psicópata violento que sabe dónde vives - John Woods.
Lo normal es que acabes trabajando en una aplicación grandiosa en la que la entropía ya esté descontrolada. Todos hemos pasado o estamos pasando por ello. Aquí viene otro consejo de oro de aplicación inmediata:
Regla de los Boy Scouts: deja siempre el código mejor de lo que lo encontraste.
No hace falta que arregles la aplicación entera, céntrate en el ámbito de tu nueva funcionalidad y déjala agradable de leer para que el próximo que llegue no se vuelva loco.
4. Es posible
Quizá no me creas, pero es posible conseguirlo. Es posible vivir tranquilo sin tener 200 variables en la cabeza para comprender el código y sin tener que navegar entre funciones hasta encontrar el punto donde meter una nueva chapuza con calzador.
Espero poder ayudar con esta serie de posts a detectar los puntos conflictivos de tu aplicación donde es posible intervenir y convertir tu código en algo de lo que te sientas orgulloso.