La primera vez que escuché algo de metodologías Agile como Extreme Programming o Scrum, una de las primeras cosas que pensé fue:

¡Vaya una mierda que nos están vendiendo!

Esta primera evaluación de las metodologías Agile fue debida precisamente a todas esas historias de trabajar al día. Programar lo justo para cumplir. Evitar la codificación de funcionalidad futura. No perder el tiempo en la creación de arquitecturas para pretendidos frameworks reutilizables. Todo se acabará mejorando en un hipotético refactoring posterior.

“Keep it simple, stupid” (KISS)
“You ain’t gonna needed it” (YAGNI)
“If it’s worth building, it’s worth testing. If it’s not worth testing, why are you wasting your time working on it?”

Habían sido muchos años de lucha contra el Spaghetti Code, intentando evitar las anti-metodológicas prácticas del Death March o el Cowboy Coding, que es a lo que me sonaba todo lo Agile.

Harto de enfrentarme a código con chapuzas, pegotes y parches, ¿¡Me vienen ahora con unas metodologías que hace apología de todas esas prácticas!?.

Lo estaba entendiendo bastante mal, porque me habían contado a medias la verdadera práctica del refactoring.

La lección aprendida es que para que el agilismo funcione, sin lugar a dudas es vital combinar “GESTIÓN + INGENIERÍA”.

Scrum proporciona una gestión y planificación agile de proyectos. La implantación de prácticas agile en un grupo muchas veces se queda sólo en Scrum, ya que la parte de gestión y planificación es es siempre más fácil de cambiar que las prácticas de ingeniería.

Extreme Programming proporciona la Ingeniería del Software Agile. Son metodologías más complicadas de introducir, ya que requiere de expertos programadores, son prácticas que emergen de la programación y no de la gestión, que es donde suele estar el mayor poder de influencia.

Cuando conocí el bucle micro-incremental e iterativo de TDD, o del BDP (Behaviour Driven Programming) de BDD, es cuando realmente entendí el paradigma YAGNI y sus derivados.

El refactoring es vital en TDD.
Si no haces un refactoring continuo no estás haciendo TDD.
Si no haces refactoring no estás diseñando.

Usando este tipo de metodologías es como se hacen viables principios como YAGNI. Así es como se puede diseñar directamente desde el código. El código nos va mostrando el diseño y la arquitectura de nuestra aplicación.

El refactoring es lo que hace posible que ese framework reutilizable, esa arquitectura o ese gran diseño surja de forma orgánica, justo en el momento que se necesita. Además con la libertad de modificación y trasformación que proporcionada la amplia cobertura de los Small Scaled Tests que han dirigido dicho refactoring.

Deberíamos llamar a la metodología Test Driven Refactoring (TDR).

Me horroriza oír hablar de “la deuda tecnológica”. Este concepto no debería existir. Da la sensación de que se le ha puesto un bonito nombre a lo comúnmente conocido como chapuza tecnológica.

No deberíamos calcular la chapuza tecnológica acumulada a lo largo de los sprints para decidir si necesitamos un período de refactoring. Se trata de un refactoring que nunca jamás nos van a permitir hacer, ya que nunca vamos a tener tiempos muertos.

Los períodos de refactoring no existen porque el refactoring es continuo.

Sí, me creo eso del refactoring, pero cuando se utiliza de forma continua, incremental e integrado en un bucle de trabajo basado en Test Driven Refactoring (o Behaviour Driven Refactoring).