Cuando terminé de estudiar Ingeniería Informática en la Universidad y me puse a trabajar de programadora en mi primera empresa, no tenía ni idea de qué significa legacy code o «código legado». Simplemente, me dediqué a desarrollar código como había aprendido en la carrera. Y estaba muy ilusionada por ello: estaba programando de forma profesional por fin. Wow. Me sentía importante.
Pasaron los años y, casualidades de la vida, los trabajos por los que pasé fueron todos de desarrollo web (relativamente modernos). Además, eran proyectos pequeños y novedosos.
Pero de repente, 10 años después aterricé en una empresa donde se desarrollaba software «casi crítico» (no llegan a depender vidas humanas de él si tuviera algún fallo en producción, pero sí pérdidas de millones de euros y alguna que otra catástrofe a nivel internacional), heredado de otra empresa, que tenía aproximadamente más de 25 años de vida. Además estaba en C++ y Java, con millones y millones de líneas de código, con lógica de negocio repartida por muchos componentes y módulos muy complejos, donde todo estaba muy acoplado. Si tocabas una cosa aquí, por arte de magia dos cosas se rompían allí, con lo cual mejor tocarlo lo mínimo posible.
En ese momento, entendí qué podía ser el código legacy.
Qué significa «legacy code»
Hay varias definiciones y todo un sinfín de debates en torno a qué se considera realmente código legado. Digamos que no existe una definición única:
- La wikipedia lo categoriza como «código heredado» que ya no tiene soporte técnico
- Michael Feathers, en su libro «Working effectively with legacy code», lo interpretó como código que simplemente no tiene tests automáticos
- Ciertos desarrolladores piensan que es código difícil de mantener. El que da miedo tocar por si se rompe por sorpresa en alguna parte desconocida. El que te esclaviza y te obliga a añadir un «IF» más donde ya había 4, para tocar lo mínimo. Yo comparto esta acepción.
Y, ¿qué ocurre cuando tu día a día se convierte en una continua sensación de no poder controlar tu producto?. Cuando te ves obligado a añadir ese IF chapucero. Cuando tu filosofía se convierte en «tocar lo mínimo». Cuando no te atreves a refactorizar absolutamente nada, porque el código no tiene tests y necesitarías refactorizarlo para poder meterle tests (pescadilla que se muerde la cola). Pues… que si tus expectativas son querer trabajar con una calidad mínima y no puedes, te empiezas a desanimar y pierdes la motivación.
Aquí creo que empieza el odio al legacy code. En este punto.
«Odio el legacy code«
Durante un tiempo yo también sentí desprecio por el código legado, lo reconozco. Me obligaba a trabajar de una manera que yo no compartía (tocar lo mínimo, sabiendo que la calidad empeoraba), y eso me hacía estar incómoda todo el tiempo. Además, como teníamos que sacar funcionalidad considerablemente rápido (¡hacemos scrum y hay jefes que revisan que nuestra velocidad vaya en aumento sprint tras sprint!) tampoco tenía tiempo de probar a refactorizar algo y probar que todo continuara funcionando porque… ¡ni siquiera sabía qué tenía que probar! El sistema era tan grande que ni lo conocíamos en su totalidad. Me sentía totalmente vendida. Odiaba ese código, y empecé a preguntarme cosas muy oscuras: «por qué las personas que lo hicieron lo hicieron tan mal?».
Entrar en esa vorágine oscura solo me perjudicaba a mí y a mis compañeros, porque además era una suposición errónea la que estábamos haciendo. Digamos que cuando estás tocando fondo necesitas sacar fuera lo malo, y a veces sale de forma tóxica… Eso nos estaba pasando.
Además, si lo pienso con profundidad, realmente estábamos molestos porque no teníamos tablas frente a ese código (no es que odiáramos el código mismo), mientras nuestros jefes esperaban que sí lo tuviéramos. ¡Era un mismatch de expectativas grandísimo!
Cambio de enfoque: «toxicidad fuera»
Fue realmente cuando busqué ayuda en las comunidades de software crafters que hay repartidas por España, cuando comencé a ver con más claridad. Seguro que había más gente que tenía mi problema: «¿y cómo se vive esto en otros lugares? ¿la gente qué hace, cómo sobrevive?». Al empezar a escuchar que hay técnicas para romper el bucle horrible de:
«no tengo tests, no puedo refactorizar de forma segura –> necesito tests –> Pero para poder meter tests, necesito cambiar el código (refactorizar) –> Pero eso no lo puedo hacer de forma segura si no tengo tests» ==> COLAPSO MENTAL
se abrió una pequeña ventana de esperanza en mi mente.
Mi problema simplemente era que yo no sabía (porque nadie me había enseñado y era la primera vez que me encontraba esto profesionalmente) cómo lidiar con el legacy, pero me pagaban para saber lidiar con él. ¡Vaya! ¡Hasta entonces pensaba que solo tenía que saber programar! Esto iba de otra cosa.
Cuando empecé a verlo como un reto, un bonito reto del que aprender mucho, entonces mi odio se fue disipando… Fui entendiendo que lo que necesitaba era más formación en este aspecto. Necesitaba, con coraje (controlado 😊), explicar a mi manager que no podíamos seguir haciendo las cosas como siempre las habíamos hecho: por inercia, siempre igual, tocando lo mínimo y que los problemas se multiplicaran exponencialmente en cada cambio. Necesitábamos hacerlas mejor para avanzar y para dejar de sentir esa toxicidad en el equipo, que nos forzaba a querer buscar trabajo en otras empresas de la desesperación.
Apreciando el legacy code
Es increíble cómo un cambio de enfoque hace que lo que antes parecía Mordor, empiece a parecerse a una aventura gráfica agradable… (un Day of the Tentacle o un Secret of Monkey Island). Algunos desarrolladores, ya experimentados, tienen otras acepciones diferentes de las que hemos visto arriba para el legacy code: «el código que paga las facturas», o incluso «el código que realmente funciona», jajaja, ¡qué cosas! ¡Y lo peor es que tienen razón! Si es código que lleva usándose 5, 10, 15, 20 años… ¡será por algo!, y además, los que estamos contratados para seguir manteniéndolo es gracias al beneficio que genera ese código, seguramente. Algo de respeto por nuestra parte, merece.
Y, por cierto, otro tema es aquel odio que nos producía pensar en los desarrolladores del pasado, en aquellos que corrieron y corrieron sin preocuparse por la calidad, sin meter tests automáticos, sin refactorizar… Me gustaría decir algo sobre eso: «¿quién te dice a ti que el código que generes hoy no será legacy para otra persona dentro de 10 años?»
Así que, sé humilde y…
. . .
Y por cierto, te recomiendo que le eches un vistazo a estas 3 charlas sobre el tema porque quizás te ayuden a cambiar la perspectiva y a valorar más el código legacy: