Por qué se pudren las herramientas internas y qué lo evita
Casi toda empresa con recorrido tiene una: una aplicación interna que funciona, que nadie entiende del todo y a la que todo el mundo tiene un poco de miedo.
Cómo ocurre
Rara vez es mala ingeniería. Es ausencia de propiedad.
La herramienta se construyó deprisa para resolver un problema real. Funcionó, así que creció. Quien la escribió cambió de trabajo. No se asignó a nadie porque no estaba rota. Las dependencias envejecieron, la versión del lenguaje dejó de tener soporte y la documentación, nunca escrita, siguió sin escribirse.
Entonces hay que cambiar algo, y la estimación de un cambio pequeño son tres semanas, porque las dos primeras se van en entender qué hay.
Las señales de alarma
- Nadie puede montar una copia de desarrollo sin ayuda de una persona concreta
- El despliegue implica pasos manuales en un orden determinado
- No hay pruebas, así que nadie se atreve a cambiar nada
- Las dependencias llevan años atrasadas, varias con vulnerabilidades publicadas
- El autor original es la documentación
Qué mantiene sana una herramienta
Un responsable con nombre. No un equipo, una persona, con tiempo asignado. Es el predictor más fuerte.
Que arranque desde cero. Si una máquina nueva puede pasar del repositorio a la aplicación funcionando en menos de una hora, el conocimiento está en el código y no en la cabeza de alguien.
Actualización automática de dependencias. Pequeña, frecuente, aburrida. La alternativa es un salto de dos años que se convierte en una reescritura.
Pruebas suficientes para permitir el cambio. No cobertura total: las justas para que alguien ajeno pueda cambiar algo sabiendo que no ha roto el cálculo de las facturas.
Una página escrita sobre el porqué. No qué hace el código, sino por qué se tomaron las decisiones raras. Quien mantenga esto en el futuro necesita el razonamiento, y el código no puede expresarlo.
Recuperar una que ha heredado
No la reescriba. Las reescrituras de sistemas que funcionan fracasan más veces de las que triunfan, porque el original absorbió años de reglas de negocio no documentadas.
En su lugar: consiga que compile de forma reproducible, añada pruebas alrededor de lo que maneja dinero, actualice dependencias en pasos pequeños y escriba la página del porqué. Seis semanas enfocadas suelen convertir un pasivo en un activo.
Asumimos este tipo de trabajo en desarrollo de software.