Hola a todos,
Como supongo que ya habréis medio entendido en los últimos artículos (o tal vez ya lo sabíais anteriormente) el refactoring es el hecho de modificar la estructura interna del código sin cambiar ni su funcionalidad y su interficie de trabajo. Es como si le hiciéramos la puesta a punto al coche, no modificamos su apariencia externa ni nos hace falta aprender nada nuevo para conducirlo, pero el producto (el coche) es de mejor calidad y más seguro.
Refactorizar no es más que la típica limpieza de código con unas cuantas normas que nos permitan tener el código estructurado y de acorde al resto del proyecto.
Cosas que NO se han de hacer al refactorizar:
- Refactorizar al final del proyecto: Este es el típico problema de la persona que no entiende bien el concepto de refactorizar. Refactoriza, si, pero no cuando debe. La refactorización se ha de realizar cada poco, al finalizar un módulo, al finalizar una función,etc... Si no, las posibilidades de introducir errores son enormes (aparte de que las ventajas de la refactorización no se pueden ver durante el desarrollo del proyecto).
- Refactorizar todo el código antiguo de golpe: Este también es un problema típico muy ligado con el anterior. Hemos aprendido las bondades de la refactorización y las queremos aplicar si o si a nuestros proyectos aunque tengamos un deuda técnica heredada de hace décadas y lo queremos ya. Esto normalmente acaba en desastre. Si se quiere refactorizar código antiguo (que se debería) se ha de hacer poco a poco y con calma probando cada uno de los cambios minuciosamente
- Aumentar la complejidad para "mejorar" la mantenibilidad: Este problema es también muy usual, lo que por desgracia la persona que lo realiza lo tiene complicado para darse cuenta. Se basa en el concepto de reutilización de código al máximo nivel. Te encuentras con 20 funciones cortas y sencillas de funcionalidad parecida (pero no idéntica) y las unes todas en una sola función enorme y genérica que basa todo su funcionamiento en los parámetros que se le pasen. Normalmente estos "monstruos" acaban muriendo por su propio peso, pero de mientras nos pueden haber obligado a seguir una estructura de código para nada mantenible. Recordad, por encima de todo la complejidad ciclomática ha de ser baja.
Cosas que SI se deben hacer al refactorizar:
- Cambiar el nombre a las funciones y variables: Este es el gran olvidado o despreciado. Cuando se habla de refactorización todo el mundo piensa en el código, el algoritmo y la implementación pero descuida que los nombres usados para funciones y variables forman parte del código y son lo que en primera instancia nos permite entender el código. Una variable que se llame "a", o una función que se llame "Calculo" aunque no sean incorrectas, no nos aportan información , hecho fundamental para la comprensión del código.
- Mantener los comentarios: Si, los comentarios forman parte del código, y si, el proceso de refactorización también les afecta. Esto es importante tenerlo en cuenta por que mucha gente se olvida de ellos, refactoriza el código y deja los comentarios antiguos (o lo deja sin comentar por que "el código se ve muy claro"). Un código, por muy bueno que sea, necesita comentarios para facilitar la vida al que venga después.
- Eliminar variables y funciones que no se usen: Durante el proceso de refactorización hay ocasiones en que el código se simplifica de tal manera que hay funciones que se quedan "muertas". Son funciones correctas, pero que no son llamadas debido a que su funcionalidad se ha visto asumida por otra función. Por mucho que el código sea bueno, limpio,eficiente y correcto, si no se usa, es un estorbo en medio del código y se ha de eliminar. Tenéis que imaginaros que el código es el combustible de vuestro motor, cuando más combustible tengas más lejos llegarás, pero si llevas más combustible ( más peso) el rendimiento del motor y del combustible disminuirá.
Cosas que estaría bien hacer al refactorizar:
- Usar patrones de diseño: En muchas ocasiones (al menos a mi me pasa bastante) primero se programa y después nos damos cuenta que la estructura que hemos usado es muy parecida o quedaría mejor implementada mediante un patrón de diseño. Esto no quiere decir que todo el código tenga que ir con patrones de diseño, ni mucho menos, pero si se ven casos de manual, esta bien introducir el concepto de patrón para estandarizar código y facilitar el aprendizaje de código de terceras personas.
-Usar TDD y análisis estático de código: Lo pongo como opcional, pero realmente, hacer refactorización sin usar estas herramientas debería estar tipificado en el código penal como intento de suicidio :) . Si no tenemos algo donde agarranos mientras hacemos la refactorización se nos va ha hacer muy pesado mejorar el código con el agravante de que tal vez introduzcamos más problemas de los que arreglemos.
- Optimizar el rendimiento aunque no sea un requisito: Este punto es tremendamente opcional por que depende del proyecto en que se esté se deberá aplicar o no. La idea es sencilla, en el momento de trabajar en un proyecto es posible que no tengamos unos requisitos establecidos de memoria o velocidad, así que todo vale, pero tanto para los tiempos de prueba como para futuras funcionalidades es bastante recomendable que el código vaya siendo mejorado a nivel de optimización. Imaginemos que hacemos una función que compara strings de texto. No nos piden que se rápido por que solo se usará para comparar dos textos cortos. 2 años después, se nos pide comparar dos ficheros relativamente grandes, y como la funcionalidad de comparar cadenas de texto está más que probada se reaprovecha. 1 año después se decide que se tendrán que comparar dos librerías con centenares de ficheros y que se ha de hacer en tiempo real.... tenemos un problema no? En resumen, un pequeño arreglo de velocidad en el momento de refactorizar nos puede permitir llegar o no a los requisitos de una futura implementación (y en todo caso siempre será más rápido y agradable probar la funcionalidad manualmente debido a que todo tardará menos)
Espero que os haya gustado y os haya servido
Nos vemos
P.D: Si os interesa el tema de la refactorización os recomendaria que conseguierais el libro de Martin Fowler (gurú de la calidad de código) que trata sobre el tema
0 comentarios :
Publicar un comentario