Recibir una herencia casi siempre es un trago agridulce, a veces un trance ineludible en el que dentro de la tragedia queda el consuelo que la persona que marchó en una demostración de amor pensó en ti en sus últimas voluntades.
Cuando hablamos de código legado la cosa cambia. Puede ser un trago dulce, debido al buen hacer del anterior desarrollador o, por desgracia, disfrutemos de un maravilloso trago amargo como la hiel, cosa que suele ser la regla general.
Cuando heredamos código, porque algún compañero decidió dedicarse a la vida contemplativa o, simplemente, cambió de empresa, la mayoría de las veces heredamos un dardo envenenado, un código maldito, una aplicación con la que los usuarios no están cómodos y los desarrolladores tampoco, una mala estructura de proyecto, un código poco legible, poco documentado, sin pruebas unitarias, probablemente con vicios adquiridos de generaciones de desarrolladores que fueron degenerando el código hasta llegar a ser el engendro al que nos enfrentamos.
Cuando uno se enfrenta a una situación así, tenemos tres opciones:
- Seguir el camino de nuestro predecesor y dedicarnos a la vida contemplativa.
- Continuar con extraños comentarios, código indescifrable, ritos de vudú para no romper nada cada vez que tocamos el código y, por si acaso, una buena colección de tarjetitas de santos (imprescindible la de San Judas Tadeo, patrón de los imposibles), para que con un poco de suerte los astros se conjuren y los usuarios no soliciten nuevas funcionalidades o modificaciones.
- Mejorar el código.
Tenemos que asumirlo, es nuestro código. Es una parte de nuestra vida, al menos de nuestra vida laboral, ocho interminables horas durante cinco días a la semana. Demasiado tiempo para vivir con miedo de un correo, llamada de teléfono o tarea en la que se nos solicite la tan temida intervención.
Una buena forma de encarar este problema nos la proporciona el libro "Clean Code" de Robert C. Martin, basándose en esta regla de los boy scouts:
“Always leave the campground cleaner than you found it.”
Traducida a nuestro propósito seria algo así:
“Deja el código un poco más limpio que lo encontraste”.
Una pequeña mejora de identación del código, el cambio del nombre de una variable, la extracción de una pieza de código en un método o la encapsaulación de métodos relacionados en una clase, puede aportar mucho valor y mejorar la mantenibilidad del código en sucesivas intervenciones.
Con esta regla conseguiremos que los desarrollos tengan una mayor calidad casi sin darnos cuenta, aplicando mejora continua.