El sistema legado se traga más tiempo cada trimestre, el equipo se queja de la base de código y alguien propone reescribir desde cero. La tentación desaparece cuando abres el historial de estimaciones de las dos últimas reescritas que seguiste: cerró entre tres y cinco veces el número inicial.
Cuatro datos antes de convocar la reunión
- Cobertura de pruebas. Con pruebas confiables, refactorizar es un cambio controlado. Sin pruebas, cada modificación es una apuesta, y una apuesta no entra en producción de un sistema de pagos.
- Acoplamiento externo. Un sistema con muchas integraciones, bases y servicios de terceros es caro de reescribir: cada integración es una superficie de error que hay que reimplementar y validar.
- Quién construyó el sistema. Si nadie que lo creó sigue en la empresa, el conocimiento tácito se fue con esa gente. Reescribir sin él produce el mismo sistema con los mismos errores escritos de otra forma.
- Presión del negocio. Reescribir entra en la cuenta cuando la arquitectura bloquea un cambio que el negocio necesita. Si el bloqueo es gente que falta, contratar resuelve antes.
Cuándo reescribir compensa
La tecnología base se quedó sin comunidad o sin soporte. La arquitectura contradice el producto de hoy: un monolito de 2014 contra la cola de eventos que la operación necesita. O el costo de mantener el sistema ya superó el costo de construir otro.
En esos casos, reescribe por dentro con el patrón Strangler Fig de Martin Fowler ("StranglerFigApplication", martinfowler.com, 2004): envuelves el sistema viejo con una capa nueva, migras funcionalidad por funcionalidad y mantienes el sistema en pie durante el cambio.
El equipo redescubre lo que nadie documentó
Pasas semanas en tres frentes: una decisión de diseño sin registro, un edge case guardado en la memoria de una persona, una integración que cambió mientras el equipo construía la nueva. Cada uno de esos ítems es una semana de trabajo que aparece a mitad de camino.
Martin Fowler publicó Refactoring (Addison-Wesley, 2ª ed., 2018) sobre cambiar estructura sin cambiar comportamiento, el camino de menor riesgo. Joel Spolsky abrió el caso de Netscape en "Things You Should Never Do, Part I" (2000) y mostró lo que costó esa reescrita total.
Empieza por la restricción de esta semana
Escribe qué bloquea al negocio esta semana y el cambio más pequeño que lo resuelve. Suele salir: un refactor de un módulo, el reemplazo de una dependencia, una funcionalidad que el sistema ya soporta y nadie habilitó. La reescrita entra después, si los cuatro datos siguen apuntando hacia ella.
Reunir al equipo a discutir refactorizar o reescribir sin esos cuatro datos produce opinión. Con ellos, la conversación dura veinte minutos y tiene dueño.
