¿Me creo eso del Refactoring?

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).

About these ads

3 thoughts on “¿Me creo eso del Refactoring?

  1. El problema es que en TDD, las dos primeras fases son mecánicas (Test y Develop) pero la última (Refactoring) requiere de intuición y sentido común.

    • Lo veo de otra forma, creo que ninguna de esas actividades es mecánica, ni la codificación del test, ni el código funcional ni el refactoring. Todas requieren buenas dotes para la programación y el diseño, para lo que se requiere conocimiento y talento. En mi opinión si un programador no sabe hacer un buen refactoring entonces tampoco estará haciendo bien el resto de las actividades.

      Por mucho que se hable de metodologías clásicas, en la inmensa mayoría de proyectos “clásicos”, casi nunca hay un buen diseño previo. Los programadores se ponen a codificar directamente. Además con la experiencia te das cuenta que codificando es como mejor se diseña. Un buen programador siempre hace un mínimo de refactoring continuo, aunque no use TDD. Esta práctica del TDD simplemente sistematiza ese refactoring, y además con la libertad que proporciona la protección de los tests.

      Existen algunas pautas o ayudas para todas esas actividades. Incluso el refactoring se puede “mecanizar” (por decirlo de alguna forma).

      En la codificación de los test se pueden cometer verdaderas aberraciones y hay unas pautas buenísimas. Todo test usado en TDD debe cumplir las propiedades FIRST (Fast, Idependent, Repeatable, Small and Transparent). El no cumplir estas propiedades reduce el TDD a lo absurdo y es una de las principales causas del abandono de los test. Mis primeros test unitarios (antes de saber de TDD) no cumplían estas propiedades. Ahora quiero usar estos tests como ejemplos del problema de no cumplir FIRST.

      En la refactorización una pauta buenísima es aplicar los principios SOLID sobre Orientación a Objetos introducidos por Robert C. Martin (Uncle Bob) a principios del 2000. Son una guía estupenda para la refactorización. De hecho el SRP (Single Responsability Principle) y el DIP (Dependecy Injection Principle) ya nos dicen casi el 90% de lo que hay que refactorizar, básicamente eliminar código repetido extrayendo responsabilidades y desacoplando las colaboraciones mediante la inyección de dependencias. También podemos hacer uso de los patrones de diseño. En general todo se reduce a eliminar los “code smells”.

      Y por último hacer caso a los TDD Anti-Patterns de James Carr.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s