Refactorizacion: camino hacia la calidad

Articulo cedido por refactoring.blog-city.com

Cuando uno se sienta delante de un puesto para desarrollar una nueva funcionalidad, en principio, siempre trata de conseguir que su código de la mayor calidad posible. El primer problema con el que nos encontramos es lo que entendemos por calidad. Probablemente hayamos leído muchos artículos de calidad del software que relacionan la calidad con el número de errores que nuestro software presenta. Cierto, es importante que nuestro software no falle, pero esta claro que siendo muy importante necesitamos otras características para saber si un software es de calidad. Y estoy seguro que en alguna ocasión y leyendo el código de alguna aplicación que se nos pedía modificar hemos podido comprobar que era muy mejorable aunque no fallara.

Por ese motivo han surgido estándares de codificación que hacen nuestros desarrollos más legibles y patrones que permiten solucionar de una forma elegante y sencilla problemas que pueden llegar a tener soluciones realmente complicadas. Y en este sentido la simplicidad y claridad son características importantes de la calidad. Conseguir esa sencillez y claridad es complicado:

   Es fácil tener una idea complicada. 
   Es muy, muy complicado tener una idea simple. 
                                       -- Carver Mead

Pero los patrones tienen algunos problemas. Es muy fácil aplicar sobre-ingeniería a nuestros desarrollos por intentar aplicar patrones que no serían necesarios. Los patrones en muchos casos nos enseñan a afrontar problemas de diseño generales, pero no nos sirven para afrontar los problemas de más fino detalle, como puede ser cuando nuestro método tiene demasiados parámetros, o cuando sería mejor eliminar una herencia que no se justifica, etc..

Intentar definir calidad puede ser demasiado ambicioso pero podemos partir de una serie de reglas que nos acercaran a nuestro objetivo de calidad. Una de la mejores enumeraciones de reglas es la que hace Kent Beck.

• El conjunto de pruebas de la funcionalidad de nuestro Software funcionan correctamente.
• No existe código duplicado.
• El código permite entender el diseño.
• Minimiza el numero de Clases y de Métodos.

Para llegar a conseguir este objetivo tenemos dos posibilidades. Una es conseguir que nuestro diseño respete todas estas reglas o intentar que nuestro diseño evolucione constantemente hacia estas reglas. Refactorizar implica aplicar la segunda aproximación que se basa en dedicar tiempo durante el desarrollo para pensar que tenemos que cambiar o modificar para que nuestro desarrollo sea de mayor calidad. Es similar al procedimiento que aplicamos en Matemáticas cuando intentamos reducir nuestras formulas para hacerlas mas sencillas. Es posible que el primer diseño no sea el mejor y teniendo delante un diseño y su desarrollo seguro que podremos mejorarlo.

Refactorizar no es un concepto nuevo, probablemente ya estemos aplicando refactorización en nuestro proyectos, no obstante es importante aplicarla de una manera metódica y conocer los tipos refactorizaciones que se están definiendo en la actualidad.

Refactorizar es el proceso de modificar el código de un desarrollo para mejorar su estructura interna sin alterar la funcionalidad que ofrece el desarrollo externamente.

La refactorización es una de las prácticas que se incluyen en Extreme Programming.

Para comenzar a Refactorizar es imprescindible que exista un desarrollo y que ese desarrollo tenga asociado código de prueba que nos permita saber en cualquier momento, pasando las pruebas automáticas, si el desarrollo sigue cumpliendo los requisitos que implementaba.

Si no existen estas pruebas será realmente complicado llevar a cabo refactorizaciones, dado que no podremos conocer si nuestras modificaciones han hecho que el desarrollo deje de funcionar. Pero eso no solo nos afectara a la hora de Refactorizar, sin o también a la hora de intentar modificar nuestro desarrollo para añadir una nueva funcionalidad, dado que no sabremos si el nuevo código añadido ha podido influir en que el desarrollo deje de funcionar en otros casos.

Si no poseemos pruebas muy probablemente adoptemos posiciones defensivas (“Si funciona no lo toques”) dado el riesgo que conllevara modificar el software, mayor cuanto mas grande sea el desarrollo. El problema de las pruebas es que no suelen estar automatizadas y que se suelen dejar en último lugar con lo que suelen en muchos no hacerse exhaustivamente. Discutir como afrontar el desarrollo de las pruebas seria otro tema pero si que es necesario conocer que para llevar a cabo un proceso de refactorización durante el desarrollo necesitaremos que las pruebas se vayan realizando según se desarrolla (Test Development Driven).

Suponiendo que nuestro código tiene pruebas, el siguiente paso es saber cuando deberemos aplicar refactorización. Generalmente es un proceso reactivo y generalmente un consecuencia de detectar que nuestro codigo no es de calidad o que necesitaria una reestructuracion para permitir una nueva funcionalidad.Por este motivo ha refactorización suele aplicarse al añadir una nueva funcionalidad al damos cuenta que si reestructuramos el código existente sería mucho más fácil añadir dicha funcionalidad. No obstante si lo hacemos constantemente aplicandola cuando detectamos que nuestro código tiene un indicio de poca calidad ( como por ejemplo que exista código duplicado) , comprobaremos que estaremos consiguiendo que nuestro código sea de mucha calidad.

Para saber si nuestro código necesita una refactorización podemos comprobar la lista de “Bad Smells”. Un Bad Smell es un indicio de que existe código de poca calidad. En el libro de Martin Fowler (Refactoring: Improving he Desing of Existing Code) existe una lista de Bad Smells.

Una vez identificado el Bad Smell deberemos aplicar una refactorización que permita corregir ese problema de calidad que hemos detectado. Existen herramientas en Ant como checkstyle que permiten automatizar la identificación de estos Bad Smell. Ejemplos de Bad Smells son que un método tenga un número elevado de líneas de código, o que tenga un elevado número de parámetros.

Al aplicar la refactorización podemos utilizar las funcionalidades que nos ofrecen los IDE. Las ultimas versiones de los entornos de desarrollos ofrecen refactorizaciones automáticas que simplifican llevar a cabo refactorizaciones. Suelen ofrecer el cambio de nombre de clases, de métodos, extracción de código a un nuevo método y muchas mas refactorizaciones.

El libro de Martin Fowler ofrece una lista de refactorizaciones aceptadas como el ABC de las refactorizaciones.

El problema de abordar la refactorización es que supone un esfuerzo que no se ve compensado por ninguna nueva funcionalidad y por ese motivo es fácil no realizar. Sin embargo si introducimos la refactorización como una de las prácticas que debemos aplicar a lo largo del desarrollo cuando finalizamos cada funcionalidad es una de las mejores formas de conseguir que nuestro código sea de calidad y la experiencia dice que este tiempo que vamos empleando en cada funcionalidad será recuperado con creces según el proyecto avance.