Pedro Pardal es ingeniero de software y coach técnico. Se dedica a ayudar a desarrolladores y equipos a mejorar la entrega de sistemas de alta calidad mediante aplicación de prácticas de XP y valores de software craftsmanship.
En esta charla en el #SDsummit, Pedro nos sitúa en el contexto del código legado -o código legacy- y lo define como todo aquel código que “cuesta leer, es complejo, incomoda y hasta (a veces) da miedo o supone un riesgo cambiar”.
Comenta que tendemos a pensar que el código legado es así porque en su momento los desarrolladores no tenían las herramientas que hay ahora, no existía SOLID, no escribían tests, etc. Sin embargo, la realidad es que todo proyecto comienza siendo greenfield, hasta que un día se transforma en legacy.
Para no caer en la trampa de pensar que “el código nuevo no será legacy algún día”, Pedro propone que veamos cuáles son los factores que hacen que el código termine siendo complejo e incómodo y luego reflexionemos sobre cómo podemos hacer que esos factores estén lo más controlados posible.
¿Qué factores nos hacen desarrollar código legado?
- Requisitos nuevos cambiantes: lo que siempre sucede es que al equipo de desarrollo le llegan requisitos y en base a ellos se monta un sistema. Luego, en un futuro no muy lejano, aparecen nuevos requisitos que contradicen los anteriores… Y resulta que el sistema no está preparado para ello y toca cambiar. A veces, a estos acontecimientos nos intentamos adelantar y hacemos una abstracción incorrecta que nos cuesta más quitar que dejar donde está. El hecho de que los requisitos cambien es, sin dudas, un factor a considerar al momento de pensar en por qué escribimos código legacy.
- Fechas de entrega: en general los proyectos de software “son para ayer”. Solemos pensar que podemos salir a producción con un código que luego mejoraremos y ese momento nunca llega.
- Desarrolladores: escribir software es una actividad social: la hacemos en equipos. Si al proyecto lo llevase adelante 1 sólo desarrollador, él no tendría que discutir con nadie sobre la visión técnica, ni explicar su entendimiento del dominio, etc. Pero en equipo, hay visiones diferentes, personas que entran al equipo y otras que se van. Por lo tanto, este es un factor que favorece la escritura de código legado.
¿Cómo podemos controlar esos factores?
Sabiendo que los factores antes descritos son inevitables, lo que podemos hacer es aplicarles a ellos una “fuerza contraria” para mantenerlos controlados y así intentar que el software se deteriore lo menos posible.
Algunos tips:
- Mejorar tus habilidades para ser más productivo: utilizar las sugerencias del IDE, autofixes, refactors automáticos. Crear el hábito de hacer katas que mejoren tus habilidades. Al final, los deportistas deben entrenar para luego competir. Aquí debería ser igual.
- Intentar cumplir con las 4 reglas del diseño simple de Ken Beck.
- Tener cierta “intolerancia” por el código “malo”: esto se consigue conociendo los code smells, SOLID, escribiendo código con TDD, etc.
- Mejorar la forma en que trabajamos en equipo para crear un ritmo sostenible: cambiando rutinas, hábitos, haciendo retrospectivas, aprendiendo juntos, creando acuerdos de equipo.
- Utilizar forcing functions: cambios en el entorno que obliguen a actuar de determinada manera. Siempre es mejor adaptar el proceso o automatizar pequeñas tareas que “tener que acordarnos de hacer las cosas de tal forma”.
Conclusión
Al final, los motivos por los que desarrollamos código legado son atemporales: existieron hace 10 años, existen ahora y seguirán existiendo.
Pedro nos propone que nos convirtamos en jardineros del código, siendo nuestro codebase el jardín. Cierra la charla dándonos un gran consejo: cada día dedicarle 10 minutos a mejorar algún código que nos haya molestado ver, puede ser simplemente aplicando refactors automáticos. Si hacemos eso todos los miembros del equipo, poco a poco estaremos trabajando en un código más agradable y menos doloroso.
Puedes volver a ver la charla de Pedro aquí:
Sobre la autora
