Una de los aspectos que en mi opinión son más terriblemente equivocados en la ingeniería del software tradicional es la orientación hacia la calidad del proceso. Hasta la llegada de las metodologías ágiles, todas las metodologías, filosofías, técnicas y certificaciones se centraban, en mayor o menor medida, en la documentación. Todavía hoy veo cómo muchas empresas se dedican a imponer restricciones que conducen a entregar cientos (literalmente) de folios para especificar un trabajo que no lo requieren. Veo proyectos que se documentan durante más de un año para una construcción que un equipo pequeño es capaz de hacer en tres o cuatro meses. ¿Qué sentido tiene eso?

Esto es lo que se dice en el punto 1.2 del manifiesto ágil: "Valorar más el software que funciona que la documentación exhaustiva", y creo que es la tendencia adecuada. El software lo hacen las personas, no las máquinas, así que aplicar métodos industriales no es correcto. Por ejemplo, los muestreos aleatorios en las líneas de producción pueden detectar bastante bien problemas en la producción, pero no en el código: es frecuente encontrar errores aislados con consecuencias catastróficas; no todas las partes del código tienen el mismo peso; no todo el código es producido por la misma persona...

La técnica que aplicamos en CexC para mejorar la calidad del producto es la Integración Contínua. Obviaré la descripción y ventajas habituales, centrándome en nuestra experiencia con Hudson, nuestro motor de integración contínua, y otras herramientas relacionadas.

Valor añadido adicional: aprendizaje

El CexC está en un entorno universitario, formando parte de la UVa, y el aprendizaje es fundamental. Este aspecto, habitualmente obviado al hablar de herramientas de calidad, para nosotros es fundamental. Mediante herramientas de análisis estático de código como FindBugs o PMD, integradas en el entorno de desarrollo, el programador va dándose cuenta cada vez de más formas de mejorar el código. Aprende, por ejemplo, que debe declarar las referencias como final si no las va a modificar. Revisar los informes agregados en Hudson permite ver qué partes del código se deben revisar, qué está mejor, cómo estamos evolucionando...

El coste son los tests

Es innegable que el uso de una herramienta adicional tiene que dar algo más de trabajo. En el caso de la integración contínua el añadido es mínimo, ya que no deja de ser una agregación y automatización. A poco de soltura que tengas con Ant (lo siento, no me gusta Maven), en un par de días, tras ajustar el script de compilación y un poco los de configuración de algunas herramientas, tienes Hudson funcionando a pleno rendimiento, y crear nuevos proyectos a partir de otros existentes es cosa de, literalmente, un minuto.

Las herramientas de calidad de código imponen buenas costumbres, buenas prácticas, así que una vez se convierten en hábito no suponen un problema. Las gráficas de Checkstyle, CPD, FindBugs y PMD crecerán de un modo moderado a lo largo de la vida del proyecto, y ya está. En el gráfico anterior podemos ver cómo sí hubo que realizar un serio correctivo respecto a PMD, lo cual sí implicó un esfuerzo extra, pero no es una consecuencia de la herramienta, sino de una relajación en la calidad del trabajo (y esta es una de las ventajas de tener una web que integre todo: la visibilidad).

Sin embargo, en metodologías ágiles sí que cobra una mayor importancia algo que sí es costoso: las pruebas. Programar pruebas, mal que me pese, no es trivial. Incluso pruebas esencialmente elementales, para probar el correcto funcionamiento de páginas de CRUDs son costosas. No por el código en sí, sino por el estado de la base de datos.

Verificar que un algoritmo para un conjunto de entradas da los resultados correctos es muy potente y fácil. Sin embargo, probar consultas, por ejemplo no. ¿Cómo pruebas que una consulta a base de datos da los resultados esperados y sólo esos? Es muy difícil hacer -en un tiempo razonable- una prueba unitaria de esto.

Al final en general lo que acaba ocurriendo es que no se hacen demasiadas pruebas, pero, si hablamos de aplicaciones de gestión, tampoco es tan grave. Realmente no aporta demasiado esforzarse en hacer pruebas que anden insertando y borrando en base de datos, ya que eso no es nuestro código, es sólo la infraestructura.

¿Cuándo hacemos pruebas, entonces?

1. Cuando se nos reporta un fallo: desarrollamos el código que reproduce el fallo. De esta forma mejoramos el flujo de trabajo: prueba que reproduce el fallo (¡automatizadamente!) - corregir - lanzar prueba - no funciona, corregir - lanzar prueba - correcto - cerrar incidencia documentando la prueba desarrollada.
2. Cuando el código de gestión no es trivial: al realizar cálculos complejos, al aplicar algoritmos importantes para el negocio...
3. Verificaciones de seguridad: no son costosas de realizar, y el valor añadido que proporcionan es importante.

Cualquiera que haya trabajado desarrollando aplicaciones es consciente de que la Ingeniería del Software tiene un gran componente de artesanía y, como tal, las herramientas son fundamentales.

En el Centro Experimental del Conocimiento hemos diseñado el entorno de desarrollo teniendo esto en mente. Al escoger las herramientas y la forma de trabajar con ellas nos planteamos los siguientes objetivos:

• Estandarizar las herramientas lo máximo posible...
• ... pero siendo pragmáticos: la mejor herramienta para cada caso.
• Escoger un conjunto de herramientas lo más integrado posible.
• Maximizar la cobertura del trabajo a realizar: buscamos el conjunto mínimo de herramientas que cubría la mayor parte del trabajo a realizar, desde la planificación de los proyectos hasta la integración.
• Soporte para las técnicas ágiles de desarrollo de software en las que se basa nuestra metodología.
• Minimizar el trabajo de gestión a los desarrolladores, permitiéndoles centrarse en su trabajo.

Los dos primeros objetivos surgen temprano en las primeras reuniones. Tenemos muchas líneas de trabajo diferentes, con dispares tecnologías (J2EE para aplicaciones de gestión, .NET para Sistemas de Información Geográfica, PHP para publicación de contenido web, SOA...). ¿Debíamos estandarizar totalmente las herramientas? Claramente se determinó que no. El choque entre Java y .NET fue el determinante. Tanto uno como otro tienen entornos de desarrollo contrastados, estables, muy productivos. No tiene sentido imponerse una limitación tal como tener que usar herramientas de Microsoft para Java, o viceversa.

Esto conlleva un efecto colateral: las herramientas que se integran bien con Eclipse no tienen porqué integrarse con Visual Studio. Por tanto, renunciamos a estandarizar no sólo el entorno de desarrollo sino también otras cosas, como la gestión de proyectos. ¿Supone esto un problema? Para nada.

Determinado esto, mi trabajo fue seleccionar las herramientas para el desarrollo con J2EE, de las que paso a contar la experiencia hasta la fecha.

Eclipse

 Es un entorno de trabajo contrastado, potente y flexible gracias a los plugins. Lo usamos satisfactoriamente gracias a esto incluso para proyectos sobre PHP.

JBoss Tools

 Es un conjunto de plugins para facilitar el trabajo con las tecnologías de JBoss, compañía de la que somos partners. Facilita trabajar con Seam (en nuestra opinión, el mejor framework J2EE en el momento), con el servidor de aplicaciones, con el Enterprise Server Bus... Implementa la creación de CRUDs de entidades tanto de forma directa, generando desde cero la entidad y las páginas de alta, edición y consulta, como inversa, tomando una tabla existente y generando con ella el código Java de entidades y control y las páginas JSF. Una de las grandes ventajas de usar Seam es este conjunto de plugins. En SpringSource se han dado cuenta de ello y hace unos meses publicaron también su propia versión de Eclipse y servidores de aplicaciones, pero en mi opinión JBoss está ya mejor posicionado para ello.

No hemos tenido un solo problema serio con JBoss Tools, y el valor que nos proporciona no tiene precio.

Trac

 Utilizamos Scrum como metodología de desarrollo, y Trac con unos cuantos plugins (Timing and Estimation, notablemente) nos permite gestionar el sprint backlog. Lo que es más, mediante Mylyn, el sistema de trabajo orientado a tareas que tiene Eclipse integrado, se conecta con Trac, permitiendo que un desarrollador gestione su trabajo (asignaciones, tiempos, requisitos...) directamente desde el IDE, sin tener que recurrir ni siquiera a un navegador web. Además, le proporciona valor añadido con la gestión de contextos.

Si bien todavía no es una solución tan estable y completa como alguna otra alternativa como Jira, su sistema de extensión mediante plugins y su integración con Mylyn le hace ser una alternativa perfectamente viable (y más barata).

Hudson

 Es nuestro sistema de integración contínua. Preferimos centrarnos en la calidad del producto sobre la del proceso, así que ejecutar tareas automatizadas de compilación, análisis estático de código, pruebas, etc., nos es muy importante. Si bien exige algo de trabajo inicialmente (especialmente para configurar un buen script Ant), lo que aporta una vez lo has echado a andar es muy interesante. Además, hay plugins para integrar Eclipse con él, y él con el Subversion y el Trac.

 A grandes rasgos, éste es nuestro poquer para el desarrollo. Realmente conseguimos que el desarrollador se pueda centrar en el código, minimizando la carga adicional de comunicación (asignación y finalización de tareas o bugs, por ejemplo), y maximizando la productividad y la calidad, todo ello sin renunciar a la información necesaria para monitorizar el proyecto tanto por dentro (calidad de código) como por fuera (estimaciones, planificación...).

En el entorno económico actual, el tejido empresarial y la Administración Pública necesitan gestionar sus documentos invirtiendo los menores recursos económicos posibles y adaptándose a las nuevas normativas. Algunos ejemplos son la Ley 56/2007, que promueve la facturación electrónica y exige que los documentos permanezcan almacenados de forma segura durante cierto periodo de tiempo, y la Ley 11/2007, que permite que los ciudadanos accedan a los Servicios Públicos de forma electrónica. Esto nos incitó investigar en este campo, buscando un sistema de almacenamiento acorde a las necesidades expuestas.
Tras analizar los sistemas actuales en el mercado, hemos creado una extensión para el gestor de contenidos Alfresco, CMS de código abierto, que permitirá almacenar los contenidos en las cabinas EMC Centera con bajo coste. Este tipo de almacenamiento es orientado a contenidos y utiliza direccionamiento único aplicando funciones Hash sobre los datos almacenados (CAS, Content Addressed Storage) de forma transparente al usuario, sin preocuparse por la ruta de almacenamiento (en NFS, etc).
Alfresco permite reducir el coste en la gestión de contenidos, ya que se basa en proyectos de código abierto, a la vez que ofrece una solución empresarial robusta y escalable. Su arquitectura está basada en J2EE: Hibernate, Spring, JBoss/Tomcat, Apache Lucene, MyFaces. Cabe destacar que es una solución multiplataforma, con suficientes extensiones como para integrarlo con otras tecnologías (OpenOffice, @firma...) y protocolos de interconexión y sistemas de ficheros(ftp, cifs, nfs...).