(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)
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Truco (con IA o sin ella) para espiar (legalmente) a tu competencia - 6 marzo, 2025
- Lo que NO te aconsejo hacer si quieres que SI se valore tu conocimiento - 27 febrero, 2025
- Como una PIZZA te puede dar una clase magistral de IA - 20 febrero, 2025
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