El refactoring (o refactorización en español) es una técnica utilizada en programación para mejorar la calidad y mantenibilidad del código existente sin cambiar su comportamiento externo. Consiste en reorganizar el código de manera que sea más claro, más conciso y más fácil de entender y modificar.

El objetivo

El objetivo del refactoring es hacer que el código sea más fácil de mantener y evolucionar a lo largo del tiempo, lo que a su vez puede mejorar la productividad de los desarrolladores y reducir los errores y problemas en el software. Además, puede ayudar a reducir la complejidad del código, eliminando código redundante y mejorando la estructura del mismo.

En el artículo de hoy miraremos algunas de las características clave del Refactoring.

Código limpio

Otro objetivo provincial de la refactorización es luchar contra la “deuda técnica”, por eso es importante desarrollar un código limpio y un diseño simple. Las siguientes son algunas de las características del código limpio:

• Es obvio para otros programadores. Debes tener cuidado con los nombres de variables deficientes, las clases y métodos (funciones) inflados, u otros elementos del código que sean descuidados y difícil de entender.
• No contiene duplicación. La duplicación aumenta la carga cognitiva y ralentiza el progreso.  Si haces un cambio en un código duplicado debes recordar hacer el mismo cambio en cada instancia.
• Contiene un número mínimo de clases y otras partes móviles. Menos código significa menos errores, menos mantenimiento y menos cosas para tener en la cabeza.
• Pasa todas las pruebas. Si el código solo pasa el 95% de las pruebas, no es limpio.
• Más fácil y barato de mantener.

Deuda técnica

Hay un momento poco mágico de la vida del programador en que su código simple y limpio se vuelve sucio. Aún está por determinar este momento, pero no se hace intencionalmente. A no ser que el programador tenga malas intenciones.

Cunningham usó la metáfora de “deuda técnica” con respecto al código sucio. Resulta que puede pasar lo mismo que pasa con un préstamo de un banco, con el código: puedes acelerar temporalmente sin escribir pruebas para nuevas funciones, pero esto ralentizará gradualmente tu progreso todos los días hasta que finalmente pagues la deuda escribiendo pruebas.

Las siguientes son algunas de las causas, más comunes, de la deuda técnica:

• Presión empresarial. Las circunstancias pueden obligarte a implementar funciones antes de que estén completamente terminadas. Esta es una “buena” oportunidad para parches que ocultan las partes inacabadas del proyecto.
• Falta de comprensión de las consecuencias de la deuda técnica. El cliente no siempre entiende que la deuda técnica tiene “interés” en la medida en que ralentiza el ritmo de desarrollo a medida que se acumula la deuda. Si el cliente no ve el valor de la refactorización, será más difícil dedicarle tiempo.
• No combatir la estricta coherencia de los componentes. Si el enfoque modular es lo tuyo, aquí es cuando empieza a morirse, y el proyecto empieza a asemejarse a un monolito. Es difícil aislar el trabajo de los miembros individuales, cualquier cambio en una parte del proyecto afectará a otras, el desarrollo en equipos se hace más difícil.
• Falta de pruebas. Si no hay feedback inmediato, nacen soluciones rápidas pero arriesgadas, que se implementan en producción sin ninguna prueba previa, con consecuencias catastróficas.
• Falta de documentación.  Si no hay documentación se ralentiza la incorporación de nuevas personas al proyecto. Incluso se puede detener el desarrollo si las personas clave abandonan el proyecto. ¿Te suena?
• Falta de interacción entre los miembros del equipo. Si la base de conocimientos no se distribuye por toda la empresa, las personas terminarán trabajando con una comprensión obsoleta de los procesos y la información sobre el proyecto. Esto pasa en cualquier sector.
• Desarrollo simultáneo a largo plazo en varias ramas. Ojo con este tema. Puede conducir a la acumulación de deuda técnica, que luego aumenta cuando se fusionan los cambios. Cuantos más cambios se hagan de forma aislada, mayor será la deuda técnica total.
• Refactorización retrasada. Los requisitos del proyecto cambian constantemente y en algún momento puede resultar obvio que partes del código están obsoletas y deben rediseñarse para cumplir con los nuevos requisitos. Cuanto más se retrase la refactorización, más código dependiente tendrá que volver a trabajarse en el futuro.
• Falta del seguimiento del cumplimiento. Sucede cuando todos los que trabajan en el proyecto escriben el código como les parece.
• Incompetencia. Si el desarrollador simplemente no sabe cómo escribir un código decente.

¿Cuándo refactorizar?

Alexander Shvets, propone utilizar la siguiente “regla de tres”:

1. Cuando estés haciendo algo por primera vez, simplemente hazlo
2. Cuando estés haciendo algo similar por segunda vez, siente vergüenza de tener que repetirlo, pero haz lo mismo de todo modos
3. Cuando estés haciendo algo por tercera vez, empieza a refactorizar

También deberías refactorizar al corregir un error, o durante una revisión de código.

¿Cómo refactorizar?

La refactorización se debe realizar como una serie de pequeños cambios, cada uno de los cuales mejora un poco el código existente y deja el programa en condiciones de funcionamiento.

Aquí tienes un ejemplo de checklist de “una refactorización realizada correctamente”:

• El código debería volverse más limpio
• Una nueva funcionalidad no debe crearse durante la refactorización
• Todas las pruebas existentes deben pasar después de la refactorización

Conclusión

En resumen, como has podido ver, el refactoring es una técnica que se utiliza para mejorar la calidad del código existente, haciendo que sea más fácil de entender, modificar y mantener.

Fuente:

• When to refactor