Recientemente estuve realizando una formación que impartía Carlos Ble. Dicha formación consistía en aprender trucos y consejos para aplicar a la hora de hacer refactor. Lejos de ser solo una charla, los alumnos estuvimos gran parte del tiempo practicando lo que íbamos aprendiendo con cada ejercicio, y ahora yo quiero hablar un poco acerca de ello.
Tras concluir esta formación mi perspectiva acerca del refactor cambió mucho. Generalmente, tendemos a buscar los refactors más complicados, esos que simplifican 20 líneas de código en la mitad o casos por el estilo. Hay entender que el refactor no consiste en hacer el código lo más pequeño posible, porque menos código no es directamente proporcional con código más simple. Estuve viendo muchos ejemplos de que con cambios muy simple como puede ser un cambio de nombre llegas a lograr una mejor semántica en tu código. Los refactor en código legacy deben empezarse por algo sencillo, es decir, desde fuera hacia dentro de un método o una clase.
No quiere decir que existen casos para hacer trabajos de refactor más complejos, pero siempre y cuando nos aporten. Al final de este post comparto y repositorio de mi cuenta de GitHub para que podáis que ejemplo estuvimos realizando.
Resumir una formación de este estilo no es posible ya que hay que estar practicando cada concepto y dedicandole un tiempo para reflexionar acerca de ello para poder interiorizarlo, pero si tuviese que destacar los puntos claves que me llevo de esta formación serían los siguientes:
IDE
- Con herramientas tan avanzadas como IntelliJ los refactors deben ser lo más automáticos posibles. Los refactors del IDE son completamente seguros y terminan ahorrándote tiempo que si lo hicieses de una forma más manual. Más allá de las ventajas de la herramienta, el porqué deberían ser lo más automático posible responde a la garantía de que en ningún momento el código se rompe, que es lo que precisamente un refactor nunca debería hacer.
- Inline method o Inline variable → Sustituye su valor o funcionamiento en los lugares donde se esté llamando. Muy útil para reemplazar todas las llamadas de un método viejo por uno nuevo.
- Introduce parameter object → Útil para cambiar un primitivo de un método por un objeto que contiene como propiedad dicho primitivo.
- Wrap return value → Para cambiar el retorno de una función
- Introduce funtional parameter → Para declarar un parámetro funcional en la función y ejecutar una cosa o otra dependiendo de dicho parámetro.
- Encapsulate fields → para cambiar la visibilidad de un campo de la clase, para que uno público se vuelva privado. Se ocupará de generar los getter y setter que le indiquemos.
- Pull members up → lleva los métodos a la clase padre
- Use interface where is possible → Usará la clase padre donde sea posible
Legacy Code
- Un legacy code puede llegar a ser muy complejo de entender y sobre todo de refactorizar. Lo más importante para éstas situaciones es disponer de una buena pila de test que prueben la funcionalidad, y tras esto si podemos refactorizar con la garantía de que si por error rompemos algo lo sabremos de inmediato con la ejecucción de los test y dejaremos el código a un estado completamente funcional con un control de versiones.
- Cuando trabajamos con código legacy es muy importante tener cuidado con los cambios que hacemos cuando son a estados de un objeto, asignaciones y condicionales. Son la principal casa de romper un código legacy.
- Con código legacy es muy útil comprobar la geometría del código. Puedes poner la letra muy pequeña y ver así la vista general del código, o puedes usar extensiones como esta: CodeGlance
Otros
- Todo puede ser testeado con un poco de creatividad. ¿Como testear que un método escribe lo correcto en la consola?, podríamos intentar capturar la salida de la consola, pero hay algo mucho más simple para el test como es extender la clase con dicho método y trucar el comportamiento que escribe en consola por almacenarlo en una variable y comprobar así esa variable.
Para terminar, me gustaría compartir el repositorio donde estuve trabajando los ejercicios de esta formación. No es posible ver como se hicieron los refactors automáticos, pero sí el resultado final.