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…

Fig. Extract Class

Fig. Replace Method With Method Object

Fig. Replace Type Code With StateStrategy

(Enlace a la parte 2 de este artículo: Breve introducción a la Refactorización (Refactoring) (2/3). Justificación)

Otras entradas relacionadas con esta:

1. Breve introducción a la Refactorización (Refactoring) (2/3). Justificación
2. Breve introducción a la Refactorización (Refactoring) (3/3). Aplicación
3. Estimación software, una breve introducción (1/4)
4. Una breve introducción a la estimación software. El proceso (3/4)
5. Los puntos función. Una breve introducción a la estimación software (2/4)