5 pasos para ser feliz ante un proyecto legacy

Photo by Jacki Drexler on Unsplash

Según la Wikipedia un sistema legacy es «un sistema informático que ha quedado anticuado pero que sigue siendo utilizado por el usuario y no se quiere o no se puede reemplazar o actualizar de forma sencilla».

Como desarrolladores de software, más de una vez a lo largo de nuestra carrera nos encontraremos ante la responsabilidad de sacar adelante un proyecto heredado. Ya que casi nunca es fácil lidiar con ello, me gustaría filosofar un poco en este artículo acerca de cómo podemos afrontar este reto de la forma más tranquila y feliz posible.

Estos son los 5 pasos o consejos que de forma natural han ido surgiendo a fuerza de pelearme con cada uno de los proyectos legacy en los que he trabajado:

1. Repite conmigo: YO NO SOY EL MEJOR PROGRAMADOR DEL MUNDO

Creo que para ser feliz afrontando un proyecto legacy la humildad es fundamental.

Si nos creemos que en unas semanas podemos hacer lo que un grupo de desarrolladores no han podido hacer durante los años anteriores a nuestra llegada nos estaremos equivocando mucho.

El código, te guste mucho, poco o nada, es código en producción, que funciona y aporta valor al cliente. Bajo mi experiencia, la actitud L´Orealista de «porque yo lo valgo» no nos aportará gran cosa. Será mucho más provechoso dedicar esas primeras semanas a analizar el código e intentar comprender el contexto que influyó a la hora de tomar ciertas decisiones.

2. Mucho cuidado con el «Ya que estamos…»

Todos alguna vez en medio de un refactor nos hemos remangado y nos hemos dicho «Ya que estamos…». Luego, a fuerza de tirar del hilo, nos hemos visto obligados a saltar de clase en clase, tocando en partes del proyecto que cada vez se ramificaban más y más, llevándonos a clases que en principio nada tenían que ver con el cambio original, y así hasta darnos cuenta de que cierta peculiaridad, que ni conocíamos ni habíamos tenido en cuenta, nos impide redondear el cambio. Ese momento de «Discard all changes» tras una o dos horas de trabajo es enormemente frustrante y no ayuda a encarar nuestros primeros pasos frente a un legacy project con energía e ilusión.

Como consejo, recuerda el paso 1. Muchas veces el «Ya que estamos…» emerge al creer erróneamente que podemos arreglar todos los problemas del mundo en un único commit. El principio de responsabilidad única también se puede aplicar a tus commits: al acotar el scope de tus cambios te será más fácil revertirlos si fuera necesario o hacer cherry picking entre ramas.

3. La ley del mínimo cambio

Siempre partiendo del respeto al código funcionando, y de que cada línea de código, por superflua que nos parezca, seguramente tenga su función, debemos aprender a conseguir el máximo impacto a través de modificaciones mínimas.

Sobre todo en las fases iniciales, cuando nuestro conocimiento sobre negocio es muy bajo, solemos sentir la necesidad de remangarnos y afrontar un refactor enorme (paso 2) que seguramente acabará impactando en distintas capas del proyecto. ¡¡No lo hagas!! Respira… Estás en la fase de leer código, de empaparte de negocio. Tu tiempo estará mejor invertido si lo dedicas a corregir pequeñas incidencias, respetando la línea a seguir que te marca la base de código actual. Esto sin duda te aportará más alegrías, muchas menos frustraciones e incrementará gradualmente tu conocimiento al mismo tiempo que el proyecto mejora poco a poco ante tus ojos.

4. La regla del Boy Scout es tu mejor aliado

La regla del Boy Scout nos dice que siempre se debe dejar el campamento más limpio de como te lo encontraste. Esto, traducido a nuestro día a día como desarrolladores, implica que siempre que nos encontremos, por ejemplo, trabajando en una incidencia, deberíamos aprovechar para aplicar los principios SOLID en aquél método o clase que estamos tocando.

Esta es la primera fase en la que empezamos a sentir el proyecto como nuestro, es un momento de mucha satisfacción que seguro nos dará un chute de autoestima, ya que hasta este momento nos habíamos dedicado simplemente a tocar lo mínimo desde el respeto. Pero tampoco te emociones, ten presente siempre el paso 2 y no te dejes llevar nunca por el «Ya que estamos…».

5. Arropa tú código con testing unitario

Según pasen las semanas te irás sintiendo más y más cómodo. Con un mayor conocimiento de la lógica de negocio y de la estructura del proyecto, ya estarás en el punto donde empezar a dejar «tu huella».

El testing unitario es siempre una buena forma de empezar a mejorar el código, al mismo tiempo que vamos sellando con tests aquellas clases que contienen la lógica más importante: UseCases, Presenters/ViewModels, Repositories…

El ejercicio de añadir un test a una clase es un excelente cazador de Code Smells: si no tienes la capacidad de testear un método, revisa las dependencias, seguramente estás creando instancias dentro de dicho método, saltándote, entre otros, el principio de responsabilidad única o el patrón de inyección de dependencias.

Conclusión

Como puedes ver, los 5 pasos se reducen a tomárselo con calma. El respeto y la humildad son también fundamentales. Debemos tener presente que el mejor código que hayamos escrito seguramente nos parecería obsoleto o como mínimo mejorable 6 meses después. En este sector los frameworks y los lenguajes evolucionan cada poco tiempo, y aunque el reto de empezar algo desde cero nos parezca un caramelito, pulir un diamante en bruto y hacerlo nuestro tampoco es mal desafío. 😉