Breve introducción a la Refactorización (Refactoring) (2/3). Justificación

(Enlace a la parte 1 de este artículo: Breve introducción a la Refactorización (Refactoring) (1/3). Definición)
Una de las razones para refactorizar es ayudar al código a mantenerse en “buena forma”, ya que con el tiempo los cambios en el software hacen que este pierda su estructura, y esto hace difícil ver y preservar el diseño. Refactorizar ayuda a evitar los problemas típicos que aparecen con el tiempo, como, por ejemplo, un mayor número de líneas para hacer las mismas cosas o código duplicado.
Existen incluso posturas, como a la que comenta la metodología ágil XP, que afirman que la refactorización puede ser una alternativa a diseñar, codificando y refactorizando directamente, sin más. Sin llegar a extremos tan radicales y poco recomendables, sí que es cierto que una buena refactorización cambia el rol del tradicional del “diseño planificado”, pudiendo relajar la presión por conseguir un diseño totalmente correcto en fases tempranas, buscando sólo una solución razonable.
Otro aspecto importante es que ayuda a aumentar la simplicidad en el diseño. Sin el uso de refactorizaciones se busca la solución más flexible para el futuro, siendo estas soluciones, por lo general, más complejas y, por tanto, el software resultante más difícil de comprender y por ello de mantener. Además, ocurre que muchas veces toda esa flexibilidad no es necesaria, ya que es imposible predecir qué cambiará y dónde se necesitará la flexibilidad, forzado poner mucha más flexibilidad de la necesaria (síntoma de esto es la sobrecarga de patrones). Con la refactorización en lugar de implantar soluciones flexibles antes de codificar se hace después, tratando con diseños más simples sin sacrificar la flexibilidad.
(Enlace a la parte 3 de este artículo: Breve introducción a la Refactorización (Refactoring) (3/3). Aplicación)