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.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Sin duda el código duplicado es el mal, pero la métrica de complejidad ciclomática puede dejar escapar métodos demasiado largos que, sin embargo, no tengan una algoritmia compleja y que también impactan en la calidad.
En cualquier caso, si solo se pueden elegir dos únicas métricas, creo que tu elección es estupenda. Gracias.
Gracias por el aporte Javier.
Continuando con lo que comentas, lo que también suele suceder es que aquellos métodos que tienen mayor complejidad ciclomática suelen tener muchas líneas de código. Aunque no sea una implicación necesaria.
Saludos!
He leido distintos comentarios respecto a la idea propuesta de calidad de software algunos plantean que realizar codigo con calidad implica construir clases con metodos que no tengan mas de 20 lineas pero mi pregunta es ¿Y donde queda la complejidad cliclomatica que realmente es una metrica de software fiable?. Saludos.
Bastante fiable
Saludos!
Yo añadiría densidad de comentarios… no basta asegurar sólo la calidad actual del software, también es bueno asegurar la calidad futura…
Esa métrica no distingue un comentario que supuestamente aporta valor (calidad) de uno totalmente irrelevante.
Las dos métricas descritas en el artículo son, sin embargo, totalmente objetivas.
La métrica de McCabe por si sola no es un indicador de complejidad necesitas tener más datos, es decir más medidas ya que esa métrica sola no te da suficiente información, hay estudios que demuestran que el algoritmo de la burbuja es complejo según esta métrica, además que no tiene en cuenta si un if tiene más de una condición como ya se expuso en los años 70.
burnos dias me brindaria un ejempko de metrica orientada caso de uso
Son dos métricas que me parecen muy indicativas y además bastante fáciles de identificar y con herramientas que permiten hacerlo de forma fácil.
Aunque un poco antiguos os dejo dos artículos que escribí hace tiempo sobre estas dos métricas.
https://jbravomontero.wordpress.com/2012/12/28/reduciendo-el-tamano-del-codigo-de-un-proyecto-java/
https://jbravomontero.wordpress.com/2012/07/30/explicando-la-complejidad-ciclomatica-mediante-graficos/
Un saludo.