¿Cómo se estima y planifica el refactoring? O sea, no siempre pasa que la primera versión del código es la mejor que podemos tener, más que nada porque cuando lo comenzamos no teníamos todo lo que se podía venir en mente, o no sabíamos si estábamos cumpliendo o no los requerimientos funcionales o no-funcionales, así que a la corta o a la larga, el código se va a tener que ajustar. Muchas veces se acumulan muchos de esos cambios como parte de la deuda técnica: sí sí, sé que tengo que mejorar eso, pero lo dejo para cuando tenga tiempo. Entonces, ¿no deberíamos hacer la estimación considerando refactoring cuando planificamos el desarrollo?
La actividad de refactor es parte de la propia tarea del desarrollo, y hablo de desarrollo del sistema, o desarrollo de la prueba unitaria, automática, parte del framework Selenium o Appium, o incluso la prueba de performance que estoy codificando.
Una cosa es desarrollar y otra es desarrollar bien. Acompañando la idea de shift-left testing (incluir actividades de calidad más temprano en la vida de un proyecto de desarrollo) está la idea de hacer las cosas bien, con calidad, y no esperar a llegar al final de la cadena de producción, y que ahí se rechace y se pierda mucho tiempo de retrabajo. En este esquema es que uno debería planificar el desarrollo bien hecho, lo cual incluye código según estándares (definiendo buenos Quality Gates en SonarQube), pruebas unitarias, etc., incluso, refactoring, debugging, improving 🙂
Gracias Nina Miller y Cesar Lobo (de Abstracta) por el insight en la discusión de estos temas.
