Lecciones aprendidas en la XPWeek

Como bien ha indicado Carlos Blé , resulta interesante realizar una retrospectiva ahora que se ha terminado la XPWeek.

Aún no he visto las conclusiones de Carlos Blé, porque quiero sacar las mías propias. Veamos qué surge de aquí:

La primera lección aprendida es que si necesitas probar una plantilla, lo mejor es pasar las condiciones al código. No se puede probar la plantilla, pero sí el código. De esta manera, se pueden sustituir las condiciones de la plantilla por herencia, y elegir el tipo de plantilla a utilizar desde el código.

La herencia debería realizarse en positivo, es decir, que siempre es mejor añadir cosas nuevas que quitar cosas que ya había. Esto lo descubrimos porque la plantilla del usuario no autorizado heredaba de la del usuario autorizado, cuando debería ser justamente al revés. El beneficio es simple: resulta más natural y, por tanto, más fácil de entender.

Algo en lo que nos insistió muchísimo Carlos es en que no debemos mockear algo que no es nuestro. Pero descubrimos que resulta sencillo apropiarse de una funcionalidad mediante una factoría. Por eso creamos una factoría que nos devolvía información de sesión, y que podíamos manipular a nuestro antojo.

Casi sin darnos cuenta, comenzamos un diseño por capas en el que falseábamos la entrada con objetos fake e incluso reales, y mockeábamos la capa siguiente. Es decir, que es preferible utilizar objetos reales en la entrada (salvo alguna operación a modificar, como comprobar si un usuario está autenticado) y mockear la capa siguiente para forzar los test.

Ya que están saliendo los dobles de prueba, aunque ya lo traía aprendido mencionaré aquí que:

• Es un stub si tiene precondiciones.
• Es un mock si tiene postcondiciones.
• Es un spy si no tiene ni pre ni postcondiciones, pero recuerda todo lo que ha pasado. Es una manera de tener un mock o un stub más versátil.

Otra lección más consiste en que siempre es mejor utilizar una clase que una tabla Hash. Una tabla Hash siempre será una tabla Hash, mientras que una clase con un modelo anémico puede crecer al incorporar métodos como toString, equals,… y terminar teniendo su propia funcionalidad.

De la misma manera, cuando una función recibe más de 3 parámetros es un buen momento para comenzar a plantearse crear una clase que embeba estos parámetros. Resulta más sencillo añadir parámetros si se han metido en una clase que si se están pasando por parámetros, ya que los parámetros nos invalidan todos los tests mientras que la clase puede tener valores por defecto. Esto resulta especialmente útil con los parámetros que se van a pasar mediante GET o POST, que deberían ser un DTO (Data Transfer Object, ¡si hasta la abreviatura lo dice!).

Además, no es bueno utilizar un objeto de base de datos como DTO, ya que nos impide el crecimiento del DTO hacia algo más útil y nos puede inducir a error. Además, se mezclan capas de una forma un poco extraña.

También aprendí lecciones de XP: cuando tu tiempo está limitado, tienes que ofrecer el máximo posible. No vale quejarse, sino que hay que ser positivo. Además, cuando se trabaja por parejas, las reglas cambian, y hay que evitar interrumpir constatemente al que escribe, y otras reglas igual de interesantes que tengo que pedirle a Carlos. También he aprendido que hay cosas que no pueden emerger del código, pero que siempre que sea posible es recomendable dejar que el código imponga sus propios requisitos. Las propias pruebas nos orientarán en este sentido.

Cuando se comienza un proyecto relámpago, hay que dominar las herramientas de trabajo en grupo. Yo siempre he utilizado Mercurial yo solo, y nunca me había hecho falta compartir mi repositorio local, por lo que las conocía bien pero no lo suficiente.

A parte de todo esto, también hemos aprendido lecciones sobre algunas herramientas. Por ejemplo, con hamcrest tienes un número de matchers muy interesante; Groovy es un lenguaje a tener en cuenta, sobre todo cuando programas en Java; JavaScript puede resultar legible y puedes abstraerte de tu framework;…

También algunas lecciones personales, como que hay que llegar al tren 2 minutos antes y que no te cambian un billete cuando el tren ya ha salido. Y que, definitivamente, hay que aprender más javascript. :D

Finalmente, agradecer a todos los participantes el buen rollo existente y a Carlos , Alberto y Enrique por sus geniales lecciones.

Para la próxima: ¡¡Foto de grupo!!