Heredar algo que construyó otra persona
Todo sistema heredado parece peor de lo que es, por la misma razón por la que toda ciudad desconocida parece mal planificada.
Tarde o temprano heredas algo: una base de código, una automatización, una hoja de cálculo de la que dependen tres departamentos. Quien la construyó se fue o está ocupado, la cosa funciona y nadie sabe decirte por qué.
El impulso de reescribir casi siempre se equivoca
El trabajo ajeno parece malo porque ves todas sus cicatrices y ninguno de sus motivos. Esa condición rara en mitad de una función no es descuido: es el arreglo de un problema de cliente de 2023 que nadie anotó.
Reescribir tira esos motivos no documentados y los redescubre incidente a incidente. Ponte una regla: nada de reescribir hasta haber hecho tres cambios pequeños con éxito. Para entonces, o lo entiendes lo bastante para reescribirlo bien, o habrás descubierto que está bien como está.
Averigua qué es estructural
En cualquier sistema heredado, una parte pequeña hace casi todo el trabajo real y una parte grande es decoración: experimentos viejos, caminos muertos, funciones que nadie usa. Desde dentro parecen iguales.
Dos maneras baratas de distinguirlas. Mira qué cambia con más frecuencia, porque el código que se edita a menudo es donde vive de verdad el negocio. Y mira qué se ejecuta más. Todo lo que en un año no se ha editado ni ejecutado es candidato a borrarse, y borrarlo es la vía más rápida para que el resto se entienda.
Encuentra a quien se acuerda, antes de necesitarlo
Casi siempre queda alguien que estaba cerca cuando se construyó, no necesariamente quien lo escribió. Alguien de soporte que recuerda el incidente, un compañero que lo revisó, el cliente que pidió el requisito raro.
Habla con esa persona la primera semana, mientras tus preguntas son todavía ingenuas y baratas, y no en el tercer mes cuando estés atascado y tenso. Treinta minutos entonces ahorran días después, y su memoria empeora cada mes que esperas.
Haz un cambio pequeño y publícalo
Leer código desconocido enseña sorprendentemente poco; cambiarlo lo enseña todo. Elige algo trivialmente pequeño y llévalo hasta producción.
Aprenderás lo que de verdad necesitabas saber: cómo se construye, qué se rompe al tocarlo, si las pruebas significan algo, quién se entera. Ese es el mapa real y no está en ningún documento. Anota lo que aprendiste en ese primer cambio: eres la única persona que verá este sistema con ojos nuevos, y esa mirada desaparece en un mes.
Preguntas que la gente hace
¿Debo reescribir un sistema heredado?
Primero no. El trabajo ajeno parece malo porque ves sus cicatrices y ningún motivo; esa condición rara suele ser un arreglo no documentado. Haz tres cambios pequeños con éxito antes de plantearlo.
¿Cómo sé qué partes importan?
Mira qué cambia más y qué se ejecuta más. El código editado a menudo es donde vive el negocio; lo que en un año no se editó ni ejecutó es candidato a borrarse.
¿Qué hago la primera semana?
Busca a quien estaba cerca cuando se construyó —no necesariamente el autor— mientras tus preguntas son ingenuas, y lleva un cambio trivial hasta producción. Después anota lo aprendido.
