Promoviendo el Refactoring

Adopción de técnicas de Clean Code

24 October 2013

David Caicedo
Jaguar Ágil



La primera vez que tuve que confrontar con el "refactoring" en una aplicación, fue un shock de emociones y disgustos, pues de hecho había que mejorar el código de alguien lo escribió de muy mala gana y encima tenía muchas funcionalidades que modificar y agregar.

Retorcí mis dientes y seguí adelante con esta larga y ardua tarea. Aunque en el transcurso noté que no existían un set de pruebas unitarias y para garantizar mi trabajo tuve que escribir dichos tests. Esto me llevo una buena cantidad de tiempo, la presión y el malestar me hizo pensar que no era el mejor camino.

Sin embargo, con el transcurso del tiempo he sido benefactor de las ventajas de utilizar técnicas como Clean Code y Refactoring, sencillamente mi trabajo se ha simplificado y la calidad de mi código fuente es mucho mejor.

Ahora es tiempo de "evangelizar" a mi equipo técnico en esta práctica, pero para que no sufran el mismo impacto que yo sufrí alguna vez, lo he tratado de una mejor manera.

Por algunos días he elaborado una presentación de Clean Code, y técnicas de refactoring muy didácticas que muestran los grandes beneficios de esta práctica ágil. Y en medio de esta rutina he descubierto cosas nuevas, las cuales me llevan a pensar: Cómo pude desarrollar software sin estas técnicas!

Antes de la presentación real, me he apoyado mostrándole la intención de mi trabajo al desarrollador más pragmático de mi equipo, y definitivamente se ha sentido motivado por la temática. Y aportó mucho con sus observaciones y propuestas de mejora.

Si de pronto tu trabajo se convierte en primera instancia: corregir el trabajo de otro y en segunda instancia realizar el tuyo. De seguro puedes creer que es largo, injusto e improductivo; pero definitivamente la mejora continua es una mejor práctica que seguir desperdiciando recurso en "reutiliza" algo que probablemente no es entendible y dificil de mantener.

Finalmente mi conclusión es que hay que "vender" la idea que usar técnicas de Clean Code y apoyar Refactorizando el código fuente son prácticas que benefician al producto y al equipo de desarrolladores que realizan mantenimientos o nuevas funcionalidades, Puede ser utilizando un proyecto en particular, para poder compararlo con el desarrollo normal y establecer diferencias.

Lo importante es tomarlo de buena manera, pensar en costo y futuro beneficio y seguir adelante sin mirar atrás. De seguro en pocas semanas el mismo equipo notará que este es el mejor camino.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Gabriel Fabian Ledesma Montaldo, CSP,CSM,CSPO, 12/10/2013 11:03:41 AM
Me gustó mucho encontrar un artículo acerca de este tema. Trabajo en una empresa que el refactor es parte del proceso de desarrollo en el propio sprint. El refactor no es un gasto, es una inversión. Pero conviene saber hacer un buen trade-off de hasta donde se debe hacer refactor contra cuando termino la story. Para ello, adoptar la técnica de Code Reviewer permite al equipo discutirlo y dar un buen balance de hasta dónde llevar el refactor en cada sprint. Gracias por el artículo.

You must Login or Signup to comment.