imagen sobre la primera base construyendo una torre de cartas
Auditoría de código,  Control de calidad

Complejidad ciclomática y calidad del código

La complejidad ciclomática es sin duda el indicador menos conocido y más práctico para medir de forma estimada la calidad de nuestro código. Lleva poco tiempo encontrar alguna herramienta que te lo calcule para tu plataforma/lenguaje de programación y la información que te da es muy interesante.

Yo lo uso siempre en mis auditorías de código ya que este sencillo calculo es también muy interesante buscando posibles vulnerabilidades desde el punto de vista de seguridad. Los puntos calientes de falta de calidad del código traen consigo problemas de seguridad, desde el punto de vista técnico e incluso en el aspecto funcional, permitiendo un uso de la aplicación no concebido inicialmente.

Descripción breve de complejidad ciclomática

La complejidad ciclomática básicamente es una puntuación de cada uno de los métodos/funciones y clases del código que nos indica cuánta complejidad condicional lógica tiene este. Resulta de la suma de sus estructuras condicionales de control y sus posibles salidas.

En el siguiente ejemplo lo más sencillo posible, este calculo de calidad del código resulta en dos. Se divide en número de condiciones 1 + número de posibles salidas 1 = v(G) 2.

La Complejidad Ciclomática (en inglés, Cyclomatic Complexity) es una métrica del software en ingeniería del software que proporciona una medición cuantitativa de la complejidad lógica de un programa.

Wikipedia

Con esta «nota» podemos tener rápidamente visibilidad sobre los puntos más críticos y complejos del código. Donde peor nota saquemos será habitual encontrar problemas de seguridad y/o calidad.

Niveles de puntuación en complejidad ciclomática y calidad del código

La puntuación también indica cómo de legible y modificable es el código de nuestro proyecto, y por lo tanto cuanto esfuerzo costará entenderlo y mantenerlo en el futuro, la organización que tiene este, etc…

La guía de revisión de código del proyecto OWASP considerada como referente, ofrece la siguientes categorías de complejidad:

PuntuaciónCategoría del código
De 0 a 10Código estable, complejidad aceptable
De 11 a 15Riesgo medio, más complejidad
De 16 a 20Código de alto riesgo, demasiadas decisiones para una unidad de código
Por encima de 50Código no testeable

Es muy importante decir que estas medidas son a nivel de unidad aislada de código, en un lenguaje orientado a objetos deben ser tenidas en cuenta a nivel de método/función, no a nivel de clase. Una clase puede tener más o menos métodos según su necesidad, y su complejidad puede variar de forma completamente aceptable. A nivel de clase también es bueno revisar la complejidad pero en este caso las medidas serían otras.

He de decir que las categorías de OWASP me parecen conservadoras, ya que un método de 16 a 20 yo no lo llamaría de alto riesgo… Parece ser que históricamente establecer categorías concretas ha causado controversia y hay categorías diferentes según el autor, aunque de forma genérica podríamos quedarnos con la idea de que cuanto menos pasemos de 15 mejor.

Herramientas, mide este aspecto

A continuación podemos ver varias herramientas que nos calcularán puntuaciones de complejidad ciclomática y otras métricas:

Código «no testeable»

Como último aspecto de lo que nos ofrece el calculo de complejidad ciclomática, es interesante como un código puede llegar a considerarse como «no testeable», ya que sobrepasado un punto de complejidad (para OWASP por encima de 50), esa unidad de código toma tantas decisiones lógicas que no puede llegar a considerarse un código conocido ni controlado.

Un código con esta categoría, por lo tanto no puede considerarse probado ni auditado. Es decir no puede considerarse válido, ni desde el punto de vista de garantía de seguridad, ni desde el punto de vista de control de calidad. Esto se debe a la gran y variada casuística de sus posibles comportamientos, el cual no es abarcable en unas pruebas o auditoría habitual.

También es interesante cómo pueden establecerse indicadores de mantenibilidad del código, como el que establece el proyecto OWASP es su guía de revisión de código y llama «Bad Fix Probability». Este nos indica, según la complejidad del código, las probabilidades de introducir un error nuevo en nuestro software durante el proceso de corrección de un error existente.

Conclusiones sobre esta medición

No tienes excusa como arquitecto, jefe de proyecto o responsable de calidad para no saber en qué punto del código la complejidad ciclomática y calidad del código se está convirtiendo en un problema, cuestión que es bastante habitual. Mi consejo es que lo vigiles de forma constante, como hemos visto no consume mucho tiempo y es un indicador que está vivo, siempre que se crea código nuevo o se modifica esta puntuación va cambiando y es fácil mantenerla a raya.

Cuando desarrollas no tienes por que tener una complejidad ciclomática bajísima desde el minuto uno, es sano escribir código primero en sucio como boceto, para después reescribir, refactorizar… Sin embargo si tienes que tener en cuenta la complejidad sobre todo a la hora de dar por válido tu código.

Referencias y recursos para profundizar en el tema:

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

error

Enjoy this blog? Please spread the word :)

error: