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.