Modernización de software
El sistema funciona. El problema es cambiarlo. Cada entrega rompe algo que no tenía relación, una función pequeña se estima en tres semanas y quien lo escribió ya no está.
Qué incluye
- Leer el sistema y escribir cómo se comporta hoy de verdad
- Reparar el modelo de datos, con migraciones para los registros ya guardados mal
- Actualizaciones de dependencias y de entorno postergadas durante años
- Pruebas alrededor de las reglas que importan, para dejar de cambiar a ciegas
- Separar las partes que nunca debieron estar acopladas
- Sustitución por etapas de los componentes, sin un lanzamiento de alto riesgo
Cuándo se necesita
Cuando la respuesta a cada petición es que es complicado. Cuando nadie quiere tocar un archivo concreto. Cuando una dependencia es tan antigua que no se puede aplicar un parche de seguridad.
También antes de decidir una reconstrucción. Refactorizar suele ser más barato que reescribir, y la auditoría dice cuál de las dos toca.
Problemas que encontramos en sistemas existentes
- Una reescritura completa en paralelo. Hay que mantener dos sistemas, el nuevo nunca alcanza al antiguo y se agota el presupuesto. Sustituimos el sistema por partes mientras sigue en marcha.
- Refactorizar sin pruebas. Nadie puede demostrar que el comportamiento sigue igual y los fallos aparecen en producción. Escribimos pruebas sobre el comportamiento actual antes de tocar nada.
- Ordenar el código sin tocar el modelo de datos que originó los problemas. Los mismos errores vuelven. Corregimos el modelo de datos con migraciones graduales y reversibles.
- Actualizarlo todo de golpe. Cuando algo se rompe, nadie sabe qué cambio lo provocó. Actualizamos en pasos pequeños, cada uno desplegado y verificado.
Qué hacemos
Empezamos estableciendo hechos: qué hace el sistema, cómo son los datos, qué está cubierto por pruebas y qué no. Esa evaluación es la auditoría.
Después trabajamos en pasos pequeños y reversibles con el sistema en producción todo el tiempo. Sin reescritura paralela y sin congelar el desarrollo salvo que quieras.
Cómo se desarrolla
- Auditoría primero, siempre: refactorizar un sistema que no hemos leído es adivinar
- Una secuencia priorizada, empezando por lo que causa incidencias ahora
- Cada paso desplegado y verificado antes del siguiente
- Tu equipo implicado, para que el conocimiento se quede con vosotros
Danos acceso y una semana.
Una auditoría sobre un sistema existente dice qué resolvería y qué no una reconstrucción.