¿Quién ha sentido la frustración de querer mejorar y hacer refactor de una funcionalidad o parte de código por no poder dedicarle tiempo ?
¿Las historias de usuario técnicas o de mejora tech se quedan más abajo en la priorización de lo que nos gustaría como desarrolladoras y desarrolladores?
¿Has empezado un refactor y has tenido que parar por que le estabas dedicando demasiado tiempo a la historia de usuario? ¿Te has sentido identificada o identificado con alguna de las preguntas anteriores?
Esta sensación es algo que llevamos por dentro, o no tan dentro, la mayoría de personas que nos dedicamos al desarrollo de producto… Y ahora es cuando nos preguntamos, ¿qué podemos hacer con esta sensación?
A principios del año pasado mi respuesta hubiera sido muy diferente y os explicaré el por que a continuación.
En una formación que hicimos con nuestro gran Pedro Pardal, coach técnico de Voxel (charla de pedro sobre el Legacy en el #SDSummit), surgieron algunas de estas mismas preguntas y cuando se las planteamos a Pedro nos comentó algunas ideas sobre cómo se podría afrontar esta situación.
Una de ellas, era un método muy sencillo pero efectivo, a este método le conocemos cómo 10 min refactor.
10 min refactor
Este método consiste en reservar cada día un espacio de tiempo de 10 minutos para refactorizar una parte del código de forma segura.
No hace falta que sea algo grande, es buscar algo y mejorarlo, ya sea un rename para que algo se entienda mejor o la extracción de un método. Siempre encontraremos algo que mejorar de forma segura.
La potencia de este método reside en dedicar cada día esos 10 minutos a mejorar.
Si sumamos esos 10 minutos de todas las personas del equipo, todos los días laborables de la semana… Ya no se ven solo 10 minutos, sinó mucho más. De esta manera, iremos mejorando nuestros sistemas de forma incremental, mejorandolos poco a poco y casi sin darnos cuenta. Gota a gota se irá llenando el vaso.
Y, ¿qué pasa con esos refactors que consideramos grandes ? Pues se afrontan de la misma manera: El primer día extraemos métodos, el segundo día extraemos en una clase, el tercero creamos los tests de esa clase etc.
Refactors de forma segura
Me gustaría destacar la frase mencionada en el punto anterior ”refactorizar una parte de código de forma segura“.
Generalmente los hacemos utilizando una herramienta de refactor automática, como por ejemplo Resharper, aunque serviría cualquier otra similar. Este tipo de herramientas nos aseguran que el código se comportará de la misma manera si lo cambiamos de forma automática, evitando errores humanos.
También cabe destacar la importancia de tener un buen coverage de tests que nos permita hacer cambios de forma segura. Y si no se tienen, mediante 10 min refactor se pueden ir creando para posteriormente refactorizar.
¿Qué puedo refactorizar en 10 minutos?
La respuesta es sencilla, lo que sea.
En el equipo de Travel, en Voxel, lo que solemos hacer es aplicar la regla del Scout: deja aquello tan limpio como te gustaría encontrarlo.
Si vemos que hay una dedicación importante para dejarlo de esa manera, nos lo apuntamos para afrontarlo posteriormente en estos 10 minutos de refactor.
Esto incluye no solamente código, sino que también incluimos tests, documentación, procesos del equipo etc. Todo es mejorable y poco a poco se consigue.
Conclusión final
Os animo a probar estos 10 minutos al día que tanto nos cambiaron la manera de trabajar y de mejorar en nuestro equipo. Que saquéis vuestras propias conclusiones sobre lo que aporta y nos contéis sobre ello.
Sobre el autor:
