Lo que aprendí manteniendo código que no escribí
Tres años heredando sistemas de otros me enseñaron más sobre diseño que cualquier proyecto empezado de cero.
Escribir código nuevo enseña a escribir código. Mantener código ajeno enseña qué código sobrevive. Son dos habilidades distintas y solo la segunda se aprende leyendo decisiones que alguien tomó hace cuatro años sin dejar explicación.
El comentario que sí importa
Los comentarios que explican qué hace el código son ruido: el código ya lo dice. Los que valen oro explican por qué se descartó la alternativa obvia. "No usar bulk_update aquí: omite las señales que la facturación necesita." Ese comentario me ahorró un incidente.
Documenta las alternativas descartadas. El camino elegido ya está en el código.
La historia del repositorio es documentación
Cuando no hay documentación, el historial de cambios es lo único que queda. Un mensaje de commit que dice "arreglos" es una puerta cerrada; uno que describe el síntoma y la causa es un documento de diseño distribuido en el tiempo. Escribo mensajes pensando en quien haga arqueología dentro de tres años, que probablemente seré yo.
La reescritura casi nunca es la respuesta
Todo sistema heredado parece mal diseñado hasta que entiendes qué caso raro justifica cada rareza. La mayoría de esas rarezas son cicatrices de incidentes reales. Antes de proponer una reescritura, mi regla es poder explicar cada una: si no puedo, todavía no entiendo el sistema.
- Primero: instrumentar. No se puede mejorar lo que no se mide.
- Después: pruebas de las rutas críticas, aunque sean feas.
- Solo entonces: cambiar, en incrementos desplegables.
Esta forma de trabajar es más lenta de anunciar y bastante más rápida de terminar.