Un noche de enero del 2007 Dave Thomas, uno de los autores del magnífico libro The Pragmatic Programmers, estaba haciendo un programa en Ruby para implementar un pequeño contador de ciertas palabras que aparecían en los artículos de su blog. Para comprobar el rendimiento creo un test y se puso a probar diferentes técnicas de búsqueda y comparación, observando las enormes diferencias de rendimiento entre distintas formas de solucionar el problema.
Supongo que la mayoría de nosotros nos hubiéramos quedado bastante contentos con haber optimizado el código y que funcionara correctamente. Pero no así Dave, el cual escribió esta magnífica anotación en su blog: A menudo, el verdadero valor de algo no es el que tiene en sí mismo, sino que lo es la actividad que lo creó.
Lo que hace una buena ducha
Otro de los Pragmatic Programmers, Chad Fowler, cogio esta frase y escribió un post utilizando a los músicos como ejemplo de la importancia de la práctica de la ejecución por encima del resultado final. Finalmente Brian Marick, uno de los firmantes del Manifiesto Agile, se basó en el artículo de Flower para escribir una entrada en su blog en donde hacía énfasis sobre el valor de la práctica en el aprendizaje de procesos creativos, como es el desarrollo de software.
Dave, como nos cuenta en su blog, estando en la ducha se da cuenta que su práctica de 45 minutos la noche anterior era muy similar al ensayo de un músico. Se pregunta qué es lo que había hecho que la ha convertido en una sesión de práctica, y las conclusiones a las que llega las comparte con el resto de la comunidad.
Principios del Code Kata
-
Reserva 45 minutos sin interrupciones.
-
Que la tareas a ejecutar sea muy simple.
-
Que la puedas realizar varias veces y de diferentes maneras.
-
Que tengas un feedback sobre lo que estás haciendo (aquí entra el testing).
-
Que construyas en pasos cortos, ya que esto motiva a continuar.
-
Que cuando hayas terminado sepas más de lo que sabías al empezar.
¿A que es obvio y simple?. Pues sobre estos principios tenemos una gran herramienta para probar, equivocarnos, investigar y aprender. Pero Dave no solamente compartió sus reflexiones si no que fue publicando semanalmente un listado de ejercicios a los que llamó Code-Katas. Kata es el nombre que se le da a un tipo de ejercicios de Karate que consisten en repeticiones de ciertas posiciones y movimientos, buscando la mejora constante en pequeños pasos; y es el nombre que eligió Dave y con el que conocemos a esta técnica de aprendizaje.
Ventajas y precauciones
La principal ventaja de esta manera de prácticar es que nos acostumbra a atacar los problemas de múltiples formas, sin prisas, sin estar pendiente de los errores o de romper nuestro trabajo o el trabajo de algún compañero. Sin pensar en documentación, análisis o metodología. Disfrutar del reto intelectual, como si fuera un crucigrama o una buena lectura. También el tener una lista interminable de Katas publicadas en la Web, nos permite enfrentarnos a retos a los cuales no estamos habituados en nuestro trabajo diario o, simplemente, no se nos hubiera ocurrido.
La llegada de TDD le ha dado una vuelta de tuerca a las Code-Katas ya que le sumamos el ciclo red-green-refactor y utilizamos la práctica para hacernos a esta nueva técnica de desarrollo que es tan extraña para quien no está acostumbrada a ella.
La única precaución que se debe tener en cuenta es que estamos haciendo prácticas con ejemplos ideales y dirigidos. Es decir, muy raramente nos vamos a encontrar problemas tan simples y sencillos en el mundo real. Y, como dice el dicho, la realidad siempre supera la ficción. También hay que no caer en la tentación de igualar Code-Kata con TDD. Se puede hacer una Code-Kata sin tan siquiera test unitarios, siempre que el feedback sea el suficiente.
Practicar, practicar, practicar.
Vía: Code-Kata. How It Started. Más información: 12 meses, 12 katas, Coding Dojo
