(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)
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
El principal problema que yo le veo a la refactorización es saber cuando parar… si refactorizamos demasiado es muy posible que compliquemos tanto el diseño que pueda ser mas difícil de entender que el diseño del que partimos (y hacer el código menos entendible no es una buena práctica).
Como comentas, la sobrecarga de patrones sería un ejemplo de este tema.
Un saludo
Pingback: Breve introducción a la Refactorización (Refactoring) (1/3). Definición - Javier Garzás, sobre calidad software y otros temas relacionados