TDD y Clean Code: La pasión por hacer las cosas bien

Los mánagers, llámense gerentes, líderes de proyecto o directores, a veces parecemos disco rayado: más productividad, más calidad, mejores soft skills. Hablamos de profesionalismo, de valor agregado, de romper esquemas.

Como mánager de un equipo de desarrollo de software confieso haberlas dicho, y por eso sé que son palabras que terminan en oídos sordos cuando aquellos a quienes las decimos no transforman su vida. Aunado a la tentación de mandar y vigilar, sobre todo cuando perdemos la paciencia, la tan soñada transformación sólo nos pasa a nosotros: de Dr. Banner a Hulk. Entonces la salida fácil es tratar a la gente como un recurso. Para ellos también es más sencillo flotar de muertito que nadar contra corriente. Al fin y al cabo “sólo es un trabajo”.

La transformación que implica cambio de hábitos es difícil y hasta dolorosa. Sin embargo, cuando se logra sientes que el equipo puede hacer cualquier cosa. Y el equipo de desarrollo de software con el que trabajo logró cambiar la cultura de “con que jale” a “nos gusta hacer las cosas bien”.

Esta es la historia de esa transformación.

Los primeros pasos

A los desarrolladores de software les puedes hablar de procesos, estimaciones, planeación e incluso pruebas, y lograr que (medio) te compren la idea. Pero no te atrevas a meterte con lo más sagrado, con lo que hacen todos los días: el código. Y nosotros nos metimos con su código impulsando TDD.

Test Driven Development (TDD) va en contra de la lógica, y de lo que la escuela y la vida nos ha enseñado: primero programas, y ya que terminas, pruebas que funcione. TDD propone que primero se hagan las pruebas automatizadas y después, el código. Hacerlo al revés es tan ilógico que se siente raro programar, porque al fin y al cabo, un gran programador sabe resolver un problema completo y a la primera ¿cierto?

Decidimos impulsar esta técnica para mejorar la calidad de nuestro producto. También le apostamos al código limpio. Hasta que lo vivimos nos dimos cuenta que más allá de las pruebas, el valor de TDD radica en el diseño que emerje en pequeñas iteraciones guiadas por nuestros escenarios; que nos obliga a entender el problema en vez de clavarse en la solución y que al final, tenemos una documentación vida, una red de seguridad que nos ayuda a no perder el control de nuestro código.

Yo soy Clean Coder

Durante algún tiempo intentamos imponer un proceso en el que TDD era obligatorio. Los resultados exitosos eran aislados y sobre todo temporales. La mayoría de los desarrolladores pensaban que TDD era una locura de los mánagers y que nosotros qué sabíamos de programación.

A finales del año pasado pedí que nos compraran los videos Clean Code de Uncle Bob. Cuando los vi entendí todo lo que habíamos hecho mal. TDD no es sencillo y va más allá de hacer pruebas.Uncle Bob nos explicó cómo comenzar a atacar el problema a través de escenarios sencillos o excepciones. Cómo cumplir con el ciclo red-green-refactor y no ceder al instinto de escupir el algoritmo definitivo.

Supe que teníamos que programar. Compré el libro de katas de Emily Banche y organicé algunas. Entonces sentimos la piel de gallina con la kata de Bowling y su diseño a prueba de escenarios extraños. Seguimos con una calculadora de Strings y Factores Primos. Cerramos con el Pokar y sus combinaciones macabras.

Entonces comprendí: tienes que vivir TDD para entender que sí funciona; no puedes implantarlo como si fuera un proceso. Tiene que guiarte un experto (y si está disfrazado de señor Spock, mejor) y sobre todo, tienes que emocionarte. Incluso yo, que tenía 8 años de no programar, me emocioné tanto que llegaba tarde a casa por estar programando. Revisaba todas las katas (¡son diez programadores!) y soñaba en Java.

Por cierto, una de las razones por la que cambié de programación a pruebas fue que me desesperaba tener front ends para probar que funcionaba mi código. Hacer tronar la aplicación me emocionaba. Ahora me doy cuenta que de haber conocido TDD hace diez años hubiera cambiado mi carrera.

La Transformación

Entonces sucedió. El código productivo comenzó a tener coberturas superiores a 80%. Las discusiones durante las inspecciones eran más críticas, y el “todo veeeerde” que gritan cuando le mueven al código y las pruebas unitarias siguen pasando.

Día a día fuí testigo de lo que parecía imposible: la adopción de TDD y Clean Code. Entre carrilla y desmadre, algunos lo hicieron más rápido y otros caían en viejos hábitos sin darse cuenta, pero después de algún tiempo ni uno se quedó atrás.

Kent Beck, el inventor de TDD, dice: No sé si soy un gran programador, pero sí soy un programador con grandes prácticas. TDD y Clean Code son prácticas que nos revolucionaron como programadores, pero también como personas. Aprendí a trabajar en equipo: sin duda, no lo hubiera logrado sin Alberto (Co-Mánager) y Armando (Arquitecto) de nuestro equipo. Aprendí a apreciar los pequeños logros: al revisar las Katas me hacía feliz el cambio en los desarrolladores. Y sobre todo, comencé a creer en nosotros como equipo.

Lo que me tomó por sorpresa fue el cambio de actitud: los programadores, cuyo seniorship era una carga, renovaron su energía y pasión por el código. Al escuchar hablar a los juniors no sólo se les nota el dominio de la técnica, sino también un dominio del negocio. Y sobre todo, el nacimiento de líderes que los invitan a arriesgarse con algo más que Clean Code y TDD.

Más de una vez lo hemos platicado en grupo: cómo fue posible haber vivido entre tanta cochinada antes de Clean Code. Cómo era posible no habernos dado cuenta que nos matábamos línea tras línea.

Y sólo es el principio.

Adoptar TDD y Clean Code me pareció durante mucho tiempo una misión imposible. Así que cuando lo logramos, pensé que habíamos llegado al final. Qué ilusa. Ahora me doy cuenta que es sólo el principio. Nos faltan Patrones, Clean Architecture, Estabilidad, Seguridad… y quién sabe qué tanto más.

Nos falta también ser más sociables y compartidos. Nos falta leer más, felicitar y agradecer más.

TDD y Clean Code nos cambió como grupo y como profesionales del software. Por supuesto, no somos los más fregones del universo (¿alguien lo es?) y tenemos algunos otros problemas con los cuales lidiar. A veces vuelvo a convertirme en Hulk, pero cuando escucho “todo veeeerde” o “¿quién tiene el libro de Clean Code?”, me acuerdo de lo que hemos logrado y calmo mis ansias.

Este es un reconocimiento para todos los desarrolladores de software que admiro, son de las personas más apasionadas que conozco, y para quienes hay algo más que sólo un trabajo cuando de tirar código se trata.