Sólo necesitas dos métricas para hacerte una idea de la calidad del producto software

Si me dijeran que tengo que ir a una isla desierta y que solo me puedo llevar dos métricas de calidad software, sin duda, me llevaría el “porcentaje de código duplicado” y “la complejidad ciclomática”.

Sólo con esas dos métricas sería capaz de, en pocos minutos, hacerme una idea de la calidad de cualquier software que se me ponga por delante, por muchas líneas de código que tenga.

Esas dos métricas se obtienen de los fuentes de la aplicación, no de documentos o diseños en papel, y por ello reflejan fielmente la realidad.

Esas dos métricas se pueden calcular para cualquier lenguaje de programación (Java, C#, Php, PL, etc.) y para cualquier paradigma (OO, estructurado, etc.).

Esas dos métricas son automatizables, muchas herramientas las calculan, y son económicas, muchas herramientas de software libre las calculan (te dejo este enlace a la lista de herramientas recomendadas).

Esas dos métricas se obtienen del código… pero me dicen cómo está el diseño.
Hagámosles un pequeño y merecido resumen…

Porcentaje de código repetido en el software

Hay quien dice que este es el peor enemigo de la mantenibilidad (es decir que provoca gastar muchos euros de más, innecesarios, para hacer cambios) software (así lo comenta Fowler en su libro de Refactoring).

En mi vida profesional he visto autenticas barbaridades en este punto, aplicaciones software tremendamente obesas con disparatados porcentajes de código “copy pegado” repartido por decenas de fuentes. Lo que había disparado en muchos miles de euros los costes de mantenimiento.

Un alto porcentaje de código repetido:

• Aumenta innecesariamente el número de líneas de código (a más líneas de código más complejo es el mantenimiento, y más costoso).
• Dispara los costes (si hay que cambiar ese código repetido… hay que cambiarlo en muchos sitios).
• Aumenta los riesgos (hay que buscar todas las repeticiones y si se nos olvida cambiarlo en algún sitio… el software acaba siendo incoherente).

Y, finalmente, esto se debe a errores de diseño.

Además esta es una métrica muy fácil de calcular, con herramientas, muchas de software libre, que calculan este dato rápidamente.

Sobre esto hablamos hace un tiempo por aquí, te recomiendo leer el post de “duplicar, o copy pegar, código no es una buena idea”.

Complejidad ciclomática

Se basa en calcular el número de rutas linealmente independientes del código (se mide en los algoritmos, por ello es aplicable a orientación a objetos, Php, PLs, etc., cualquier cosa con algoritmo). Te dejo aquí un post sobre esta métrica.

Es mi favorita. La métrica estrella a la hora de rápidamente ver la calidad software de un montón de fuentes. Fácil de automatizar y proporciona mucha mucha información.

Muestra el grado de código “espagueti”, profundos problemas de diseño, problemas de compensibilidad, las pruebas necesarias para lograr una cobertura 100% del código, etc.

Con la complejidad ciclomática no se te van a escapar aquellos mortales algoritmos con muchos “case” o “switch”, con muchas clausulas, o muchos ifs anidados, etc., que no son más que el reflejo de un mal diseño. Te dejo un enlace al post de “un case o switch con muchas clausulas, o muchos ifs anidados, no es una buena idea”.

Terminando…

En el contexto de este post, cuando hablo de calidad software, me estoy refiriendo principalmente a la calidad de la programación y del diseño, aquella que impacta principalmente en los costes de mantenimiento. A la calidad que llamamos “estática” y de “caja blanca”.

Obviamente hay muchos otros parámetros de calidad que aquí no he tocado, como la fiabilidad, funcionalidad, rendimiento, etc. Aquellos “dinámicos” y de “caja negra”.
Como siempre, comparte, tuitea, envía, etc., y me ayudas a difundir el conocimiento.