El código heredado empeora con el tiempo

El código heredado no mejora con el tiempo. Empeora.

La semana pasada, pasé tres horas arreglando un error. Debería haberme tomado 20 minutos. El problema era un módulo de validación de 2019. Todo el mundo lo ignoraba porque "funciona". No funcionaba. Encontré un comentario TODO de 2020 dentro del archivo.

Muchas personas tratan el código heredado como una deuda opcional. Piensan que pueden pagarla cuando tengan tiempo. El código heredado es más bien como el moho. Se extiende. Contamina otras partes de tu sistema. Cuanto más tiempo lo ignores, más caro será limpiarlo.

Esto crea un ciclo vicioso:

  • Heredas un proyecto desordenado.
  • Añades una sentencia if más para que tu funcionalidad funcione.
  • Seis meses después, alguien más hace lo mismo.
  • Un año después, el archivo tiene 800 líneas y cero pruebas.

Este código que "funciona" tiene costes ocultos:

  • La velocidad de desarrollo disminuye. Pasas más tiempo leyendo el contexto que escribiendo código.
  • Los errores aumentan. Arreglar una cosa rompe otra.
  • La incorporación (onboarding) se vuelve difícil. Los nuevos desarrolladores luchan por entender por qué la lógica está duplicada en todas partes.

Presta atención a estas señales de alerta:

  • Comentarios inútiles o engañosos.
  • Lógica de negocio duplicada en diferentes archivos.
  • Dependencias circulares y alto acoplamiento.

No intentes reescribirlo todo. Las reescrituras completas fallan el 80% de las veces. Pasas meses reconstruyendo lo que ya existe mientras el negocio espera nuevas funcionalidades.

Utiliza la refactorización incremental con pruebas de caracterización:

  • Captura el comportamiento actual con pruebas, incluso si es extraño.
  • Refactoriza sin cambiar ese comportamiento.
  • Repite hasta que el código sea legible.
  • Solo entonces cambia el comportamiento con pruebas reales.

Sigue estas reglas para evitar trampas:

  • Nunca refactorices sin pruebas.
  • No cambies el comportamiento durante una refactorización. Un error podría ser una funcionalidad no documentada de la que depende un cliente.
  • No toques el código que no da problemas. Si un módulo no ha cambiado en tres años y no causa inconvenientes, déjalo como está.

Enfoca tu energía en el código que tocas con frecuencia.

Fuente: https://dev.to/taina_costa_f/legacy-code-nao-envelhece-como-vinho-quanto-mais-espera-pior-fica-132h