Aprendizajes durante los primeros coding dojos en Madrid
Desde el COVID 19, numerosos grupos de desarrolladores se reúnen a distancia mucho más que en persona. Cuando empezamos a planificar un día de coding dojo en Madrid, la cuestión de ser remoto o presencial era un gran dilema.
En consecuencia, empezamos a plantear posibles actividades para averiguar si habría gente interesada en reunirse para hablar de tecnología en persona.
En primer lugar, empezamos con tres sesiones de coding dojo en un intento de contar una historia completa de lo que es el día a día de un desarrollador: escribir código TDD (baby-steps), ajustar el estilo TDD en función del problema (outside-in) y refactorizar.
A continuación evaluamos cada una de las sesiones y cerramos con un resumen de nuestras experiencias y lo que estamos planeando para el futuro.
TDD, baby steps
Empezamos con un kata clásica de nuestro catálogo: Mars Rover. Esta kata tiene dos niveles, Simple Mars Rover y Mars Rover.
Mars Rover propone un reto en el que un programador tiene que diseñar la aplicación de un rover (robot explorador) que se encuentra en Marte en un tablero de 10 x 10. El sistema interpreta los comandos que se envían al rover y luego el rover reacciona a estas entradas. La kata Simple Mars Rover tiene un número reducido de funcionalidades a implementar y Mars Rover toma todo lo de la versión simple y le añade obstáculos.
En nuestro primer dojo elegimos la Simple Mars Rover por su enfoque en baby-steps junto con TDD. Dado que aún no conocíamos a nuestra comunidad, empezar con pequeños pasos tenía sentido.
Empleamos la dinámica de trabajo por parejas (pair programming), como solemos hacer en Codurance, y enfocados en las buenas prácticas.
Al inicio hicimos una exploración con los participantes de la kata, dejamos 5 minutos para elegir las parejas y no añadimos ninguna restricción de lenguaje de programación, cada pareja eligió la suya.
Al final, cerramos con una aportación de cada participante y hablamos de cómo había transcurrido la sesión y de las distintas soluciones que se habían debatido.
Outside-in
En nuestra segunda sesión de TDD elegimos enfocarnos en el estilo de Londres, también conocido como outside-in mockist.
Esta vez elegimos la Bank kata, otro ejercicio clásico para entrenar nuestras habilidades técnicas. Nuestro objetivo era explorar cómo sería desarrollar una aplicación manejando test doubles.
Los test doubles, en otras palabras, son el siguiente paso una vez que se está acostumbrado al flujo TDD y a los baby-steps. Los doubles son las funcionalidades que nos permiten aislar comportamientos que son difíciles de controlar como, por ejemplo, el manejo de fechas o las interacciones con la base de datos.
La dinámica utilizada fue la misma que en la sesión anterior: por parejas. Cada pareja eligió el lenguaje de programación con el que trabajar.
En esta ocasión, la diferencia fue que empezamos con una breve charla sobre qué son los test doubles para que todos los participantes estuvieran en el mismo punto de partida.
Refactorización
Para cerrar el ciclo, la kata elegida fue Gilded Rose, el tercer ejercicio clásico en el que el foco está puesto en la refactorización y en cómo nos apoyamos en las pruebas de caracterización para mejorar el código sin cambiar su comportamiento.
Para esta última sesión cambiamos la dinámica basándonos en el feedback que recibimos de los participantes. No formamos parejas, sino que utilizamos el método Randori. Este método se centra en el aprendizaje en grupo, donde tenemos un teclado, una pantalla y un par de rotaciones cada cierto tiempo. Para nosotros fueron 10 minutos.
El cambio nos ha ayudado a centrarnos todos a la vez en el mismo problema. La sensación de aprendizaje al final de esta tercera sesión ha sido mayor que en las dos anteriores.
¿Y ahora qué?
La sorpresa de los coding dojos presenciales fue la asistencia de los participantes. Dado que nos encontramos en un periodo de transición entre la modalidad totalmente remota y la parcialmente remota, era difícil imaginar que los participantes estuvieran dispuestos a reunirse de manera física.
Al mismo tiempo, la comunidad que se está creando en torno a los coding dojos sigue creciendo con personas de distinta procedencia y formación, pero con el mismo interés común por la calidad de software y el desarrollo artesanal.
El circuito que proponemos cubre un porcentaje de las actividades que un desarrollador suele realizar en su jornada normal de trabajo.
Empezamos con baby-steps y TDD, seguimos con el TDD outside-in mockist y cerramos con la parte de refactorización.
Tras las primeras reuniones y dinámicas, hemos visto que aún hay margen para explorar cómo abordar la transición de las katas, que tienen un enfoque de aprendizaje, a un proyecto comercial como API REST.
Ya hemos empezado a abordar este tipo de escenario.
En el coding dojo del 11 de abril hemos explorado la Bank Kata con un setup de REST API. El código está disponible en GitHub con el setup y la solución que hemos empleado.
¡Nos vemos a la vuelta de verano con nuevas fechas!
