Saltar al contenido
Devloop
Volver

Reconstruir un producto sin detener el trabajo

Husseini Sobhy2 min de lectura

Proteja lo que ya funciona

El código antiguo no es malo por definición. Algunas partes pueden ser difíciles de mantener y, al mismo tiempo, sostener tareas que los clientes usan todos los días. Anote los recorridos, las integraciones y las rutinas internas que no pueden fallar durante la reconstrucción. La nueva versión debe conservarlos aunque cambie por completo su implementación.

Calcule el costo del sistema actual

Decir que el código es un desastre no basta para justificar una reconstrucción. Busque el costo. Un cambio pequeño puede tardar varios días de más. La misma zona puede causar fallos repetidos, o una función necesaria puede seguir retrasándose porque nadie puede modificar esa parte con seguridad.

Use la información que ya tiene. Las horas perdidas, los lanzamientos retrasados y los fallos recurrentes ayudan a decidir entre un reemplazo puntual y una reconstrucción más amplia.

Elija un primer límite claro

Empiece por una parte con un inicio y un final reconocibles, como una página, un servicio o una tarea interna. Debe poder publicarla mientras el resto del producto sigue en el sistema actual. Ese límite permite aprender del uso real sin comprometer todo el producto con la misma decisión.

Trate la primera publicación como una prueba de ese límite concreto. La parte sustituida debe funcionar mejor y poder convivir con el resto.

Haga reversible cada publicación

Defina la vía de retorno antes de empezar la implementación. Puede usar un feature flag, mantener ambos caminos en paralelo o conservar la versión anterior lista para volver a publicarse. El método depende de la parte que cambie, pero el equipo debe saber cómo retroceder antes de necesitarlo.

Defina el final antes de empezar

Escriba los criterios de aceptación de cada parte y nombre a la persona que los aprueba. Así, la reconstrucción no acumula todas las mejoras que aparezcan durante el trabajo. Una idea nueva puede ser útil, pero debe convertirse en una tarea aparte en lugar de alargar la parte actual sin una decisión explícita.