Refactoring

Hace tiempo que me preguntan que es todo este tema del Refactoring y aquí hago una pequeña explicación de lo que es. También os recomiendo el libro "Refactoring -> Improving the Design of Existing code" que lo explica muy bien. Está escrito por Martin Fowler, y ya tengo varios de sus libros en mis estanterías, así que os recomiendo su lectura, al igual que el que comenté en su día "Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series)". El tema del Refactoring, es una técnica que se utiliza en la ingenieria del software para reestructurar el código fuente, alterando su estructura interna, sin cambiar su comportamiento externo. Por lo tanto hacer que el código sea más fácil de entender y extender. Evitamos soluciones Quick & Dirty i mejoramos el código sin cambiar la funcionalidad. Para aplicar Refactoring, no consiste ir formateando el código para que quede más bonito, consiste en analizar muy bien el código e ir encontrando patrones dentro de lo que escribimos, es decir encontrar lo que llamamos "Bad Smells in code".

Los ejemplos que se me ocurren ahora són por ejemplo el Shotgun Surgery y la envidia de capacidades. El shotgun Surgery por ejemplo consiste en que si tenemos que modificar algo, tenemos que hacer lo mismo en N clases, y por lo tanto puede ser que algún día se nos olvide hacerlo, con el consiguiente fallo. Y la envidia de capacidades consiste en que si tenemos una clase que accede mucho a los métodos de otra clase, a lo mejor es que tiene mucha envidia, y realmente esos métodos tendrían que ir en la primera clase.

En los enlaces de interés encontrareis buenos resúmenes sobre los "Code smell", pero simplemente consiste en tenerlos muy claros, y saber identificarlos. Los más comunes por ejemplo Data Clumps, Switch, Clase perezosa y Comentarios.

Data Clumps: Consiste en que si siempre pasamos los mismos 4 argumentos a nuestra función, a lo mejor es que hay una relación más estrecha y necesitamos generar un tipo de datos.

Switch: La POO es una ataque al "case". La Programación estructurada no soporta el polimorfismo, y se pueden reemplazar por tipos con métodos virtuales. El uso de Switch es un sintoma de que no estoy aprovechando el polimorfismo.

Clase perezosa: Es una clase que no hace nada, que no tiene comportamiento. A lo mejor sus métodos están en otras clases y a lo mejor las otras clases están padeciendo envidia de capacidades????. Esto es un síntoma de que algo no va bien.

Comentarios: Poner el comentario que es un candidato a una función, crea la función!. A lo mejor crear comentarios puede ser que nuestro código no sea tan bueno. Hay que comentar el propósito de las cosas, no comentar lo que hacer el código porque eso ya se puede leer en él. Hay que evitar hacer cosas redundantes y sobretodo el DRY.

Algunas categorías de refactorings:

• Composing Methods.
• Moving Features.
• Organizing Data.
• Simplifying Conditions Expressions.
• Simplifying Method Calls.
• Dealing with Generalization.
• Big Refactorings.

Simplificar llamadas a métodos, de esta manera conseguimos que se pueda leer mejor el código. Análisis intuitivo y que cada objeto tenga su rol y seguir el diálogo entre objetos. Crear métodos deprecated, y sobretodo tener en cuenta que el Refactoring no es cambiar el código. Como podéis ver hay toda una filosofía detrás de la refactorización de código, y podréis encontrar muchos ejemplos ilustrados en el libro de Martin fowler.

• Enlaces de interés:

http://sourcemaking.com/refactoring
http://es.debugmodeon.com/articulo/categorizacion-de-code-smells