Si te paras a pensar sobre a qué dedicas tu tiempo como desarrollador de software, la cantidad de código que lees y escribes sobre proyectos de código heredado es bastante superior que los creados desde cero.
Un técnica bastante frecuente al trabajar con código legado es Refactorizar.
¿Qué significa Refactor?
Refactorizar es una técnica disciplinada para reestructurar una parte de código existente, alterando su estructura interna sin cambiar su comportamiento externo.
Consiste es una serie de pequeñas transformaciones que conservan el comportamiento. Cada transformación (llamada "refactorización") hace poco, pero una secuencia de estas transformaciones puede producir una reestructuración significativa.
Dado que cada refactorización es pequeña, es menos probable que salga mal. El sistema se mantiene en pleno funcionamiento después de cada refactorización, lo que reduce las posibilidades de que un sistema se rompa gravemente durante la reestructuración.
¿Cuándo hay que refactorizar?
A mí me gusta el refactor como una acción de mejora diaria.
No soy partidario de tareas de refactor, salvo que aporte valor al cliente. Por ejemplo, para mejorar una parte de la aplicación crítica para el cliente con una tasa alta de bugs.
¿Cómo refactorizar un proyecto de desarrollo de software?
Cuando refactorizamos deberíamos tener objetivos a perseguir y problemas a evitar como origen del refactor.
Objetivos a perseguir:
- Legibilidad del código de producción
- Legibilidad del código de los tests
- 4 reglas del diseño simple
- Criterios de diseño
- Alta cohesión y bajo acoplamiento
- Código limpio
- Aquitectura limpia
- Testabilidad
- Principios SOLID
Problemas a evitar:
- Código duplicado
- Clases o funciones grandes
- Código con muchos bucles y/o condicionales (alta complejidad ciclomática)
- Code Smells en arquitectura
- Code smells en el código
- Obsesión primitiva
- Código desodorantes
- Escucha el código , no todo está escrito o catalogado y es necesario detectar las señales. Yo suelo decir: Este código nos pide un cambio .
Saber refactorizar:
- Saber si tenemos una red de seguridad de pruebas .
- Saber cómo crear esa red de seguridad si no existe
- Refactorizaciones como por ejemplo: eliminar código muerto , método de extracción, método en línea, reemplazar condicional anidado con cláusulas de protección , reemplazar condicionales con polimorfismo.
- Conocer las opciones de refactorización que brinda el IDE . Por ejemplo, te dejo las opciones de refactor con Intellij IDEA y vscode que son lo que yo uso:
- Conocer técnicas para trabajar con código legado : Parallel change, Sprout Method , Sprout Class, Wrap Method y Wrap Class
Cómo crear una red de seguridad si no existe
Al hacer un refactor sobre código legado tenemos dos opciones:
- Modifica sin tests y reza
- Cubrir con test primero y modificar después
Es cierto que podemos tener que enfrentarnos dilema del código heredado :
Cuando cambiamos el código, debemos tener pruebas. Para implementar las pruebas, a veces tenemos que cambiar el código.
Una de las técnicas para obtener una red de seguridad es Golden Master Technique , que consiste en capturar la salida de diferentes entradas y crear una prueba con ellas para garantizar que no rompamos el sistema al refactorizar.
En algunos escenarios puede ser útil usar Pruebas de Aprobación que están disponibles en diferentes lenguajes de programación.
Si el sistema actual no envía texto a un flujo de salida, debemos seguir otras técnicas para escribir pruebas:
- Identificar responsabilidades y extraer métodos para ellas: Recuerda que está bien extraer métodos con nombres o estructuras deficientes para realizar las pruebas. Seguridad primero. Una vez realizadas las pruebas, puede hacer que el código sea mucho más limpio. - Michael C. Plumas.
- Comenzando con pruebas de caracterización para documentar el comportamiento real.
- Programación en pareja: (…) trabajar en código heredado es cirugía, y los médicos nunca operan solos - Michael C. Feathers.
Beneficios del refactoring
Vamos a ver que tipo de beneficios podemos obtener con el refactoring.
1. Reducir la complejidad del código
A medida que pasa el tiempo (incluso solo horas) mejora nuestra compresión del problema a resolver.
A base de pequeños refactors tenemos la posibilidad de ir reduciendo la complejidad del código haciéndolo más intuitivo y fácil de entender.
2. Código más fácil de leer
El refactor es ideal para mejorar la legibilidad de nuestro código.
Mejorando los nombres asignados a variables, funciones o clases.
3. Reducir tiempo de solución de errores
Al mejorar la legibilidad del código y reducir complejidad, es más sencillo encontrar problemas en el código cuando un cliente reporta un error.
4. Reducir tiempo de añadir nuevas features
Al mejorar la legibilidad del código y reducir complejidad es más sencillo añadir código nuevo que se siga la misma dinámica de legibilidad y simplicidad.
5. Reducir deuda técnica
A aplicar refactors podemos reducir la deuda técnica que nos hayamos ido dejando por el camino debido a diferentes motivos como fechas de entrega, solución rápida de bugs etc..
6. Evitar errores en el futuro
Cuando identificamos duplicidades en el código y tras evaluar si es necesario, podemos crear mejores abstracciones que lo reducen.
De esta manera estamos también evitando posibles errores en el futuro.
7. Pone el tiempo a correr a tu favor
El último beneficio como suma de los anteriores, es que pone el tiempo a correr a tu favor.
Si creas hábito diario de pequeños refactors rápidos a medida que haces tus tareas, es cuestión de tiempo que veas los resultados.
¿Cómo aprender y practicar todas esas cosas?
Una de las mejores formas de aprender y practicar es jugar con la refactorización de katas , donde se comienza con una pequeña pieza de código heredado que se debe refactorizar para agregar/cambiar una función.
Puedes encontrar varios katas de refactorización en Kata Log .
Uno de mis katas de refactorización favoritos es 'Gilded Rose Kata', porque es un excelente ejemplo de los pasos recomendados para agregar una nueva función en el código heredado:
- Creación de una red de seguridad de pruebas
- Refactorización (porque el código no es simple)
- Agregando la nueva característica
Te dejo un video de Rachel M. Carmena resolviendo este kata:
Recursos
- Clean Code: A Handbook of Agile Software de Robert C. Martin (capítulo Olores y heurística )
- Working Effectively with Legacy Code por Michael C. Feathers
- Refactoring: Improving the Design of Existing Code por Martin Fowler
- Catálogo de refactorizaciones
Conclusiones
Termino con una frase:
Recuerda, el código es tu casa y tienes que vivir en ella.
