Métricas de SonarQube (parte I)

Las métricas de SonarQube te facilitan la información objetiva de la calidad actual de tu proyecto.

Soy muy fan de los datos y de la información objetiva, y seguramente por ello, un firme defensor de esta frase de Edwards Deming, un estadístico estadounidense, profesor universitario, autor de textos, consultor y difusor del concepto de calidad total:

Sin datos, no es usted más que otra persona con una opinión.

Por eso, es fundamental para medir la calidad de software, contar con datos objetivos, además de actualizados y en tiempo real

Pero, empecemos por lo básico.

¿Qué es una métrica?

En desarrollo de software en general, y en calidad en particular, una métrica es cada uno de los conceptos que expresa con datos numéricos el resultado de una medición.

Gracias a la objetividad de datos numéricos, los resultados se mostrarán de la misma forma para todos, y, aunque esos datos se pueden interpretar (es mucho, es poco, etc…) tiene una serie de ventajas.

Metricas SonarQube

La primera fundamental, está relacionada con los objetivos, ya que una característica fundamental de ellos es que sea medible.

Así, gracias a las métricas, la primera ventaja, y para mí la más importante, sería saber si la calidad del proyecto está mejorando, y debemos continuar con esa tendencia, o si, por el contrario, está empeorando, y, por lo tanto, debemos tomar acciones para revertir la situación.

Métricas de SonarQube

SonarQube divide las métricas en las siguientes categorías:

  • Evidencias
  • Duplicados
  • Complejidad
  • Tamaño
  • Pruebas
  • Fiabilidad
  • Seguridad
  • Mantenibilidad

En este artículo, veremos las tres primeras.

Evidencias / Issues

Las evidencias son los fragmentos de código de un proyecto que SonarQube detecta que incumplen con algunas de las reglas establecidas para cada lenguaje en su respectivo perfil de calidad. En esta categoría puedes encontrar:

Nuevas evidencias (new_violations)

Número de evidencias detectadas desde el principio del periodo de “Nuevo código”, que es un parámetro que se debe configurar en SonarQube.

Nuevas evidencias [severidad] (new_[severity]_violations)

Indica el número de evidencias sobre la severidad especificada, detectadas desde el inicio del periodo de “Nuevo código” que puede ser: bloqueante, crítica, mayor, menor o info (bloquer, critical, major, minor o info respectivamente)

Evidencias (violations)

Es la valor total de todas las evidencias posibles.

Evidencias [severidad] ([severity]_violations)

Muestra el valor total de evidencias por cada severidad: bloqueante, crítica, mayor, menor o info (bloquer, critical, major, minor o info respectivamente)

Falsos positivos (false_positive_issues)

En este caso se trata del total de evidencias que se han marcado como falso positivo

Evidencias abiertas (open_issues)

Indica el número de evidencias que se encuentran con el estado “Abierto”, es el estado inicial de una evidencia.

Evidencias confirmadas (confirmed_issues)

Refleja el número de evidencias que han sido marcadas como “Confirmadas”, estado creado para indicar que esa evidencia se va a resolver

Evidencias reabiertas (reopened_issues)

Total de evidencias en estado “Reabierta”, que son aquellas que se han vuelto a abrir tras haber sido cerradas por algún motivo.

Duplicados

La programación permite evitar duplicados gracias a constantes y métodos, lo que ayuda en gran medida a evitar resultados distintos en operaciones iguales, que producirían errores. Por eso es importante mantener un código limpio y evitar los duplicados.

Sobre fragmentos duplicados puedes encontrar las siguientes métricas de SonarQube

Bloques duplicados (duplicated blocks)

Número de bloques de líneas de código que se duplican.

Para que un bloque de código se considere duplicado:

  • Proyecto Java
    • Hay al menos 10 sentencias sucesivas y duplicadas con cualquier numero de tokens y líneas. Se ignoran las diferencias en indentación y literales de strings.
  • Proyecto No Java
    • Hay al menos 100 tokens sucesivos y duplicados
    • Dichos tokens deben encontrarse en al menos:
      • 30 líneas de código para COBOL
      • 20 líneas de código para ABAP
      • 10 líneas de código para el resto de lenguajes

Archivos duplicados (duplicated_files)

Número de archivos involucrados en la duplicación

Líneas duplicadas (duplicated_lines)

Número de líneas involcradas en la duplicación

Porcentaje de líneas duplicadas (%) (duplicated_lines_density)

Se obtiene de dividir el número de líneas duplicadas entre el total de líneas y multiplicarlo por 100.

Complejidad

La complejidad de un proyecto de software dificulta su mantenimiento y escalabilidad, por eso es tan importante que tu código sea lo más sencillo posible.

Complejidad (complexity)

Es la complejidad ciclomática, calculada en el número posible de rutas que puede seguir el código.

Cuando el flujo de control de una función crea dos posibles caminos, el contador de la complejidad se incrementa en uno.

Cada función tiene un mínimo de complejidad de 1. Éste calculo puede variar ligeramente entre lenguajes debido a sus funcionalidades.

Complejidad cognitiva (cognitive_complexity)

Como de difícil es el ciclo que sigue el código. Puedes consultar el White paper de Sonarsource sobre la complejidad cognitiva del modelo matemático que se aplica para calcular esta métrica aquí


Y hasta aquí esta primera parte, con las métricas de SonarQube más generales, pero que te puede ayudar a hacer una idea sobre el estado de calidad de tu proyecto.

En la siguiente parte, te mostraré las métricas relacionadas con las pruebas (concretamente pruebas unitarias) y el tamaño de tu proyecto

Deja un comentario