Gran titular que muchas veces estuvo en boca de muchos jefes.
Y yo aquí diría… ¡cuidao! porque es muy fácil pisar la línea y tergiversar el mensaje. Ni hay que hincharse a refactorizar todo, ni hay que tener miedo a tocar el código -«¡ni con un palo toco yo ese legacy!«. Si soy honesta, reconozco que no me gusta la frase «hay que refactorizar con sentido común» en boca de manager, porque su visión está muy alejada del día a día y puede que no sepa exactamente qué le hace falta al código. Eso lo saben las personas que están con el código, día tras día.
El monstruo
Imaginemos que nuestro producto es una amalgama de código legacy (¿y qué es legacy? otro drama) que lleva «funcionando» 20 años (le pongo comillas a «funcionando» porque, aunque es cierto que da retorno y produce beneficio, está empezando a generar muchos problemas de escalabilidad y no tiene la calidad que se necesita si el cliente demandara más). Por cierto, el negocio del que hablamos es potente; hablamos de máquinas grandes e importantes las que funcionan gracias a ese código (cercano a software crítico: aquél donde un fallo puede ocasionar perdidas económicas significativas, daño físicos o en el peor de los casos amenazas a la vida humana). Hasta aquí todo más o menos controlado si no hay que tocar ese código.
¡Problema! Hay que tocarlo. Un usuario de esas máquinas grandes necesita una nueva funcionalidad ahora y nosotros se la queremos dar (management se ha comprometido con el cliente en que se la vamos a dar y además con fecha ya establecida basada en nuestra velocidad, ¡qué bien! ¬¬). Cual cirujanos, necesitamos abrir en canal ese código y meterle bisturí.
¡Problema dos! Tal cual está el código, es imposible asegurar que no meteremos regresiones al tocarlo a menos que hagamos unos tests automáticos.
¡Problema tres! Es imposible meterle unos tests automáticos a esto sin refactorizar un poco el código; vamos, sin cambiar de sitio un par de cosas y reorganizar un poco el caos que hay ahí. Y todo esto, con la presión de saber que hay un jefe de proyecto mirando las horas que vamos a gastar con lupa, porque tienen que cuadrar con una celda de una excel, OMG.
Si queremos complicarlo un poco más, podemos añadir un ¡problema cuatro! y es que como no tenemos cultura de testing, no sabemos hacer tests automáticos bien. Tardamos mucho y encima a veces los que hacemos hay que cambiarlos de arriba a abajo cuando el software cambia. Por tanto, todo es miedo, terror y pavor. Pero para no liarla mucho, vamos a obviar el problema cuatro xD
Cómo enfrentarse a la realidad
Volviendo al tema… ¿qué hacemos? ¿qué hacen los desarrolladores aparte de llorar? ¿qué hace ese jefe de proyecto cuando se entera de que la feature que esperaba para dentro de una semana no se la puede entregar al cliente?
Lo he vivido muchas veces: la gente entra en pánico y en la sombra se echan la culpa unos a los otros, eso lo primero (primero en la sombra y luego a plena luz del día, depende del jefe de proyecto).
Lo segundo es atrasar la fecha de entrega pero añadiendo más features para que el cliente no se enfade.
Lo tercero, que sucede en paralelo, es que tenemos una retrospectiva en el equipo donde analizamos por qué no hemos conseguido acabar la feature en un sprint, como dijimos que haríamos en el sprint planning. Volvemos a analizar el bucle de los 3 problemas del párrafo de arriba. Es la pescadilla que se muerde la cola. Es el día de la Marmota. La película acaba con los desarrolladores queriéndose pegar un tiro y actualizando su LinkedIn.
Origen del mal
Tiendo a pensar que este drama empieza a emerger a los X años de iniciar un producto/proyecto, y que hasta que llega ese momento todo el mundo vive en la inconsciencia, porque cuando comienzas un producto siempre lo haces lo mejor que puedes en ese momento puntual. Cuando empiezas a programar un sistema desde cero no tienes estos problemas, porque el volumen es menor, la gente conoce el código y no hay tanta complejidad. Cuando la gente que programó el sistema se empieza a ir y hay cambio de generación, cuando el sistema tiene que aguantar 10, 20, 30 años y además seguir evolucionándolo (no solo manteniéndolo con parches -qué falacia más grande por cierto-)… Ahí empiezan los problemas. ¿Y es posible que de repente todo empiece a crashear como cuando el ser humano se hace muy mayor y con 98 años te empiezan a fallar todos los órganos a la vez?
Pues sinceramente últimamente pienso que sí, que el problema está escondido hasta que te explota en la cara. Y cuando llega ese momento… Un cambio grande es necesario:
- o paras motores e inviertes en que ese monstruo sea usable,
- o inviertes en otro equipo en paralelo para que vaya arreglando el desastre,
- o haces un poco de equilibrio bajando el ritmo y que el equipo le vaya hincando el diente (para eso hace falta confiar mucho en que el equipo tenga la capacidad de conseguirlo)
- o…, ¿se te ocurre otro?
Refactoriza constantemente
Refactoriza desde el día 1. Programa pensando en tu YO del futuro. Concibe el código como propiedad del equipo, no solo tuyo.
Y hacia management diría que confíe más en el criterio de los desarrolladores. Refactorizar con cabeza (centrar los esfuerzos en el código que más retorno va a proporcionar si se cambia) es un mantra que los propios desarrolladores persiguen o perseguirán pronto con la experiencia, confía en ellos.
Me temo que el jefe que vigilaba con lupa que los desarrolladores no perdieran el tiempo en refactorizar más de la cuenta (cosa que es de lógica, por favor, no me malinterpretes; pero pensar que un desarrollador, si lo dejas libre, tiende a refactorizar por gusto perdiendo el tiempo ¡¡me parece criminal!!), y que no paraba de incidir en la parte del «pero si funciona no lo toques» en lugar de dar herramientas y espacio a los desarrolladores para perder el miedo a lidiar con código complejo, pronto tendrá que tomar una difícil decisión.