Números mágicos

Hace tiempo que llevo pendiente compensar el desequilibrio en artículos técnicos que últimamente tengo en el blog, así que aquí va éste.

El pasado día 22 de diciembre celebramos el segundo aniversario del primer coding dojo que organizamos como AGILISMO.es. Luis Rivera, siempre disponible para echarnos una mano, nos prestó las instalaciones de Okuri, también conocidas como Tetuan Valley porque allí tiene la sede esta iniciativa de incubación y aceleración de startups en Madrid. Echamos de menos a Alejandro y Roberto, de Autentia, a los que tanto tenemos que agradecer durante estos dos años. Pero junto a los habituales también estuvo gente nueva. Eso es buena señal.

Hasta aquí no parece un artículo técnico, ¿verdad? Bueno, pues al grano. Durante el desarrollo del coding dojo, con la PomodoroKata como ejercicio, surgió un debate sobre si dejar el número 25 en los primeros pasos del desarrollo es aceptable o no. Xavi defendía la sustitución del 25 por una constante por tratarse de un número mágico mientras que opinaba que era suficientemente expresivo y que el refactor era prematuro.

Como podeis comprobar en el video de la kata que grabé hace ya dos años, yo también prefiero sustituir el 25 por una constante (minuto 1:40 aprox) por las siguientes razones:

* el método minutesLeft devolviendo 25 es menos expresivo que minutesLeft devolviendo DEFAULT_DURATION
* en el test también hago este refactor aunque el título del test es incorrecto y debería decir "Un pomodoro tiene una duración por defecto", porque realmente me es indiferente cuál sea esa duración
* si realmente hubiera querido probar que la duración por defecto es 25 entonces debería haber tenido un test del tipo: assertEquals("La duración por defecto es 25", 25, Pomodoro.DEFAULT_DURATION), lo que nos habría llevado a pasar esa constante de privada a pública.

Como veis, mis argumentos están basados en la expresividad del código y en que se ajusten a lo que se quiere probar. El trabajo más difícil es siempre elegir bien los tests porque, dependiendo de ellos, nuestro diseño y posterior implementación tomarán un rumbo u otro.

BeCodeWeek : Día 5

Ayer empleé la mañana en bloguear y algunos asuntos relacionados con mi salto al vacío en los que, por cierto, Xavi me echó una mano muy importante para enfocarme.

Después de comer le dimos un empujón muy serio a la kata para la XGN porque, entre otras cosas, esa misma tarde habíamos quedado con Ricardo Borillo y otros más para practicar con ella. Cuando llegaron ya estaba suficientemente enfocada y todos accedieron amablemente a servirnos de conejillos de Indias. Xavi hizo una presentación muy clara de la kata. Era como si hiciera meses que estuviera escrita. Aún tenemos que trabajarla un poco más, pero si la XGN fuera esta tarde ya podríamos hacer este taller con perfectas garantías. Trabajar con Xavi da una gran seguridad. Tanta que a veces da miedo. :-D

Poco a poco fue llegando todo el mundo. Emma y algunos compañeros de OpenFinance. Y poco a poco todos los demás. Hasta Ricardo Borillo, que venía de Castellón. Mientras llegaban todos, Emma me hizo una pregunta muy interesante y para cuya respuesta tendré que escribir un post entero: cómo desplegar Fitnesse en Integración Continua y con Control de Versiones. Como yo nunca he usado Fitnesse en Integración Continua sino Fit, no supe bien qué contestarle. Me sonaba pero nada concreto, así que acudimos a Google y, tras varias búsquedas, llegamos a estos dos videos de UncleBob (el autor de Fitnesse):

  • http://vimeo.com/2498115 Cómo preparar Hudson para ejecutar la integración continua del proyecto Fitnesse (no entra en detalle sobre cómo se ejecutan los tests de Fitnesse, pero ya es un punto de entrada)
  • http://vimeo.com/2765514 Enseña cómo usa él Git para controlar las versiones de sus especificaciones con Fitnesse, con lo que se aprende un poco sobre cómo guarda esta herramienta sus ficheros.

Ambos son videos de hace ya un par de años por lo menos, pero si, como Emma, te estás planteando darle una oportunidad a Fitnesse, quizás te merezca la pena echarles un vistazo.

Durante un par de horas estuvimos completamente absorbidos por la práctica de la codekata. Verdaderamente nos ha salido una kata bastante completa y, a la que nos despistemos, demasiado larga en su resolución. Tendremos que trabajarla bastante aún si queremos mostrar una solución limpia en la XGN. Otra opción es simplemente dejar el enunciado y que los que vengais trabajéis mucho, je, je. Veremos si podemos hacerlo todo porque también tenemos que preparar el taller de backlog y eso va a necesitar mucha más atención por nuestra parte.

Al terminar ese coding dojo privado nos fuimos a cenar. Yo había propuesto pedir algo a un uruguayo muy majete que hace comidas para llevar, pero no hubo mucho éxito. Luego confesaron que ninguno quería dar la impresión de falta de compromiso haciendo una llamada durante el dojo. . Terminamos comiendo muuuy tarde, pero no fue tampoco un , ni mucho menos. Pasé un rato muy interesante entrevistando a para . Esta vez en video y, por supuesto, con mucho ruido de fondo. :-D

Luego estuvimos hablando sobre la organización de la CAS2011, que este año, gracias a Ricardo, se hará en la Universidad Jaume I de Castellón. Estuvimos escuchando sus planes y, la verdad, ¡ésta no me la pierdo!

 

Ahora estoy esperando a Xavi para conocer algo de Valencia, que he venido y no he visto casi ná. :-)

BeCodeWeek : Día 4

Ayer sólo hice tres cosas: blog, taller de product backlog y coding dojo. La primera no merece la pena mencionarla salvo que empleé casi toda la mañana. Después me puse a avanzar (no mucho, la verdad) en la codekata que estamos preparando para la XGN. Cuando llegó Xavi de conseguir dinero (contratos para casi todos los colaboradores) era ya casi hora de comer. Sin embargo, asistí a un momento muy interesante. Miguel Angel levantó la mano (metafóricamente) para avisar de que estaba teniendo problemas para avanzar al ritmo esperado. Xavi le echó una bronca (muy amable y didáctica, eso sí). Le explicó que había que avanzar en base a certezas y dejarse de tratar de demostrar más de una cosa en cada paso. En este caso, la iteración consiste en hacer una prueba de concepto, una bala trazadora que demuestre que la arquitectura funciona y que se puede hacer lo que se pretende. Y Miguel Angel lo entendió perfectamente y, en vez de responder a la agresión, reaccionar de una manera sumisa o bloquearse y pedir la solución concreta, explicó cuáles iban a ser sus siguientes pasos: de qué iba a prescindir para poder avanzar y en qué se iba a enfocar para conseguir el objetivo de la iteración. Y todo eso, con el cliente delante y con total naturalidad. Chapó. Es evidente que ser un punk no está reñido con ser un gran profesional.

Después de comer tomando el sol en la plaza de la Catedral con @luislitze y , volvimos a para tomar un cafelito y, mientras llegaba un cliente para preparar una visita a una feria de inversores en San Francisco, conseguí sacar la media hora mínima para empezar a trabajar el taller de backlog que también tenemos que preparar para la XGN. Surgieron conversaciones muy interesantes y creo que va a quedar muy bien. Este taller me lo voy a tener que preparar especialmente bien porque Xavi quiere sacarme de mi zona de confort y que lo lidere yo. Me gusta, porque es uno de esos empujones que necesito para saltar al vacío y porque tiene mucho que ver con un terreno en el que me siento especialmente cómodo: los criterios de aceptación (que idealmente deberían estar automatizados).

Y al final de la tarde ya nos fuimos yo con mi camiseta de agilismo.es y Miguel Angel con la de BeCode al Coding Dojo que se celebraba en la Escuela de Informática (la ETSINF). Xavi, por supuesto, iba con sus pintas de siempre. Las mismas que había llevado para visitar a un cliente y conseguir varios contratos, por cierto.

En la ETSINF me buenas instalaciones, aunque para ser la Universidad, muy poca audiencia. Eso sí, al final tuvimos conversaciones muy interesantes con algunos de los asistentes. Durante el ejercicio dimos varias recomendaciones de libros: “Refactoring“, “Implementation Patterns“, “TDD by example“, “Desarrollo Agil con TDD“, “Clean Code” y, por supuesto, “The Pragmatic Programmer“. A los que quedaron al final, charlando con nosotros sobre lo poco que se aprende en el trabajo, también les recomendé “Apprenticeship Patterns“.

La codekata que propusieron Miguel Angel y Xavi era FizzBuzz. No me deja de sorprender esta kata por la cantidad de cosas que se pueden practicar y cómo, siendo tan simple, te permite hablar de tantas cosas: naming, refactor (no sólo los refactors “hacia adelante”, sino también los “hacia atrás”), duplicación, código limpio, baby steps… Tanto es así, que me he empezado a reproducir la kata en el portátil usado git y poniendo un comentario en cada commit. Cuando lo tenga lo subiré a github.

Y bueno, cena con una agradable conversación con Miguel Angel y a la cama.