La refactorización de supervivencia


Hasta ahora he refactorizado código heredado de más de 15 proyectos ajenos (a veces ni código, directamente compilados), pero ha sido durante estas últimas semanas cuando he podido comprobar una refactorización todavía más dolorosa, la que tienes que hacer sobre tu propio código.

Habitualmente siempre refactorizamos código internamente: vamos metiendo mejoras, crece la deuda técnica y cuando estimamos que la deuda empieza a ser elevada la reducimos con pequeños proyectos de reingeniería, nada del otro mundo, pequeñas iteraciones de 2 o 3 semanas.

El problema ocurrió el año pasado cuando en uno de nuestros proyectos internos dejamos que la deuda técnica fuera demasiado elevada, hasta el punto de que teníamos un gran monstruo de código ilegible con varios antipatrones de por medio: nadie quería meter nueva funcionalidad y cuando se intentaba los avances llegaban con cuenta gotas, viciándose el entorno de trabajo.

La culpa obviamente fue mía, porque la culpa siempre es mía cuando pasan cosas de estas, así que dimensionamos un proyecto para el primer semestre de 2011 solo dedicado a refactorizar el proyecto: a quitar deuda técnica sin añadir funcionalidad.

Hoy mismo pasamos a producción los cambios y debo admitir que no descorcho una botella de champán porque lo detesto, pero acabo de meter una cola zero de 2 litros en el congelador para sacarla cuando este a punto de granizarse… ummmm.