El objetivo de refactorizar y reescribir es "limpiar" el sistema mediante la mejora de la legibilidad, estructura y la claridad del código. Un código limpio es más fácil de mantener y mejorar. Sin embargo, en muchas ocasiones los equipos pasan en cierto tiempo decidiendo entre los dos enfoques.
Michael Dubakov sugiere las siguientes razones por las qué el código se deteriora con el tiempo:
- Más y más funcionalidades. Esto conduce a una mayor complejidad.
- Atajos e improvisaciones para apoyar cosas como "Necesitamos esta pantalla de búsqueda en agosto. ¡Y punto final!"
- Rotatividad. Los nuevos desarrolladores no saben todas las decisiones y las ideas clave detrás de la arquitectura. Inevitablemente, el conocimiento se pierde en la transición.
- Crecimiento del equipo. Más gente, menos comunicación. Menos comunicación, mas decisiones.
Michael sugiere que a pesar de que refactorizar y reescribir llevan a un código más limpio, ambas técnicas llevan al caos al sistema existente. Refactorizar es una actividad incremental, ya que afecta sólo una parte del sistema a la vez. Eso crea caos en el plano local, que puede ser fácilmente contenido. Por otro lado, reescribir es un cambio más invasivo, que resulta en un gran caos en el sistema. Debido a su mayor impacto, el período de estabilización de reescribir y mucho mayor que el de la refactorización.
Tenemos el sistema antiguo durante la reescritura, por lo que el caos es constante. Después del "release", el caos aumenta de manera significativa. Muchos nuevos (y viejos) errores y comportamientos extraños son esperados y así el período de estabilización es mayor.
Peter Schuh sugiere que algunas veces los equipos usan esas palabras de forma cambiada, resultando en una mayor confusión y caos. Los equipos deben entender que reescribir es una propuesta más arriesgada en comparación con refactorizar y por lo tanto debe utilizarse la terminología correcta. Según él,
Es sólo semántica. Bien, es sólo semántica hasta que alguien se lastima! Reescribir código es algo arriesgado y a veces doloroso. No siempre termina bien. Si ejecutamos una reescritura, pero lo llamamos refactorización y las cosas no salen "redonditas", ningún usuario se va a detener a pensar en la semántica. Ellos sólo van a tener miedo la próxima vez que oigan la palabra refactorizar.
Guido AJ Stevens hace una observación interesante. Él sugiere que la cuestión no es elegir entre refactorizar y reescribir, pero si entre o: refactorizar, o: reescribir y refactorizar. Él sugiere que, incluso cuando el equipo decide reescribir, eventualmente tendrán dos sistemas en paralelo. El antiguo sistema, que puede requerir refactorización el nuevo sistema que está siendo reescrito. Esa combinación crea una tarea extremadamente compleja. Según él,
Mantener una base de código que está envejeciendo, y escribir un nuevo sistema, puede "chupar" sus recursos. Su equipo se divide y va a incurrir en atrasos. Tenemos que planificar y ejecutar cuidadosamente la transición. Mientras tanto, sus competidores, no tienen el problema de corto plazo para ponerel producto en el mercado, tratarán de tomar a sus clientes. Si mantenemos esa realidad en vista e incluso apostamos por la reescritura, tenemos la oportunidad de tener éxito.
Naresh Jain tiene las siguientes sugerencias específicamente para el código legado. Refatorizar cuando el código es difícil de entender y el equipo no está seguro de lo que hace. Reescribir cuando está claro lo qué hace el código, pero es difícil de entender.
Así, refactorizar es la forma preferida de mejorar el sistema de forma incremental. Sucede en paso lento, aumenta la calidad con pequeñas y constante mejoras. Reescribir tiene sus ventajas, pero en muchas situaciones es una opción más arriesgada y los equipos nunca están seguros del resultado. Según lo propuesto por Joel on Software,
Es importante recordar que cuando se comienza desde cero no hay absolutamente ninguna razón para creer que vamos a hacer un trabajo mejor que la primera vez.
