« You can’t control what you can’t measure » (Tom de Marco)

Explicaba en el post anterior Los 3 costes que las herramientas de análisis de código nos entregaban un gran número de informaciones cualitativas mientras que las métricas cuantitativas eran menos numerosas, pero muy útiles. Esta opinión no es siempre compartida.

Las métricas cuantitativas o ‘raw metrics’ en inglés (que se podría traducir por ‘datos brutos’) son unas medidas bastante fáciles a conseguir con la gran mayoría de las herramientas de análisis de código. Generalmente, este tipo de software presenta primero una nota global de calidad que agrega diferentes reglas de conformidad a buenas prácticas de programación, de diseño, de documentación, etc.
Esta nota global da una visión general de la calidad de la aplicación, pero se revela de hecho bastante subjetiva: depende mucho de la herramienta.

Las buenas prácticas son bastante bien estandardizadas y deberíamos encontrar los mismos conjuntos de reglas en cada herramienta. De hecho, es poco el caso. Unos softwares son especializados sobre un lenguaje único para el cual proponen el máximo de reglas posibles. Otros son multitecnologías y apuntan a equilibrar o a menudo a normalizar las reglas entre los diferentes lenguajes, y no á soportar el más posible de estandares.

Un factor más subjetivo todavía es la criticidad affectada a una regla, su peso en el modelo de calidad. Realizando un estudio comparativo entre dos softwares de análisis de código, descubrí que, en una escala de 1 a 10:

• La primera herramienta disponía de 15 diagnósticos con un peso de 6 á 10, en un total de 73 reglas, es decir el 20 % de éstas.
• La segunda herramienta disponía de 58 diagnósticos de un total de 102, con un peso superior á 6, es decir más de la mitad del número total de réglas.

A veces, bajar o subir la criticidad de una regla basta para modificar drásticamente la nota global de calidad. Más grave todavía, una herramienta se puede equivocar en la medida de una regla, o sea porque produce un gran número de falso-positivos, o sea simplemente de la culpa de un defecto (bug).

Me acuerdo así de un software de análisis de código que no encontraba todos los enlaces hacia la página de error de la aplicación y concluía que había un defecto grave para la seguridad. Imaginate la estupefacción cuando el equipo de proyecto y sus gerentes – y a menudo un CIO – descubren que su aplicación super-critica presente un riesgo superior para la seguridad. Gran momento de soledad para el consultor Calidad que presenta esta conclusión sin haber verificado previamente la exactitud de esta medida cualitativa.

Es paradójico que la calidad de tu aplicación depende de la calidad del software que evalua la calidad de tu aplicación.

Si dos herramientas distintas no alcanzan a la misma medida cuando a los datos cualitativos, las medidas cuantitativas son más a menudos semejantes y exactas.

Oigo muy a menudo decir: « esta aplicación es compleja » pero si pregunto por qué es compleja, las respuestas no son precisas. Me basta con examinar el número de líneas de código y ya tendré una indicación. ¿La talla de esta aplicación es o por encima de la media para esta tecnología? Luego, la Complejidad Ciclomática me entrega una segunda información: ¿esta aplicación incorpora un gran número de reglas? ¿Su nivel de complejidad la hace fácilmente mantenable?

¿Si sabes que una persona pese 60 kg, esto basta para decir si es delgada? Claro que no. Pero si conoces su talla, entonces puedes decir si está o no en exceso ponderal.
Otras medidas complementarias tales como el porcentage de comentarios o de código duplicado permiten reconstituir el perfil de la aplicación. Por supuesto, los datos cuantitativos son limitados. Algunos me dirán que es una herejía de utilizar el número de líneas de código (LOC), otros van sólo a por los puntos de función. Todas estas opiniones presentan interés, pero los ‘raw metrics’ presentan ciertas ventajas innegables:

• Están fácilmente disponibles.
• Son generalmente exactas.
• Son fácilmente comprensibles para los directivos.

Constituyen pues una base sólida para evaluar la calidad de una aplicación y si ella es costosa a mantener. El examen de las métricas cualitativas permite luego precisar nuestra evaluación y el ‘por qué’ de este coste: porque es poco legible, porque presenta defectos para su fiabilidad, porque las buenas prácticas en materia de realización o en materia de optimización no son aplicadas, etc.

Las métricas cualitativas permiten afinar un diagnóstico, construir un plan de remédiaciones, poner en ejecución un proceso de mejoramiento continuo de la calidad. Son preciosas para los equipos de proyecto.
Cuando se trata de responder a la cuestión legítima de los ejecutivos y de los usuarios: ¿cuánto me cuesta esta aplicación? los datos cuantitativos son más simples, más precisos y más fáciles de utilizar.

Empezamos por medir lo que podemos controlar.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.