En este tutorial vamos a realizar un análisis de la calidad de un proyecto ejemplo de acuerdo con la información de los índices de calidad que nos ofrece SonarCloud.

En este tutorial aprenderemos a:

1. Analizar los índices de calidad de un producto de acuerdo con los resultados de SonarCLoud
2. Identificar las partes (módulos, archivos) más críticas de la aplicación, con respecto a la calidad del código.
3. Explicar la calidad del producto que está siendo analizado

Para acceder al sitio oficial de SonarCloud.

Este tutorial ha sido desarrollado en la Universidad de los Andes, Colombia

Conceptos básicos

Todos los issues detectados por Sonar al realizar el análisis estático de código tienen un esfuerzo o costo de remediación asociado. Este costo se expresa en minutos.

La suma de todos los costos de remediación de los issues tipo code smell conforman la deuda técnica. Recordemos que los issues tipo code smell son las no conformidades relacionadas con el atributo Mantenbilidad.

El esfuerzo necesario para corregir los issues de tipo bugs, es decir del atributo Confiabilidad, se llama "Esfuerzo de remediación de la confiabilidad" (Reliability remediation effort).

El esfuerzo necesario para corregir los issues de tipo vulnerabilidad, es decir del atributo Seguridad, se llama "Esfuerzo de remediación de la Seguridad" (Security remediation effort).

Tabla 1: Vocabulario básico

El proyecto que vamos a analizar en este ejemplo se encuentra en el TutorialCanciones.

Para guíar el análisis vamos a completar la información de la siguiente tabla que resume los principales hallazgos.

Tabla 2: Resumen principales hallazgos

El índice de mantenibilidad se calcula a partir de la deuda técnica y del número de líneas de código totales del proyecto. La deuda técnica se calcula a partir de los issues de tipo code smells.

Líneas de código

La siguiente figura presenta el reporte del tamaño del proyecto.

Figura 1: Tamaño del proyecto

Costo de desarrollo

El costo de desarrollo del proyecto se calcula multiplicando el número de líneas de código (lógicas) por 0,06 días. Este valor representa, en SonarQube, el esfuerzo para desarrollar una línea y ha sido definido por una comunidad de desarrolladores experimentados. Para el caso del ejemplo, el costo de desarrollo equivale a 428,16 horas, como se ve en el cálculo a continuación:

Costo de desarrollo = 892 * 0,06 días = 53,52 x 8 horas = 428,16 horas

Deuda técnica

La deuda técnica suma los esfuerzos de todos los code smells del proyecto. La siguiente figura muestra el reporte de la deuda técnica, para el caso del ejemplo:

Figura 2: Deuda técnica

Para el ejemplo, la deuda técnica corresponde a 3,72 horas, como se ve en el siguiente cálculo:

Deuda técnica = 3h 43 min = 3,72 horas

Razón de la deuda técnica

La razón o proporción de la deuda técnica con respecto al costo del proyecto se calcula dividiendo la deuda técnica por el costo de desarrollar las líneas de todo el proyecto. Para el caso del ejemplo, equivale a 0,8% como se ve el siguiente cálculo:

Technical debt ratio = 3,72/428,16 = 0,008 = 0,8%

Con estas informaciones podemos completar la tabla de resumen de los principales hallazgos:

Tabla 3: Resumen principales hallazgos el cálculo de los índices

Entonces, para el ejemplo, el índice de mantenibilidad es A porque el Debt Ratio es menor de 5% 

Análisis de los code smells

En el proyecto ejemplo hay 45 code smells distribuidos por severidad como lo muestra la figura 3, 10 críticos, 2 mayores y 33 menores.

Figura 3: Severidad de los code smells

Severidad crítica

Los code smells de severidad crítica corresponden a violaciones de reglas de manejo de excepciones y de definición de constantes. Hay 10 code smells críticos en el ejemplo que violan las siguientes reglas:

"SystemExit" should be re-raised
Code Smell Critical Bad-practice error-handling suspicious SonarQube (Python) Constant/issue: 5min

String literals should not be duplicated
Code Smell Critical design SonarQube (Python) Linear with offset: 2min +2min per duplicate instance

Severidad mayor

Los code smells de severidad mayor corresponden a violaciones de reglas de código duplicado y a código comentado. Hay 2 issues que corresponden a violaciones de las siguientes reglas:

Functions and methods should not have identical implementations
Code Smell Major  confusing duplicate suspicious  SonarQube (Python)  Constant/issue: 15min

Sections of code should not be commented out
Code Smell Major unused  SonarQube (Python) Constant/issue: 5min

Severidad menor

Los code smells de severidad menor corresponden a violaciones de reglas de convención de nombramiento. En el proyecto ejemplo, se utiliza camelcase y en el perfil la regla pide que la separación de palabras se haga con _ (barra al piso).

En el proyecto hay 33 code smells relacionados con las siguientes reglas:

Method names should comply with a naming convention 
Code Smell Minor convention SonarQube (Python) Constant/issue: 5min 

Field names should comply with a naming convention 
Code Smell Minor convention SonarQube (Python) Constant/issue: 2min 
Sharing some naming conventions is a key point to make it possible for a team to efficiently collaborate. This rule allows to check that field names match a provided regular expression. 
Noncompliant Code Example 
With the default regular expression ^[_a-z][_a-z0-9]*$: 
class MyClass: 
 myField = 1 
 
Compliant Solution 
class MyClass: 
 my_field = 1 

Localización de los code smells

Al revisar el reporte de Mantenibilidad que muestra la deuda técnica contra el número de líneas de código de los archivos del proyecto, vemos que el archivo lógica/Colection.py es el que más issues tiene (24) con una deuda técnica 1h 48 min, estos son los issues críticos y menores.

Figura 4: Deuda técnica contra tamaño de los archivos

Tabla 4: Distribución de la deuda técnica en los archivos del programa

Code smells en la lista de CWE top 25

Cualquier desarrollador debería revisar con frecuencia los issues que se presentan en la lista CWE top 25, ya que estos presentan no conformidades de alto impacto, muchos para la seguridad, que se presentan con gran frecuencia en los proyectos de desarrollo. Veamos cómo está el proyecto del ejemplo en este aspecto.

En el ejemplo que estamos analizando no hay ningún issue de ninguna de las tres categorías, que esté en la lista de los CWE top 25

Para saber el código del CWE, hay que ir al final de la regla como se muestra en la siguiente figura.

Figura 5: Lista de los CWE top 25.

En este ejemplo no tenemos bugs:

Figura 6: Información del índice de Confiabilidad.

Entonces, para el proyecto de ejemplo, el índice de confiabilidad es A porque el número de bugs críticos es 0.

Análisis de los bugs

El proyecto no tiene bugs.

Localización de los bugs

El proyecto no tiene bugs.

Bugs en la lista de CWE top 25

El proyecto no tiene bugs.

En este ejemplo no tenemos vulnerabilidades:

Figura 7: Información del índice de Seguridad.

Entonces el índice de seguridad es A porque el número de vulnerabilidades es 0.

Análisis de las vulnerabilidades

El proyecto no tiene vulnerabilidades.

Localización de las vulnerabilidades

El proyecto no tiene vulnerabilidades.

Vulnerabilidades en la lista de CWE top 25

El proyecto no tiene vulnerabilidades

La tabla completa de los datos del proyecto:

Tabla 5: Resumen principales hallazgos con cálculo de índices completos

A partir de la información que se ha recopilado y analizado hasta el momento, en especial el cálculo de los diferentes índices es posible concretar un diagnóstico de un proyecto en curso. Este tipo de diagnósticos se usan para, que el equipo de desarrollo mejore sus procesos. De la misma forma, se utiliza para evitar salir a producción con producto que no satisface condiciones de seguridad o confiabilidad mínimas.

De acuerdo con los índices de mantenibilidad, confiabilidad y seguridad, el proyecto tiene buena calidad ya que en todos los casos el valor es A. Significa que la deuda técnica es menor al 5% del costo de desarrollo de las 892 LOCS. En el proyecto no hay bugs ni vulnerabilidades lo que implica que el índice de confiabilidad y de seguridad son A.

Con respecto a la deuda técnica, esta proviene de dos code smells críticos, 10 code smells mayores y 24 code smells menores.

Los 24 code smells menores están todos ubicados en el archivo Colection.py y corresponden a no conformidades con las convenciones de nombramiento de acuerdo con el perfil de calidad por defecto de SonarQube. En el proyecto se utiliza camelcase y en el perfil la regla pide que la separación de palabras se haga con _ (barra al piso).

Con respecto a qué debemos corregir primero, consideramos que los issues críticos están relacionados con un inapropiado manejo de excepciones. Los code smells menores relacionados con las convenciones pueden esperar. Incluso, si la política de la organización es usar camelcase, se puede considerar cambiar la regla del perfil de calidad para que analice los nombres para que sean conformes con camel case.

Hay distintas formas de calcular los índices de calidad, una manera es el modelo Sqale. La compañía bitergarten desarrolló un plugin para SonarQube que reporta el análisis de calidad basado en Sqale. El plugin reporta el análisis como se muestra en la siguiente figura:

Figura tomada de: bitergarten

Para saber más sobre la lista de los CWE top 25 puedes visitar el siguiente enlace.

La compañía bitergarten tiene un plugin para SonarQube que reporta los issues encontrados en el proyecto que están en la lista de los CWE top 25, el plugin saca un reporte como el de la siguiente figura:

Figura tomada de bitergarten

© - Derechos Reservados: La presente obra, y en general todos sus contenidos, se encuentran protegidos por las normas internacionales y nacionales vigentes sobre propiedad Intelectual, por lo tanto su utilización parcial o total, reproducción, comunicación pública, transformación, distribución, alquiler, préstamo público e importación, total o parcial, en todo o en parte, en formato impreso o digital y en cualquier formato conocido o por conocer, se encuentran prohibidos, y solo serán lícitos en la medida en que se cuente con la autorización previa y expresa por escrito de la Universidad de los Andes.

De igual manera, la utilización de la imagen de las personas, docentes o estudiantes, sin su previa autorización está expresamente prohibida. En caso de incumplirse con lo mencionado, se procederá de conformidad con los reglamentos y políticas de la universidad, sin perjuicio de las demás acciones legales aplicables.