Primer coding dojo en #xdp

El pasado jueves 28 de abril, la comunidad #xdp celebró su primer coding dojo en Sevilla, con la colaboración de emergya que nos facilitó sus instalaciones.

Un coding dojo no es más que juntarse un grupo de personas a resolver un ejercicio de código (kata) por el mero hecho de practicar, con el objetivo de mejorar nuestras habilidades y discutir sobre el código que vamos produciendo.

Juanma Laó escogió para la ocasión el ejercicio de abril propuesto por la iniciativa 12 meses 12 katas, la kata del bowling.

Nos juntamos 6 personas, y tras las presentaciones de rigor y una breve introducción a TDD empezamos a analizar el problema.

Javi Soler y Juanma Laó (juanlao)

Javi Fernández (Mudi) y Pablo Escribano (huelvafriki)

Christian López (penyaskito) y Víctor Ramírez (virako)

Menos mal que vino Javi Soler que sabía jugar a los bolos, porque el enunciado me resultó un poco complicado de entender.

Javi Soler nos explica la puntuación de los bolos

Nos sentamos por parejas, y empezamos a hacer las pruebas. En contra de las otras 2 parejas que eligieron c#, Virako y yo elegimos python, con la librería unittesting para las pruebas.

Tras unos cuarenta minutos de programación, pronto iniciamos una discusión sobre qué pruebas habíamos hecho. Unos optamos por implementar las pruebas sugeridas por el problema, otros por pruebas más simples en función de distintas partidas con distinta complejidad de cálculo de puntuación de la partida… También discutimos sobre cómo habíamos o no decidido prematuramente el algoritmo a utilizar para calcular la puntuación. Es curioso como tres parejas distintas abordamos de forma totalmente distinta tanto los algoritmos como el enfoque de la kata.

Al final se nos hizo tarde, y tras tres horas de (poco) código y (mucha) discusión, disolvimos la reunión no sin antes hacer la retrospectiva de la sesión. Para mi, siendo mi primera kata en grupo, la experiencia fue muy enriquecedora.

Imagen de la pizarra tras la retrospectiva

FindBugs

Las herramientas de análisis estático de código permiten encontrar fallos potenciales mediante búsquedas de patrones en el código.

La pionera en esto del análisis estático fue Lint, una herramienta que apareció en 1979 y estaba incluía en el propio compilador. Desde entonces Lint es usado como nombre genérico de este tipo de herramientas.

Puedes ver una lista de herramientas de análisis estático para distintas plataformas en la Wikipedia.

Había utilizado FxCop en el trabajo, y le eché un vistazo a JSLint con OpenLayers. Pero nunca me había parado a buscar una herramienta similar para aplicaciones Java.

Pues bien, recientemente encontré FindBugs. Y por supuesto, la he probado con ArgoUML.

FindBugs es una herramienta opensource desarrollada por la Universidad de Maryland. Desarrollada en Java, tiene una interfaz simple pero efectiva.

Seleccionamos donde están nuestros jar y el código asociado y se pone a analizar el código (puede tardar un ratillo).

Nos muestra un árbol con los errores clasificados por categorías, mostrando para cada uno el código donde aparece y cómo debería mejorarse.

Gracias a esta herramienta se puede incrementar el rendimiento de una aplicación además de eliminar bugs potenciales. En las próximas semanas trabajaré en eliminar estos fallos en ArgoUML.

PD: Esto es posible porque desde ayer tengo permisos de escritura en todo el repositorio 🙂

Test Driven Development: Antipatrones

Que no tenga tiempo actualmente para escribir no significa que no lo tenga para leer.

James Carr nos muestra una lista de antipatrones a evitar cuando nuestro desarrollo es orientado a pruebas: TDD Anti-Patterns Catalogue.