Refactorizar (o Refactoring) es realizar una transformación al software preservando su comportamiento, modificando sólo su estructura interna para mejorarlo. El término es de Opdyke, quien lo introdujo por primera vez en 1992, en su tesis doctoral.
Más definiciones, en 2001 Tokuda y Batory las definieron como una transformación parametrizada a un programa preservando su comportamiento, modificando automáticamente el diseño de la aplicación y el código fuente subyacente. Decía Fowler que eran cambios realizados en el software para hacerlo más fácil de modificar y comprender, por lo que no son una optimización del código, ya que esto en ocasiones lo hace menos comprensible, ni solucionar errores o mejorar algoritmos. Las refactorizaciones pueden verse como un tipo de mantenimiento preventivo, cuyo objetivo es disminuir la complejidad del software en anticipación a los incrementos de complejidad que los cambios pudieran traer.
Aunque hay varios catálogos de refactorizaciones el más famoso es el de Fowler, que se mantiene en la página www.refactoring.com. Algunos ejemplos de las refactorizaciones que podéis encontrar en este catálogo: Add Parameter, Change Bidirectional Association to Unidirectional, Consolidate Conditional Expression, Extract Class, Introduce Null Object, Move Method, etc.
Y para terminar de definir el concepto, os dejo más abajo el diseño UML de algunas refactorizaciones…
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024
Pingback: Herramientas de refactorización | Fábricas de Software
Pingback: Herramientas de refactorización | Fábricas de Software
Pingback: Una lista de herramientas de calidad software imprescindibles - Javier Garzás, sobre calidad software y otros temas relacionados
Pingback: Breve introducción a la Refactorización (Refactoring) (2/3). Justificación - Javier Garzás, sobre calidad software y otros temas relacionados
Pingback: Ejemplos y buenas prácticas para descomponer historias de usuario en tareas (parte 1 de 2) - Javier Garzás, sobre calidad software y otros temas relacionados
Pingback: Qué es UML y por qué es tan sumamente importante (seas informático o no) saber interpretar diagramas UML - Javier Garzás | Javier Garzás
Pingback: Tres maneras muy típicas de fracasar con un proyecto ágil - Javier Garzás | Javier Garzás
Hola Javier, muchas gracias por la informacion, es clara y puntual