Modifica un sistema existente de forma segura

Identifica los contratos que rodean al cambio

El software existente tiene llamadores, datos almacenados, tareas programadas y procedimientos operativos. Algunas dependencias no aparecen en el archivo que quieres editar. Un agente puede producir un cambio correcto en ese archivo que rompa uno de esos contratos.

Antes de implementar, identifica quién lee y escribe los datos afectados. Inspecciona rutas, procesos en segundo plano, informes e integraciones externas. Comprueba si otros equipos o versiones antiguas de clientes dependen del comportamiento actual.

Pide al agente que muestre las pruebas que respaldan este mapa. Un resultado de búsqueda es un buen punto de partida, pero las llamadas dinámicas y los consumidores externos pueden requerir que una persona responsable confirme la dependencia.

Haz observable el comportamiento actual

Si un módulo está mal documentado, añade comprobaciones concretas del comportamiento que debe permanecer estable. Estas comprobaciones describen el contrato actual. No demuestran que todo comportamiento existente sea deseable.

Si el comportamiento actual contradice un requisito, registra el conflicto. No conserves un defecto de seguridad solo porque una prueba lo haya recogido. Obtén la decisión necesaria para distinguir el comportamiento previsto de un defecto.

Usa datos de prueba realistas y no sensibles. Incluye formatos antiguos y registros incompletos cuando puedan existir. Un esquema nuevo probado solo con datos recién creados puede ocultar problemas de migración.

Revisa la transición entre versiones

Considera un cambio ficticio de nombre de customer_name a display_name. Cambiarlo de inmediato puede romper una instancia antigua de la aplicación durante el despliegue. Actualizar ambos archivos en una pull request no hace que el despliegue sea atómico.

Un enfoque por etapas puede conservar la compatibilidad:

1. Añade el campo nuevo sin eliminar el antiguo.
2. Define cómo mantendrán las nuevas escrituras la coherencia de los valores necesarios.
3. Completa los registros existentes mediante un proceso que pueda reanudarse.
4. Verifica que los datos estén completos y que los lectores funcionen correctamente.
5. Pasa los lectores al campo nuevo.
6. Retira el campo antiguo solo cuando ya no queden consumidores.

El método exacto depende de la base de datos y de los patrones de escritura. Las escrituras dobles pueden crear incoherencias si falla una de ellas. Puede hacer falta una transacción de base de datos u otro método explícito de sincronización. No apliques este ejemplo sin comprobar las garantías del sistema.

Martin Fowler describe esta transición general como parallel change, también llamada expand-and-contract. La idea central es mantener una transición compatible antes de retirar lo antiguo.

Planifica la recuperación por separado de la reversión

Una reversión de código restaura una versión anterior de la aplicación. No deshace automáticamente una migración de datos. La versión antigua puede no entender los datos nuevos. Una migración destructiva puede eliminar información que la reversión de código no puede recuperar.

Identifica la acción de recuperación de cada paso. Puede ser seguro reanudar un proceso de relleno de datos preparado para ello. Una transformación incorrecta puede exigir una corrección a partir de los datos de origen conservados. Una operación destructiva puede requerir un procedimiento de restauración verificado.

Pregunta quién es responsable de decidir la recuperación y cuánto puede tardar. No trates «tenemos copias de seguridad» como prueba de que la recuperación cumple el requisito del servicio.

Mantén el cambio revisable

Separa la limpieza ajena a la tarea del cambio funcional. Incluye en la pull request el plan de compatibilidad, los resultados de verificación y las condiciones de retirada. Marca el punto a partir del cual la reversión requiere trabajo adicional.

Un agente puede ayudar a inspeccionar los consumidores y preparar el código de migración. Una persona responsable sigue teniendo que aceptar el plan de transición y recuperación. El diseño final es solo una parte de un cambio seguro.