30 de agosto de 2011

Pepe Grillo y TDD

Hace varias semanas tuve una conversación franca y abierta con mi amigo Alcides: el único tipo de conversación que es posible tener con él. En ella, discutimos las dificultades de su actual proyecto y de cómo hace falta una implementación más formal de algunas mejores prácticas, en especial las pruebas unitarias. Durante nuestra charla yo argumentaba "pero, ¿porqué no usas TDD?" a lo que el me respondía con varias razones:

  • Presiones de tiempo
  • La curva de aprendizaje del equipo de desarrollo
  • El estado actual del código
  • etc

Todas razones válidas, pero sin embargo insuficientes para justificar el no-uso de lo que ambos sabemos ayudará al proyecto. Es como ir al doctor, recibir la receta, surtirla y después negarse a tomar la medicina diciendo que estamos demasiado ocupados para hacerlo.

Ante esto, le recordé una frase del Robert "Tio Bob" Martin:

"Es durante las crisis que más debemos aferrarnos aún a nuestras prácticas y nuestras disciplinas"

Está claro: si el ingeniero civil que está construyendo nuestra casa comienza a tener problemas de tiempo, lo que menos queremos que haga es que empiece a dejar de lado los códigos de construcción, los cálculos, las medidas de seguridad, las mejores prácticas, etc., para ahorrar tiempo, dinero o porque son muy complicadas. Después de todo, si lo hace corremos el riesgo de que la casa se nos venga encima.

Tiempo después, yo mismo entré en modo de emergencia en mi propio proyecto y mientras estaba en ello, Alcides pasó a visitarme. Inmediatamente le mostré el código que acababa de escribir para que me diera su opinión, a lo que él replico:

- "bien, veamos... ¿dónde están las pruebas unitarias?" a lo que por supuesto respondí - "No hay. Este proyecto no me pertenece y mi líder me ha comentado que no tenemos tiempo para eso y debemos concentrarnos en escribir el código tan rápido como podamos: ¡Esto es una crisis!"

Por toda respuesta, recibí una mirada significativa de parte de mi amigo y segundos después la misma frase que le había dicho yo tiempo antes:

"Es durante las crisis que más debemos aferrarnos aún a nuestras prácticas y nuestras disciplinas"

Como dicen en mi pueblo: me mató el gallo en la mano. En ese momento Alcides fue como Pepe Grillo diciéndome que estaba faltando a mi propia conciencia, que estaba dejando que circunstancias externas me detuvieran de hacer mi trabajo de la mejor forma que se y la única que considero ética.

Siempre es valioso tener a alguien que pueda hacer eso por nosotros en momentos que por estrés, flojera o hastío dejemos de hacer caso a la propia conciencia.

Saludos

P.D. Me complace informar que tanto Alcides como un servidor hemos vuelto al buen camino y nos sentimos mucho mejor...

1 comentario:

  1. Sobre el particular me gustaría compartir algunas frases del Sr. Don Wells:

    * "The first test is the hardest."
    * "Your test suite is more valuable than your code."
    * "Where there is a will there is a way to test."

    Sobre todo ésta última me dejó pensando un rato... en pocas palabras "querer es poder"

    Y la segunda frase refleja claramente el cambio de paradigma mental necesario para poder hacer verdaderamente Test-Driven Development (TDD).

    En TDD el código de producción es algo así como un sub-producto del código de pruebas.

    Otra cosa importante es que TDD y la Programación Orientada a Objetos son ortogonales. TDD trasciende el paradigma de programación orientado a objetos y no se restringe únicamente a éste. Se puede hacer TDD en Programación Funcional y aún también en Programación Estructurada.

    Claro, que hay lenguajes y herramientas que facilitan mas el estilo TDD que otros, como diría Kent Beck, no es lo mismo hacer TDD en SmallTalk con SUnit y el Refactor-Browser que en C/C++ con vi. Pero de que se puede, se puede.

    Y sobre éste último punto creo que lo más importante no son las herramientas de refactorización (que mucho ayudan desde luego) sino las pruebas unitarias y de caracterización que se tengan.

    Saludos.

    ResponderEliminar