Refactorización de código

Aprovechando que acabamos de escribir un artículo tratando los olores del código fuente no podíamos dejar pasar la ocasión para escribir sobre refactorización, un conceptos íntimamente relacionado.

Refactorizar código

¿Qué es la refactorización?

Refactorizar es la acción de modificar el código fuente de una aplicación sin alterar su comportamiento con el objetivo de mejorarlo. Esta acción no viene provocada por la aparición de bugs, sino por la posibilidad de mejorar su calidad mediante la modificación o sustitución del código en el que se han utilizado prácticas no recomendables.

Objetivo de la refactorización

A priori puede parecer bastante razonable cuestionarse por qué querríamos modificar el código fuente de una aplicación que aparentemente funciona bien. Es una duda muy válida si tenemos en mente una aplicación sobre la que no planeamos realizar cambios futuros, mejor invirtamos nuestro valioso tiempo en otra tarea.

El objetivo de la refactorización es facilitar el mantenimiento y la extensibilidad de una aplicación. Todo desarrollador con suficientes años de experiencia y que ha participado en varios proyectos se ha enfrentado a aplicaciones en las que cambias aquí y aquello deja de funcionar, o en las que un cambio que en principio debería ser sencillo ocupa muchísimo tiempo. Situaciones como estas pueden verse generadas por múltiples motivos, dese proyectos mal diseñados hasta aplicaciones que han sufrido tantas modificaciones que no tienen nada en común con la versión inicial, sin olvidarnos de lo dañino que puede ser un desarrollador sin la suficiente experiencia al que no se le presta la atención necesaria para asegurar la calidad de su trabajo. Pues bien, la refactorización se realiza para corregir y con ello evitar o minimizar este tipo de situaciones, y que a medida que el software crezca o mute no se convierta en un gigantesco castillo de naipes.

Cuándo refactorizar

Los boys scouts tienen una sencilla pero efectiva regla: dejar el campo más limpio de lo que lo encontraron. Es una muy buena regla que podemos aplicar también al desarrollo del software: dejar el código fuente más limpio de lo que lo encontramos.

Existen una una serie de factores que nos indican que un código es candidato a ser refactorizado, en esos casos se suele decir que el «código huele». En el artículo ¿A qué huele el código fuente? os contamos qué significa que un código huele y los principales olores para que seáis capaces de detectarlos.

Cuando nos enfrentamos a un código oloroso, una práctica muy habitual es realizar el mínimo cambio necesario, comprobar que funciona, cerrar los ojos y seguir con la siguiente tarea. Esto no hace más que agravar el problema, de forma que si lo hacemos repetidamente nos encontraremos con el castillo de naipes del que hablábamos: un proyecto insostenible que será un agujero negro de recursos y foco de conflictos.

Por lo que hemos visto hasta ahora, parece que solo debemos refactorizar cuando trabajamos sobre aplicaciones en un estado de desarrollo más o menos avanzado y en las que detectamos mal olor. Sin embargo existe una situación en la que refactorizar es aun más importante: mientras estamos desarrollando. Cada vez que damos por concluido un bloque de código debemos asegurarnos de que es un código limpio, sin olores, y en caso de no ser así refactorizar antes de pasar al siguiente. Pensemos por un momento en lo «caótica» que es la acción de programar, no lo hacemos de forma lineal sino que estamos continuamente avanzando y retrocediendo: cambiamos una función, escogemos otro nombre para una variable, creamos un nuevo método extrayendo parte del contenido del otro, sustituimos esa estructura que no nos convence, reescribimos aquella parte del código que es tan enrevesada, etc. Así que tras terminar de dar forma a la última línea de la funcionalidad en la que estamos trabajando, debemos asegurarnos que entre tantas idas y venidas el código está impecable.

Conclusión

Tanto si nos enfrentamos a un proyecto ya existente como si estamos creando algo nuevo, la refactorización debe convertirse en parte de nuestra rutina de desarrollo. Aunque en un primer momento a alguien le pueda parecer que estamos gastando el tiempo, realmente estamos realizando una inversión de futuro que os aseguro que merece la pena hacerla.

¿Y tú cómo lo ves? ¿ya integras la refactorización en tu flujo de trabajo? ¿crees que no sirve para nada? Cuéntanos tu experiencia en los comentarios.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *