0.12 ¿qué es refactoring?

Refactoring es un tipo de reestructuración de código que se aplica en desarrollos orientados a objetos y que se define como “el proceso de cambiar el software de un sistema de manera que no altere su comportamiento externo pero mejorando su estructuración interna” (Fowler

Como cualquier reestructuración de código, el refactoring tiene como objetivo limpiar el código para que sea más fácil de entender y modificar. Esta acción consigue, como efecto lateral, mejorar el diseño del software y ayudar a encontrar errores ocultos que puede que no hayan salido a la luz todavía.

Existen una enorme variedad de técnicas para hacer refactoring (Fowler, 2000), que pueden agruparse en las siguientes categorías:

• (Re)Composición de métodos. En esta categoría se incluyen las técnicas para que se basan en acortar métodos demasiado largos (de acuerdo a la funcionalidad), sustituir llamadas a los métodos por su código, etc.
• Movimiento de características entre clases. Bajo esta categoría se incluyen técnicas para reasignar las responsabilidades de una clase a otra, por ejemplo, separar una clase en varias, eliminar una clase, introducir uno o más nuevos métodos a una clase, etc.
• Reorganización de datos. Esta categoría incluye las técnicas de refactoring que permiten facilitar el trabajo con datos, como la creación de accesotes para consultar los propios atributos dentro de una clase, reemplazar ciertas estructuras de datos por objetos, reemplazar literales por constantes, etc.
• Simplificación de expresiones condicionales. Esta familia de técnicas pretende facilitar la comprensión, depuración y mantenimiento del software mediante la simplificación de las estructuras condicionales, por ejemplo dividiendo una condicional compleja en varias, eliminando expresiones condicionales redundantes en estructuras complejas, etc.
• Simplificación de las llamadas a los métodos. Las técnicas de esta categoría pretenden simplificar la interfaz de una clase para que sea más fácil de usar. Incluye algunos refactorings como cambiar el nombre de métodos, eliminar o añadir parámetros a las signaturas de los métodos, etc.

Reorganización de la jerarquía generalización. Bajo esta categoría se engloban las técnicas que permiten mover métodos a lo largo de la jerarquía de herencia, como añadir un método de subclases a una superclase, añadir constructores a las superclases o dotar su cuerpo de mayor funcionalidad, crear nuevas sub/superclases, etc.

Métafora de los dos sombreros

Lo ideal es hacer el refactoring sobre la marcha, según se va escribiendo código. La idea la explica perfectamente la metáfora de los dos sombreros. Según esta metáfora, un programador tiene a su disposición dos sombreros. Uno de ellos etiquetado "hacer código nuevo", y el otro con la etiqueta "arreglar código".

Cuando empieza a programar, se pone el sombrero de "hacer código nuevo". Se pone a programar hasta que tiene hecha alguna parte del programa y le hace una primera prueba, compilando y viendo que funciona. Deja esa parte del programa funcionando. Sigue con el mismo sombrero puesto y se prepara para seguir haciendo su programa. En ese momento ve un trozo de código que podría reaprovechar si estuviera separado en otra función o ve cualquier otra cosa que si estuviera hecha de otra forma, le facilitaría la tarea de seguir con su programa. O simplemente ve algo que no le convence cómo está hecho. En ese momento se cambia el sombrero. Se quita el de "hacer código nuevo" y se pone el de "arreglar código".

Ahora sólo está arreglando el código. No mete nada nuevo. Echa un rato cambiando código de sitio, haciendo métodos más pequeños, etc, etc. Al final deja el código funcionando exactamente igual que antes, pero hecho de otra manera que le facilita seguir con su trabajo. Nuevamente se cambia el sombrero por el de "hacer código nuevo" y sigue programando.

La idea es hacer código nuevo a ratos, arreglar código existente a ratos. Tener claramente qué se está haciendo en cada momento. Si añadimos código nuevo, NO arreglamos el existente. Si estamos arreglando el existente, NO añadimos funcionalidades nuevas. La idea también es arreglar el código con frecuencia, cada vez que veamos que algo no está todo lo bien hecho que debiera. Es decir, hacer refactoring sistemáticamente.

Ventajas de hacer refactoring

Cualquier programador con un poco de experiencia sabe que nunca se diseña bien el código a la primera, que nunca nos dicen al principio todo lo que tiene que hacer el código, que nuestros jefes, según vamos programando y van viendo el resultado van pidiendo cosas nuevas o midificaciones, etc.

El resultado de esto es que nuestro código, al principio, puede ser muy limpio y estar bien organizado, siguiendo un diseño más o menos claro. Pero según añadimos cosas y modificaciones, cada vez se va "liando" más, cada vez se entiende pero y cada vez nos cuesta más depurar errores.

Si vamos haciendo refactoring sistemáticamente cada vez que veamos código feo, el código se mantiene más elegante y más sencillo. En fases más avanzadas de nuestro programa, seguirá siendo un código legible y fácil de modificar o de añadirle cosas.

Aunque inicialmente parece una pérdida de tiempo arreglar el código, al final del mismo se gana dicho tiempo. Las modificaciones y añadido tardan menos y se pierde mucho menos tiempo en depurar y entender el código.