Refactorización en la práctica: peligros y soluciones - Resumen y preguntas

Resumen

INTRODUCCIÓN

Refactorizar es una práctica muy importante dentro de las metodologías ágiles, como Extreme Programming. Implica hacer modificaciones en el código para así mejorar su estructura interna sin variar el comportamiento del mismo. Por tanto, no es una técnica para modificar la aplicación, o encontrar y corregir errores. Refactorizar más bien consiste en hacer cambios pequeños en el código pero sin variar su comportamiendo, siempre manteniendo el control y sin cometer equivocaciones. Se propone seguir ciertas técnicas matemáticas con el fin de reducir partes complejas del código en partes mucho más simples, y que a fin de cuentas, hacen lo mismo.

Aún así, es importante conocer que en la práctica hay que tener en cuenta ciertos factores que puedan entorpecer o complicar el proceso de refactorización. Factores como por ejemplo el factor humano, que al tener un exceso de celo en querer conseguir un diseño y código perfecto, se pierda demasiado tiempo en realizar infinitas refactorizaciones, o el hecho de estar trabajando en equipo, donde hay que llevar sumo cuidado en la sincronización de las tareas y escuchar a todos los miembros del equipo en sus posibles propuestas de rediseño o refactorización del código.

CARACTERÍSTICAS

Mediante la refactorización obtendremos en nuestro proyecto las siguientes características:

• Calidad: un código de calidad trata de un código sencillo y bien estructurado de forma que cualquiera pueda leerlo y entenderlo en poco tiempo. Esta calidad se obtiene gracias al continuo proceso de reflexión que se lleva a cabo sobre el código pudiendo corregirlo y simplificarlo.
• Eficiencia: gracias a la refactorización obtendremos un código eficiente al evitar la duplicación de código y al simplificarlo, ya que esto nos facilita la modificación y correcion de código y el añadir nuevas funciones.
• Diseño Evolutivo en lugar de Gran Diseño Inicial: se realizará un buen diseño a partir de un simple diseño inicial que sólo represente algunas funcionalidades. Esto se debe a que se va refactorizando el diseño y poco a poco se van añadiendo nuevas funciones haciendo un diseño más completo. El diseño inicial sólo contemplará algunas funcionalidades debido a que inicialmente no se suelen tener claros los requisitos.
• Evitar la Reescritura de código: hay que enfrentarse al código y refactorizarlo en vez de reescribirlo por no seguir los mismos estándares del código ya existente.

CONCLUSIONES

Refactorizar es una técnica muy útil ya que suele abordar uno de los puntos débiles de muchos de los proyectos software, el código.  En muchos proyectos se suele crear el código y comprobar que funcione, pero son pocas las ocasiones en las que se refactoriza el código, es decir, se trata de simplificar y estructurar de tal forma que sea lo más eficiente y claro posible, eliminando redundancias, clases, variables, etc….  Gracias a la posibilidad  de preparar el código para poder adaptarse a cambios en el sistema, esta técnica es empleada sobre todo en el desarrollo ágil de software.

Pero hay ciertos problemas asociados a esta técnica que hacen que algunos equipos no quieran hacer uso de la misma. Esto es debido a que la técnica de refactorizar no ofrece resultados a simple vista, y en muchas ocasiones, se suele pensar que no es útil, sin embargo mantener el código estructurado y simple, puede facilitar futuras pruebas y modificaciones, pudiendo adaptar el código del sistema a construir fácilmente cuando se producen cambios en los requisitos o especificaciones. Otro problema de la factorización es la necesidad de un buen entendimiento entre todo el equipo de desarrollo ya que un cambio por parte de un desarrollador a la hora de refactorizar, puede afectar al resto del equipo, esto puede hacer que el equipo se muestre reticente a refactorizar. Además los desarrolladores encargados de refactorizar pueden sentirse menospreciados por tener que realizar esta tarea y no la de crear código, aunque sea una tan tarea de suma importancia. Por último, un problema muy habitual de esta técnica, es que se emplea la refactorización de código pero no de forma asidua, de tal forma que tratar de refactorizar un código avanzado, amplio y con muchas funcionalidades, se vuelve una tarea demasiado costosa.

En conclusión, refactorizar es una técnica que requiere de un equipo comprometido y crea firmemente en que la refactorización ayuda a crear software de calidad y que se trata de una técnica muy valiosa.

Enlaces utilizados:

• http://www.willydev.net/descargas/WillyDev_Refactorizacion.pdf
• http://es.wikipedia.org/wiki/Refactorizaci%C3%B3n

Preguntas tipo test:

1. La refactorización:

1. Es una técnica en desuso
2. Es idea poco realista por su elevada complejidad
3. Se asemeja a las pruebas unitarias
4. Ninguna de las anteriores

2. Sobre la refactorización:

1. Consiste en tener el mínimo código aunque se pierda funcionalidad.
2. Se basa en simplificar y estructurar el código.
3. Motiva cambios en el código para cambiar la funcionalidad del mismo.
4. Ninguna de las anteriores

3. En refactorización, ¿qué es un “Bad Smell”?

1. Encontramos una parte del programa que no funciona y no sabemos encontrar el por qué.
2. Secciones de código que nos indican que el desarrollo funciona perfectamente y sin problemas.
3. Secciones de código que nos indican que el programa puede volverse problemático o inmanejable si seguimos desarrollándolo.
4. Ninguna de las anteriores.

4. La refactorización continua:

1. Consiste en refactorizar el código cada cierto intervalo de tiempo determinado.
2. Consiste en refactorizar cada vez que se acaba una parte del código, cuando está reciente.
3. Consiste en refactorizar el código al final de cada iteración.
4. Ninguna de las anteriores.

5. La realización de pruebas automáticas:

1. No es necesario en la refactorización, ya que no supone riesgo.
2. Es necesario en la refactorización, ya que el no realizar prueba conllevaría un alto riesgo en la refactorización.
3. Es necesario realizar pruebas automáticas, pero sólo en algunas partes de código.
4. Ninguna de la anteriores.

6. Los pasos de la refactorización son:

1. Pruebas, Herramientas, Formar sobre patrones de refactorización, refactorizar los principales fallos de diseño, refactorizar al final del desarrollo.
2. Pruebas, Herramientas, Formar sobre patrones de refactorización y arquitectura, refactorizar los principales fallos de arquitectura, refactorizar cada nueva funcionalidad.
3. Pruebas, Herramientas, Formar sobre patrones de refactorización y diseño, refactorizar los principales fallos de diseño, refactorizar cada nueva funcionalidad, refacorización continua al completo.
4. Ninguna de las anteriores.

7. La refactorización en el trabajo en equipo supone:

1. Coordinarse en el trabajo de refactorización, porque podrían modificarse archivos que están siendo modificados simultaneamente por otros desarrolladores.
2. Que si un miembro del equipo encuentra una idea diferente a la que se está llevando a cabo, comunicarlo en base a una posible refactorización.
3. Reunirse diariamente el equipo de desarrolladores para plantear las posibles refactorizaciones a llevar a cabo.
4. Todas son correctas.

8. La características de un código simple son:

1. Que el código funciones.
2. Que no haya código duplicado.
3. Que el código permita entender el diseño.
4. Todas las anteriores.