La Cascada de Refactorización
Todo comenzó con una observación correcta. Pita notó que tres subsistemas distintos implementaban cada uno una variante de la misma operación de agregación por ventana deslizante, y que las tres variantes habían divergido durante cuatro años de mantenimiento independiente. Cada una era correcta en su propio dominio. Ninguna era incorrecta. Pero mantener tres implementaciones del mismo concepto era un trabajo que la tripulación no podía permitirse cuando la tripulación eran veintitrés personas gestionando un navío con setecientos combinadores activos.
Propuso una refactorización: un único combinador canónico de ventana deslizante, registrado en el almacén, del que derivarían los tres subsistemas. La propuesta fue aprobada en la reunión técnica de la tripulación en quince minutos. La refactorización tomó tres semanas. No porque la implementación canónica fuera difícil de escribir — no lo era — sino porque cambiar un combinador de carga en un navío en operación requería ejecutar la suite completa de verificaciones contra cada consumidor aguas abajo antes de intercambiar la referencia.
La cascada era esta: cambiar la implementación canónica cambiaba su hash. Cambiar su hash cambiaba el enlace de derivación en cada combinador que lo referenciaba. Cambiar esos enlaces de derivación cambiaba sus hashes. La tripulación tuvo que rastrear el árbol de dependencias completo, actualizar cada manifiesto que referenciaba los hashes antiguos, ejecutar las verificaciones en cada paso y verificar que el comportamiento era idéntico antes de retirar las referencias antiguas del uso activo.
No eliminaron nada. Cada combinador antiguo permaneció en el almacén, direccionado por su hash original, su linaje intacto. Lo que cambió fue a qué hash apuntaban los manifiestos activos. Los sistemas en ejecución del barco cargaron los nuevos combinadores en el siguiente ciclo de arranque. El monitoreo de Sigma registró la transición sin incidentes.
Al final de la refactorización, Pita escribió una retrospectiva. El hallazgo clave: la refactorización había revelado cuatro lugares adicionales donde existía el mismo patrón en forma ligeramente diferente. Los añadió a una lista etiquetada como 'trabajo futuro'. La lista estaba en el almacén. El trabajo futuro se realizó, de forma incremental, a lo largo de los siguientes dieciocho meses. Nadie lo llamó gestión de deuda técnica. Lo llamaron mantener el almacén coherente.