REFACTORIZACIÓN

Y si ustedes están aquí hoy, es muy probable que hayan trabajado o estén trabajando
con algún lenguaje de programación. Y si ese es el caso, sus actividades podrían
resumirse en:
En ocasiones como desarrolladores vemos que la calidad o la estructura del código
existente no es muy buena, ya sea porque el código es complejo, no es fácil de entender
o incluso cuando agregamos algún cambio desencadenamos errores sin entender por
qué.

Todos estos factores son señal de que nuestro código debe ser refactorizado.

Pero, Qué es la refactorización? Cambiar código? Sí, pero no es sólo eso.

Como dice Martin Fowler, “Refactorizar significa hacer un cambio en la estructura interna
del software para que sea más fácil de entender y más barato modificarlo sin cambiar su
comportamiento observable”
Pero, Por qué querríamos nosotros cambiar la estructura interna del software?

Sin refactoring la productividad decrece, la duplicación del código se acumula, la lógica

se vuelve más compleja y el código es cada vez más difícil de entender. Generando así
problemas de escalabilidad o problemas de velocidad en el desarrollo.

A todo esto le llamamos deuda técnica y aparece por diversas razones, entre ellas:

1. La falta de experiencia de algunas personas para escribir buen código.

2. La falta de motivación para hacer el trabajo correctamente.
3. La falta de tiempo en donde nos vemos obligados a saltar estándares de calidad.

Por eso sabemos que la deuda técnica siempre existirá y no podemos pensar que la
refactorización es una tarea especial en nuestros proyectos, sino más bien, una tarea de
la programación diaria.
Lo que debemos saber es en qué momento SÍ y en qué momento NO debemos hacer un
refactor.
Cuándo NO debemos hacer refactor de nuestro código?

1. Cuando el código actual no funciona.

2. Cuando los plazos deben cumplirse.
3. Cuando existe el chapado en oro, lo que significa, que si el código ya está en
buena forma entonces no hay que gastar tiempo adicional en optimizarlo.

La refactorización en un proyecto grande debe asegurarse de no romper nada. Por eso el

proceso recomendado es:

1. Asegurar que el comportamiento existente sea correcto.

2. Si tiene pruebas, ejecutarlas y asegurar de que pasen.
3. Hacer el refactor.
4. Verificar que el comportamiento sigue siendo el mismo.
Y cuándo SÍ debemos hacer un refactor? Pues aquí debemos introducir un término
fundamental: los Code Smells, que son básicamente características en el código que
indican un problema más profundo.

Ya que, como dice el dicho: “no trates de arreglar lo que no está roto” y lo mismo ocurre
con el código.

Hay una gran cantidad de Code Smells, pero gracias a los esfuerzos de Mika Mäntylä y
Casper Lassenius están agrupados en algo que ellos denominaron A Taxonomy for "Bad
Code Smells"

http://mikamantyla.eu/BadCodeSmellsTaxonomy.html

Entre los que se encuentran:

1. Los Bloaters que nos habla de los métodos y clases muy grandes con las que son
difíciles de trabajar.
2. Object - Oriented Abusers: Se refieren al código que aplica incorrectamente los
principios de la programación orientada a objetos o no los usa.
3. Change Preventers: Que violan la regla sugerida por Fowler que dice que las clases y
los posibles cambios deberían tener una relación de uno a uno.
4. Couplers: Representan un acoplamiento entre clases o módulos y se sugiere que sean lo
más independientes posible.
5. Dispensables: Un dispensable es un código que no es necesario y debe
eliminarse como los malos comentarios y el código duplicado.
Después de identificar problemas, llamados Code Smells y aplicar técnicas de
refactorización dependiendo de cada uno de ellos, definamos 5 principios para la
refactorización:

1) Tener claridad sobre lo que se va a refactorizar. Aunque parece obvio, es

bueno resaltar que es muy importante que primero exploremos el código para
entender lo que se va a cambiar.
2) Si no tiene pruebas unitarias, agrégalas antes de cambiar algo. Que,
aunque parece ser un proceso lento, es más rápido que romper las cosas y
arreglarlas después.

3) Mantener cada refactorización pequeña. Como dice Joshua Kerievsky: “La

refactorización en pequeños pasos ayuda a prevenir la introducción de defectos”.

4) Definir el alcance de la refactorización. Si no se puede por algún código

dependiente, es mejor hacer un análisis de lo que debe hacerse definiendo tareas
separadas y enfrentándolas una a una en el orden correcto.

5) No ser un héroe en solitario. Es mejor buscar opiniones de los miembros del

equipo como por ejemplo haciendo uso de los Pull Request.
Como dice Joshua Kerievsky: “Para obtener los mejores resultados de refactorización,
necesitará la ayuda de muchos ojos”.

Si les interesa saber mucho más acerca de este tema, los invito a leer el libro de Martin
Fowler “Refactoring. Improving the Design of Existing Code”.

https://martinfowler.com/books/refactoring.html

Y a mi me pueden encontrar en redes sociales como @teffcode.

Muchas gracias !