En los últimos años el refactoring se ha transformado en una técnica core del desarrollo de software. No por nada Martin Fowler escribió un libro dedicado al tema el año 99 y ha generado distintas charlas.
Pero ¿qué es el refactoring?. Es una técnica que permite cambiar el interior de una rutina de código, sin alterar su comportamiento al exterior. Esto es la base de lo que se conoce como el ciclo de TDD (Red->Green->Refactor).
Ahora, parece ser que el refactoring se encuentra muy ligado al TDD y que su uso queda relegado a dicha práctica. Sin embargo, hemos visto a lo largo de nuestros desarrollos que también se hace necesario refactorizar en otras instancias, no necesariamente asociadas al TDD, pero siempre relacionadas a un testeo profundo. De ahí vienen las preguntas Cuándo y Cómo.
Cuándo debo refactorizar? Basándonos en una reciente charla de Martin Fowler sobre “Refactoring Workflows”, en EXE estamos instaurando como política, al menos en el área de desarrollo de productos, que SIEMPRE se debe refactorizar, un poco aplicando la regla de los Scouts, de dejar siempre más limpio de lo que encontramos. A veces son pequeñas mejoras, pero sumadas generan una base de código más limpia y fácil de entender.
Otro momento para refactorizar es previo a la implementación de alguna funcionalidad. Un escenario bastante común aquí es que podemos encontrarnos con código legado de baja calidad, poco claro, el cual debemos reestructurar para hacer que la implementación de esta nueva funcionalidad sea más económica
También hemos identificado un flujo particular de refactorización: Para entender el código que estamos tomando. No es raro tener que reestructurar código de manera de entender lo que éste hacía. Esto apoyado de una estrategia de testing es bastante más productivo.
Finalmente, tal como lo expuso Martin Fowler, nos hemos visto en situaciones donde el refactoring debe ser una tarea “planificada”. Este no es el escenario ideal ya que, como dijimos inicialmente, el refactor debe ser una tarea constante, no algo planificado. Siempre será mejor refactorizar poco pero constantemente, que refactorizar como una actividad planificada de proyecto. No creo que algún Project manager esté dispuesto a destinar tiempo de proyecto a “correcciones”
Cómo debo refactorizar? Básicamente apoyándose en la especificación de pruebas unitarias y automatizadas, siempre ejecutando pequeños cambios fácilmente testeables que permitan comprobar que no se ha alterado el comportamiento del código. Existe una serie de “buenas prácticas”, las cuales no cubriremos aquí, pero que pueden encontrarse en google sin mucho esfuerzo.
Por qué debo refactorizar? Esta pregunta podría tener varias respuestas. De acuerdo al manifiesto del Software Craftsman, uno como profesional tiene el deber de entregar siempre código limpio, debe refactorizar constantemente como parte de su arte. Podría entregar más razones románticas, pero la verdad es que no hay otra razón más potente que la económica.
A medida que un proyecto de software avanza, debemos ir lidiando con la deuda técnica, con aquellas decisiones y atajos que se tomaron al inicio del proyecto que hoy nos impiden avanzar con la velocidad que quisiéramos. Al ir refactorizando constantemente y tomando consciencia de lo importante de realizarlo, podemos mejorar enormemente nuestros tiempos mediante el uso de patrones, reutilización de código, modularización, etc.
Entonces, la próxima vez que tu Project Manager consulte por qué debería asumir su proyecto este costo, no olvides mencionarle que es por su propia conveniencia y que hay una razón económica detrás.