Hoy hemos trabajado juntos por primera vez en la kata de los Roboexplorers (no encuentro ahora un nombre mejor) en el coding dojo de Bilbao. Gracias a @vgaltes y @plainconcepts por ceder el espacio y ser tan buenos anfitriones.
¿De qué van los roboexplorer? Son robots (autónomos) que juegan en un servidor de juego. Como dijo @jmbeas, es algo como la idea de @mattwynne, aunque la idea de robots en servidores es más vieja, la ví por primera vez hace mucho en la universidad.
En este caso se trata de aplicar los principios ágiles a un desarrollo que tiene un objetivo un poco distinto al de una kata tipoe StringCalculator. Se trata de escribir el mejor código posible pero llegando a producir “valor para el cliente”, es decir, algo que funcione, por poco que sea lo que haga. Así que no sólo está el código, sino elegir la estrategia que produzca un resultado con valor en el menor tiempo posible y sin embargo, sin prisas.
He ideado un juego muy sencillito basado en el buscaminas y me he puesto a programar un robot y tambien un motor de juego. Al programar ambas cosas traté de analizar las ventajas y las dificultades de usar TDD para el diseño y la implementación de ambas cosas.
Sabemos de sobra que TDD es genial cuando el problema es fácilmente fraccionable en subproblemas. Cuando la división es intuitiva, la aplicación de TDD también lo es y se hace directa.
Sin embargo, cuando el problema se presenta con un nivel de abstracción mayor, es más dificil pensar en su composición.
Al programar el servidor de juego, el cual se basa en validación del estado, la aplicación de TDD no sólo ha sido fácil y directa sino imprescindible a la hora de abordar la gran casuística que se puede presentar. Sin embargo, al diseñar el robot, he terminado con más código de test que código de producción. Aproximadamente el doble.
Ha sido natural usar TDD por la costumbre de programar sólo lo que pide una especificación pero ha habido que prestar mucha atención a la fragilidad de los tests, ya que la mayoría se basan en la interacción (dobles a saco). Al ir haciendo cambios en los requisitos se ha notado enseguida el beneficio de tener una batería de tests de respaldo pero me quedaba la duda de si TDD me había ayudado a hacer emerger el diseño o si la arquitectura que tenía en mente me había aportado toda la información que necesitaba. Es decir, hasta qué punto, unos tests que te están contando con cierto detalle el comportamiento interno de tu código de producción te ayudan escribiéndolos a priori y no despues.
Cuando el código de producción ha quedado tan pequeño, la única ventaja clara es la atención que le prestas a la “testabilidad” del código y la calidad de la batería de tests que queda, lo cual no es poco. Es decir, si en este caso no hay más beneficios, lo haría por eso.
He querido presentar el problema a la gente y estudiar cómo lo abordaban. Cómo se enfrentaban a un problema que te requiere un cierto esfuerzo arquitectónico. Sin contarles nada del problema antes, para verles trabajar desde el momento cero. Por eso de momento no vamos a publicar las reglas del juego, para probarlo en más dojos por diferentes ciudades.
El resultado en este primer dojo ha sido que nadie ha terminado una
primera versión del robot. La gente empezaba a tirar líneas, con los tests por delante, pero sin saber hacia donde ir. Perdiendo el objetivo de alto nivel y sin terminar de saber qué comportamiento querían darle. Se han oido algunas frases como “TDD es bueno para el validar entrada y salida pero no para validar comportamiento, para eso mejor BDD”. Esto es un indicador de que no tenemos maduro el concepto de diseño marcado por ejemplos, que es el significado de TDD y BDD. Siempre digo que TDD y BDD son lo mismo, para mí el concepto es el mismo.
Parece que la gente se empieza a defender con las katas tipo StringCalculator pero que no practica TDD/BDD en su día a día. Parece que hay un cierto malentendido entre TDD y la arquitectura o el diseño.
TDD no es ponerse a tirar código esperando que el objetivo que queremos emerja, lo que emerge son los pequeños detalles, pero no la finalidad. Esta la tenemos que saber nosotros primero para guiar la marcha con paso firme. El código te habla y te guía cuando sabes a dónde quieres ir, pero no te ayuda si tu no sabes hacia dónde vas.
En este experimento hay mucha más información que extraer como por ejemplo, de qué manera reutilizamos la información y el propio código que extraemos de los spikes. En este caso lo que ha ocurrido es que los spikes han sido directamente incluidos en código de producción, tan pronto como daban un resultado plausible. Logicamente esto nos ocurre a todos, por eso es interesante hacer el ejercicio y poner la cámara lenta a ratos.
Hacia el final de este primer dojo, los intrépidos participantes han ido encontrando el camino que les ofrecía sensación de rumbo correcto y si hubiesemos tenido tal vez un pomodoro más hubiésemos tenido robots funcionales y certeros.
Hay más matices que ya se irán contando en otros blogs y que iré enlazando desde aquí.
La idea ahora es repetir el dojo en más sitios y seguir sacando conclusiones juntos. De aquí a la CAS 2011 que se celebrará en Castellón en el último cuarto del año, vamos a ver si conseguimos completar un estudio riguroso acerca de todo esto.
Aviso que el dojo puede llegar a ser frustrante por su dificultad, pero… esto es un dojo, no un curso de TDD 😉
Después de varios dojos pondremos el código del servidor en la red para que cualquiera pueda practicar con sus propios robots y podremos incluso organizar un campeonato.