Cómo decidimos cuándo refactorizar y cuándo reescribir
Todo desarrollador se enfrenta a este momento.
La base de código es lenta. Añadir nuevas funcionalidades toma demasiado tiempo. Las nuevas incorporaciones tienen dificultades para entender el sistema. Alguien acaba sugiriendo una reescritura completa.
El equipo suele dividirse en dos grupos. Un grupo quiere empezar de cero. El otro grupo teme el fracaso de reescrituras pasadas. Ambos bandos tienen puntos válidos.
Una reescritura no es una solución mágica. A menudo tarda más de lo previsto. Terminas manteniendo dos sistemas a la vez. Incluso podrías repetir los mismos errores en la nueva versión.
Una reescritura tiene sentido en estos casos específicos:
• El modelo de datos es fundamentalmente incorrecto para el negocio. • La tecnología está obsoleta y no recibe actualizaciones de seguridad. • Las necesidades del negocio han cambiado tanto que el sistema original es obsoleto. • Nadie en el equipo actual entiende cómo funciona el sistema.
Aun así, no realices un reemplazo de tipo "big bang". Utiliza el patrón strangler fig. Construye el nuevo sistema pieza por pieza junto al antiguo.
La mayoría de las veces, lo que realmente necesitas es refactorizar.
La refactorización es la opción correcta cuando:
• Aún puedes añadir funcionalidades, aunque sea lento. • El equipo entiende el código actual. • El desorden se limita a módulos específicos. • El negocio no puede dejar de lanzar nuevas funcionalidades.
Antes de elegir, pregunta por qué el código se volvió malo.
Si el problema es la deuda técnica, refactoriza las peores partes. Si el problema es la falta de revisiones de código o una mala cultura, una reescritura no ayudará. Simplemente construirás un nuevo desastre con los mismos viejos hábitos.
Hazte estas preguntas antes de decidir:
• ¿Podemos arreglar las peores partes de forma aislada? • ¿Está el modelo de datos roto para las necesidades actuales del negocio? • ¿Qué conocimiento perderemos si empezamos de cero? • ¿Tiene el negocio la estabilidad necesaria para gestionar una transición larga?
Empezar de cero se siente bien. Terminar la reescritura es la parte difícil. La mayoría de las veces, un plan de refactorización estructurado es más seguro y eficaz.
Fuente: https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk