Cosas que nunca deberías hacer, parte I (2000)

Artículo original ↗ Discusión en Hacker News ↗

Reescribir un gran sistema de software desde cero suele verse como una salida tentadora del código heredado y desordenado, pero los comentaristas sostienen que por lo general subestima el valor incorporado en el sistema existente y el tiempo necesario para alcanzar la paridad de funcionalidades. Muchos enfatizan la refactorización incremental, las pruebas sólidas y la documentación como caminos más seguros, al tiempo que reconocen casos raros en los que el código está tan roto, los requisitos o la tecnología han cambiado tanto, o las restricciones de rendimiento son tan severas, que una reescritura completa puede justificarse. La conversación destaca el atractivo psicológico de los proyectos greenfield, los riesgos empresariales de las reescrituras estancadas y la necesidad de distinguir entre codebases pequeñas y reescribibles y sistemas críticos con millones de líneas de código.

Sentimiento general hacia las reescrituras completas

  • Muchos comentaristas siguen de acuerdo en que las reescrituras completas suelen ser arriesgadas y a menudo están impulsadas más por la psicología que por la necesidad.
  • Otros argumentan que en sistemas más pequeños (decenas de miles de líneas de código) o en codebases realmente patológicos, empezar de cero puede ser la opción más pragmática.
  • Hay críticas a tratar “nunca reescribas” como una regla universal; el contexto y la escala importan.

Por qué las reescrituras son tan tentadoras

  • El trabajo greenfield es más divertido; evitas las restricciones heredadas, el dolor operativo y la historia enmarañada.
  • A menudo los desarrolladores creen que pueden “hacerlo bien esta vez”, armados con los requisitos conocidos y la perspectiva del retroceso.
  • Es más fácil leer tu propio estilo que el de otros, así que el código existente parece peor de lo que puede ser.
  • Las reescrituras pueden restaurar una sensación de autonomía y control, a veces de forma inconsciente.

Argumentos a favor de refactorizar y del cambio incremental

  • La refactorización incremental preserva un sistema en funcionamiento, permite desplegar continuamente y reduce el riesgo.
  • Eliminar código muerto, aislar las áreas malas y mejorar gradualmente la arquitectura se considera más sostenible.
  • Las pruebas completas y la documentación confiable reducen significativamente el impulso de reescribir al hacer los cambios más seguros.
  • Algunos comparan refactorización vs. reescritura con reforma vs. revolución: las revoluciones suelen acabar mal, pero negarse a reformar también lleva a explosiones.

Cuándo las reescrituras pueden estar justificadas

  • Cuando el sistema existente es un “monolito/obelisco enfadado” en el que los cambios rompen la producción de forma impredecible y la velocidad se ha desplomado.
  • Cuando gran parte de la funcionalidad existente ya no se necesita, de modo que el nuevo sistema es sustancialmente más simple.
  • Cuando el lenguaje/framework/arquitectura original bloquea fundamentalmente el rendimiento o la evolución requeridos.
  • Cuando la calidad del código es “tipo dos mala”: sin estructura, sin control de स्रोत, archivos enormes únicos, caos de copiar y pegar.
  • Varios informan de reescrituras exitosas de 50–100K LOC realizadas por equipos experimentados que conocían en profundidad el dominio.

Fracasos, escala y factores organizativos

  • Las reescrituras grandes de varios años a menudo se estancan: los equipos terminan manteniendo tanto el sistema viejo como el nuevo en producción.
  • Se dan ejemplos de reescrituras de grandes empresas que languidecen, sobreingeniería del segundo sistema y equipos que simplemente no pueden ejecutar un reemplazo greenfield complejo.
  • Algunos señalan que reescribir puede ser un movimiento profesional encubierto: iniciar la reescritura, disfrutar de la programación greenfield, marcharse antes de que lleguen el soporte y los compromisos difíciles.

Otros temas

  • Debate sobre si el código es más difícil de leer o de escribir; la mayoría coincide en que la comprensión profunda es lo difícil.
  • Se discuten los frameworks como una forma de estandarizar idioms y facilitar la incorporación; otros responden que los frameworks también pueden ser malos y no son una solución universal.