Comentando el libro “the art of agile development”

XP
Imagen de http://www.extremeprogramming.org/

Introducción

El libro the art of agile development trata de TODAS las etapas de un desarrollo utilizando XP. He escrito todas en mayúsculas porque el libro es muy completo y habla de cada etapa con mucho detalle.
Los autores del libro son James Shore y Shane Warden. James Shore lo conocía de antes porque tiene una página sobre TDD en Javascript que tiene muy buena pinta:

http://www.letscodejavascript.com/

Dentro de cada capítulo hay un apartado con posibles preguntas que nos podemos hacer, problemas que podemos tener y posibles alternativas a ciertas prácticas.
Al ser un libro muy completo y con muchos detalles, es muy fácil el encontrar una pequeña joya en forma de consejo en muchas de sus hojas.

Hay, a continuación, un apartado sobre XP y luego una serie de conceptos que aparecen en el libro y que me han gustado especialmente. Estos conceptos son root cause analysis, informative workspace, pair programming y theory of constrains.

XP

Extreme programming (XP) es una metodología que a diferencia de otras metodologías Agile se centra mucho en prácticas para los programadores.
Así, dentro de las prácticas de XP tenemos pair programming, TDD, simple design y refactoring.
Todas estas prácticas permiten que el equipo se centre en llegar a la excelencia técnica, que es uno de los principios detrás del manifiesto Agile.
Creo que tener estas prácticas es algo que la diferencia de otras metodologías y que puede hacerla que tenga mayor número de éxitos, pero que a su vez resulta complicado de implantar al tener más prácticas que, por ejemplo, Scrum.
Si quieres saber más sobre XP, en la siguiente página hay mucha información sobre esta:
http://www.extremeprogramming.org

Root cause analysis

Root cause analysis es un método que nos permite llegar a la raíz de un problema. En nuestro caso, lo podemos utilizar cuando nos encontremos con un error en nuestro código de producción.
Cuando nos encontremos con un problema en nuestro código debemos de preguntarnos 5 veces el porqué se ha producido.
Una cosa importante sobre este tema y que comentan en el libro es que resulta fácil el culpar a una persona del problema, pero que detrás de la persona tenemos nuestro proceso de desarrollo, por lo que si tenemos que culpar a alguien hay que culpar a nuestro proceso y, luego, intentar mejorarlo.

Informative Workspace

La idea es muy simple, añadir información relevante relativa al proyecto en la zona de trabajo.
Tener una zona de trabajo con información del proyecto permite a todo el equipo y a la gente fuera del equipo el ver el progreso de este, simplemente caminando alrededor.
El objetivo principal de esta práctica es la información. Difundir información entre todas las personas involucradas en el proyecto.
Los gráficos deben de estar en este espacio porque permiten de una forma simple, eficaz y sin malentendidos el informar. Hay principalmente dos gráficos en XP y son: iteration plan y release plan.
También comentan que es mejor utilizar un bolígrafo y un papel en vez de pantallas, debido a que nos da más flexibilidad y en que de un solo vistazo se puede ver todo.
Creo que otra de las cosas en las que ayuda estas prácticas es en aumentar la confianza de los stakeholders en el equipo ya que pueden ver en todo momento el estado del proyecto.

Pair programming

Lo primero que llama la atención sobre pair programming en el libro, es que esta en la sección de pensar (thinking). Lo que nos da una idea para que lo utilizan los autores.

Esta práctica mejora, según los autores, el poder mental (brainpower) mientras estamos programando. Así, mientras el que esta programando (driver) solo esta pendiente de desarrollar, la otra persona (navigator) tiene como tarea la de pensar.
Cuando practicamos pair programming no es que dos personas este realizando el trabajo de dos, sino que se divide el trabajo, uno programa y el otro piensa. No es que el que programa no esté pensando sino que la pareja tiene mas tiempo para hacerlo.

He practicando pair programming en los coderetreat y todas las veces acabé muy cansando porque al estar con una pareja estas todo el tiempo concentrado al 100%. Otra gran cosa es que se aprende muchísimo y creo que en general todo el mundo tiene la misma sensación.

Theory of constraints

La teoría de las limitación dice que en todo sistema hay una y solo una limitación y que esta es la que provoca que se ralentice el sistema.

XP considera que la limitación en software development es el desarrollador. Eso es algo que se dice muchas pero que muchas veces en el libro.
Después de leerlo tantas veces estaba algo mosqueado porque aunque es cierto que los programadores podemos mejorar para que el sistema vaya mejor creo que hay otras posibles opciones. Como puede ser los managers que en muchos cosas ralentizán el trabajo de los programadores con sus decisiones, o la poca integración de la gente de negocio en el proceso de desarrollo.
Escribí un tweet y tuve la suerte de que jb me respondió.

Is the developers the constraint in software developer? why? @jbrains @ronjeffries
— Enrique Martín (@kikers25) January 21, 2015

 

Resumen

Aunque tiene unos años es un libro muy recomendable. Me ha ayudado a entender XP y todos las prácticas relacionados con XP.
Tiene muchos consejos sobre cómo implantar XP en una organización y creo que son muy útiles.

Personalmente, me encantaría practicar XP porque aunque sé que las primeras semanas o meses voy a estar muy cansado, debido principalmente a pair programming, voy a poder aprender muchísimo y creo que el resultado final va a ser un gran producto.

*Modificado 25-03-2015: añadido enlaces al libro e información de los autores

Ejemplo de código Java hecho con TDD (con historia incluida)

programming challenges
Imagen de http://www.programming-challenges.com/

Hace algunos meses estaba buscando un nuevo trabajo como programador, y una de las cosas que suelen pedir en Holanda, para medir las habilidades de los candidatos, es un ejemplo de código.

Por lo que he vivido durante esos meses, hay un número grande de empresas que no solo quieren un ejemplo de código sino que te piden resolver un problema concreto en un tiempo determinado.

En una de las empresas, el problema que me pidieron resolver me pareció interesante. El problema era el construir una aplicación que calculara la fecha en la que un cliente tendría su pedido listo, teniendo en cuenta la fecha actual del sistema y el tiempo que se tarda en realizar la tarea.

El ejercicio lo hice completamente utilizando TDD y me costó (creo recordar) dos semanas, utilizando horas de mi tiempo libre, ya que tenía trabajo.  Lo tuve que hacer dos veces, debido a que la primera vez, la solución que había elegido en un punto me estaba complicando el añadir más test sin romper los test anteriores.

Después de enviar mi solución al problema, me quedé a la espera de recibir información de si les había gustado, y si era así, si me invitaban a una entrevista. Estaba bastante ansioso de recibir la respuesta porque terminé bastante contento de como me quedó.  No es que sea perfecto el código, sino que era la primera vez que enseñaba mi código a alguien después de haber aprendido TDD.

Nunca recibí ningún tipo de feedback sobre el código y ni siquiera se dignaron en decirme nada de porqué se estaban retrasando tanto.

Ya que no he recibido ningún tipo de feedback y que me quedé con ganas, lo he publicado en GitHub y estaré más que encantado de recibir cualquier tipo de comentario.

No he añadido muchos detalles sobre cual es el problema porque no quiero dar pistas sobre cual era la compañía, pero creo que los comentarios que añadí en el código y los test hacen que resulte fácil de entender.

El enlace al código es:

https://github.com/kikers25/programming_challenge

El ejercicio está hecho con maven y java 7. Las librerías que utilicé son: JUnit 4, hamcrest, Joda-Time y pitest.
Pitest es una librería que mide la cobertura del código utilizando “mutation testing”. Hay un artículo en español muy bueno que explica muy bien qué es “mutation testing”:

http://testeandosoftware.com/mutation-testing/

Dobles de test con jMock en un ejemplo

Introducción

En los dos últimos artículos (este y este) hemos visto cómo crear nuestros propios dobles de test. En este artículo vamos a ver un ejemplo de una librería de dobles de test: jMock.

jMock

Hay muchas librerías de dobles de test, como easyMock, Mockito y JMockit. La mayoría de esta librerías están bien y te van a ayudar a crear dobles de test que te faciliten el trabajo de testear una clase.

Yo utilizo jMock porque me ayuda a mejorar el diseño de mi código. Por defecto, nos obliga a tener que declarar de forma explícita cuales son las llamadas que todos los dobles de test que utilicemos en nuestro código a probar.
Si, por ejemplo, en un método tenemos un doble de test que llamamos a tres de sus métodos, tenemos que especificar que permitimos la ejecución de los tres métodos.

Al tener que añadir todas las llamadas al principio del test, podemos ver si hay algo que huele mal (smell) en nuestro código, y así poder mejorar nuestro diseño.

Un inconveniente de jMock comparado con otras librerías como easyMock es que es más complicado de leer el código, pero personalmente es más que suficientemente legible el código.

Ejemplo

En el artículo sobre dobles de test de tipo spies, hay un ejemplo con dos tipos de dobles: spies y stub. Vamos a utilizar ese mismo ejemplo, junto con el mismo código de producción pero añadiendo un test utilizando jMock. Al tener un test con dobles de test hecho por nosotros y otro test con dobles de test de jMock nos va a permitir el ver la diferencia de utilizar la librería y nuestro código.

Vamos a utilizar el mismo código de producción y añadiremos al código de test un nuevo test utilizando jMock.

Creo que el código de producción que aparece arriba es fácil de entender, pero si necesitas alguna explicación extra, en el artículo sobre spies puedes encontrarla.
A continuación, el código de test.

Ambos test hacen lo mismo, comprueban que UserService.findOrCreateWith llama al método sendEmailTo de EmailService, o lo que es lo mismo, comprueban que se envía un email.
La mayor diferencia entre ambos test es que el primero falla cuando nuestro doble de test devuelve false y que el segundo falla lanzando una excepción.

El test con nuestro código de dobles de test comprueba de forma explícita que es llamado el método. Y el test con los dobles de test con jMock comprueba de forma implícita que es llamado el método.

El test should_send_an_email_when_a_user_was_created_with_jmock, dentro de Expectations comprueba que es llamado un vez el método EmailService.sendEmailTo en:

Nuestro doble de test también podría lanzar una excepción cuando no es llamado el método, pero para ello tendríamos que crear un método que realizara la comprobación y lanzara la excepción. Este método debería de utilizarse al final del test.
jMock no necesita que llamemos a ningún método para comprobar las llamadas a los colaboradores porque siempre comprueba internamente (gracias a la anotación Rule) al final de cada test si las expectativas de cada doble de test fueron satisfechas.

Dobles de test propios o librería

Cuando descubrí los dobles de test, los creaba todos a mano, pero ahorré mucho tiempo cuando empecé a utilizar librerías.
Actualmente la mayoría de mis dobles de test los creo con jMock.

Aunque utilizo mas jMock que mis propios dobles de test, siempre hay casos en los que resulta mucho más fácil el crear mis propios dobles de test.
Por ejemplo, cuando resulta complicado el añadir un doble de test con jMock siempre utilizo mis propios dobles de test.
Otra ejemplo sería, cuando no voy a utilizar para nada en los test un colaborador creo un doble de test de tipo dummy o stub para que sea más fácil de entender el test.