Development

Mejora de la calidad del código con SonarQube

Desarrolladores, aquí les explicamos cómo pueden mejorar el proceso de revisión de calidad de código con SonarQube.

January 22 2016

Mantener un cierto nivel de calidad y legibilidad de código es de crucial importancia para un desarrollo exitoso en el ambiente de desarrollo dinámico actual, en el que múltiples equipos trabajan en el mismo código, y se realizan cambios con frecuencia. Esos ambientes requieren seguir ciertas convenciones de código para lograr que el código sea entendible para todos los involucrados en el proceso.

Para nosotros, en Infobip, es fundamental que los productos que entregamos cumplan con los más altos estándares de calidad. El núcleo de cada producto es el código fuente. Esto convierte la calidad del código en el factor más importante para determinar la calidad del producto completo.

Para mantener un control de alta calidad, elegimos implementar la revisión de código en nuestro proceso de desarrollo. Sin embargo, luego de cierto tiempo, las revisiones comienzaron a llevar mucho tiempo y desviaban nuestra atención de otras tareas importantes. La revisión de código consiste no sólo en un proceso de revisión creativo sino también en un control de errores repetitivos, del uso de las reglas de convención, etcétera. Se cuestionó el proceso completo, así que una solución lógica era automatizar una parte.

En nuestros centros de desarrollo, intentamos automatizar tantas tareas manuales como sea posible para poder enfocarnos en la innovación, que es lo que nos convierte en la mejor elección para nuestros clientes. En este momento, nuestros desarrolladores pueden implementar servicios automáticamente, escribir API públicas con facilidad y rapidez y generar librerías de clientes en diferentes lenguajes de programación. Nos llevó un largo tiempo encontrar la solución perfecta para ayudarnos con la automatización parcial de la revisión de código. Luego de investigar varias herramientas, nos dimos cuenta de que SonarQube cumple con todos los requisitos.

Características de SonarQube

SonarQube es una plataforma de código abierto para el análisis de la calidad de código. Pertenece al conjunto de herramientas de análisis de código estático, junto con Understand, semmle y otras.

Esta plataforma recibe el código fuente como entrada de datos. Se puede enviar este código desde IDE o se puede realizar un pull desde SCM. Hay plugins de SonarQube para los IDE más populares, que hacen que ejecutar los análisis de código sea más fácil. La plataforma, en base a entrada de datos, comienza a aplicar reglas predefinidas y a controlar si se cumplen. Como salida de datos de análisis, se brinda mucha información útil y propuestas de mejoras.

La razón por la cual elegimos SonarQube son las numerosas y extensas reglas de Java. En este momento, existen más de 700 reglas de Java, y esta cantidad aumenta constantemente. Estamos realizando análisis principalmente en códigos escritos en Java, pero pueden realizarse fácilmente en códigos escritos en cualquiera de los otros 20 lenguajes de programación.

Además, puede escribir sus propios plugins si necesita compatibilidad con un lenguaje específico o si quiere establecer sus propias reglas. Si necesita agregar sus propias reglas de código, es posible si utilizan expresiones XPath o crean un nuevo plugin usando Java.

La plataforma SonarQube consiste en cuatro componentes: analizadores, servidores, plugins instalados en el servidor y, lo que no es menos importante, la base de datos.

Arquitectura de SonarQube

Los analizadores son responsables de ejecutar el análisis de código línea por línea. Pueden brindar información sobre deudas técnicas, cobertura de código, complejidad de código, problemas detectados, etcétera. Los problemas detectados en el código pueden ser bugs, bugs potenciales o elementos que puedan generar errores en el futuro, entre otros. Cuando el análisis está listo, se pueden ver los resultados en la página web albergada en el servidor web de SonarQube. El servidor web simplifica la configuración de SonarQube, la instalación de plugins, y brinda una intuitiva vista general de los resultados.

Enigneering

Vista general de los resultados

Existen muchos problemas que se pueden encontrar en un código. Las reglas difieren y pueden clasificarse en 5 grupos según su severidad: Bloqueador, crítico, grave, menor e informativo. Así que, si hay un bug o un bug potencial, va a ser clasificado como problema bloqueador o crítico, y algunos problemas como "los números mágicos no se deben utilizar" van a ser clasificados con severidad menor o informativa.

Aquí hay un ejemplo de las reglas más infringidas:

Engineering

Reglas más infringidas

Lo mejor de SonarQube es que todos los datos se guardan en una base de datos relacional, con la cual todos los desarrolladores suelen estar familiarizados. La base de datos elegida por nosotros fue una base de datos MySQL. Esto fue así, principalmente, porque somos ávidos defensores de las open source technologies. Si tiene otras preferencias en cuanto a bases de datos, o tiene más experiencia con otra base de datos, estas son algunas de las que son compatibles: PostgreSQL, Oracle, etcétera.

Configuración de SonarQube

La arquitectura de SonarQube permite separar el servidor de la base de datos, e incluso hacer réplicas de la base de datos e implementar servidores en múltiples máquinas para obtener más rendimiento y adaptabilidad.

Con fines de prueba, y para probar varias funcionalidades de SonarQube, pueden probar con un servidor web con una base de datos incrustada y analizar uno o dos proyectos. Si el entorno está configurado correctamente desde el principio, no habrá problemas al migrar la base de datos y el servidor de SonarQube desde una máquina de desarrollo local al servidor. Docker, con sus contenedores, puede ser útil para esto porque usted puede juntar todo lo que necesite (código, tiempo de ejecución, librerías del sistema) e implementarlo fácilmente en cualquier otra máquina. También hay un official SonarQube docker container con una versión H2 incrustada, así que no hace falta perder el tiempo en crear una propia. Las bases de datos externas también pueden configurarse, lo cual es necesario para cualquier trabajo más serio con SonarQube.

Comenzamos con una máquina virtual dedicada y no tuvimos problemas hasta que la cantidad de proyectos se excedió y comenzamos a analizar códigos todos los días. Sin embargo, notamos una caída significativa en el rendimiento y un aumento en la duración del análisis. En ese momento, comenzamos a separar diferentes capas SQ (arquitectura) en distintas máquinas.

Para comenzar, separamos la base de datos y el servidor Sonar. Hemos aceptado las recomendaciones de SonarQube para estar en la misma red.  Para la implementación de SonarQube, estamos usando un contenedor docker, que simplifica la instalación en otra máquina si necesitamos mejores niveles de rendimiento.

SonarQube y la integración continua

Como se mencionó anteriormente, nos ocupamos de la automatización e intentamos emplear menos esfuerzo en cosas que pueden automatizarse para así tener más tiempo para la parte creativa del trabajo. El análisis de código también encaja perfectamente en la historia de la integración continua.

Practicamos y predicamos la integración contínua y el desarrollo ágil, así que así es como luce un proceso de resolución de tareas de nuestro lado:

Comienza cuando un desarrollador (llamémosle “Alisa”) se hace cargo de una tarea y comienza el progreso. Durante la resolución de la tarea, Alisa ejecuta un análisis de código en IDE una y otra vez, obtiene los resultados y puede ver si se cumplen los requerimientos de calidad del código. En lo que respecta a lógica, necesita controlarlo ella misma. Cuando Alisa está segura de que el código escrito cumple todos los requisitos, realiza un commit del nuevo código al repositorio y le pide a Bob que lo revise. Después realizar el commit de los cambios al repositorio de git, el webhook impulsa un build Jenkins. El build se ejecuta automáticamente, y el artefacto con la nueva característica está disponible en el repositorio experto interno y puede implementarse fácilmente en la producción.

Bob revisa el código que escribió Alisa y ejecuta un análisis para determinar si la calidad del código se encuentra en un nivel deseable. Luego de la interpretación de los resultados, Bob solo tiene que realizar la parte creativa de la revisión de código: revisar la lógica. Si todo está bien, la tarea está completa y la nueva característica está lista para la producción.

Engineering

Administración de código fuente con servidor CI y SonarQube

En la versión 4.0 se introduce el modo de análisis progresivo. Este modo se podría usar para controlar si los nuevos cambios van a romper alguna regla de código importante, y el desarrollador que realizó los cambios debería ejecutarlo. Antes de la versión 4.0, el desarrollador comenzaba el análisis del proyecto completo incluso si había cambiado solo dos o tres archivos. Con la nueva característica, el tiempo necesario para el análisis se acorta significativamente. Además del nuevo modo progresivo, también tenemos el análisis de proyecto completo, el análisis línea por línea que envía los resultados al servidor y los almacena en la base de datos, y el modo de vista previa que realiza el análisis completo, pero sin almacenar los resultados en la base de datos.

En este momento, estamos utilizando el modo de análisis de proyecto completo con almacenamiento de resultados para las builds de noche, y el modo de vista previa luego de cada commit.

Eso brinda una manera de realizar un seguimiento del control de calidad del código de commit a commit. Además de esto, tenemos datos históricos sobre la calidad del código, así que podemos analizar cómo varió la calidad durante la duración del proyecto.

Conclusión

Utilizar SonarQube facilita el control de calidad de código y disminuye la cantidad de bugs reales y potenciales. Los desarrolladores ahora están más enfocados en la lógica misma y pueden dedicar su tiempo a los requerimientos de análisis de negocio y a encontrar soluciones óptimas para casos concretos. Además, luego de su implementación, los gerentes comenzaron a realizar un seguimiento de métricas porque, basándose en los resultados, creen que es posible tener una mejor percepción del trabajo de desarrollo.

Como dijo John F. Woods:

Siempre escribe código como si la persona que va a terminar manteniéndolo fuera un psicópata violento que sabe donde vives.

¿Qué está esperando? Hoy es un gran día para analizar código.

Por Nevena Menkovic, ingeniera en software