SonarQube es una herramienta para desarrolladores - Excentia


Antes de iniciar la parte gruesa de este artículo y la razón por la que escribimos hoy aquí, queremos destacar que es un placer para excentia poder colaborar con el proyecto QA Lovers. Muchas gracias Víctor por tu invitación y sobre todo, por tu predisposición, energía y ganas por seguir mejorando la calidad del software de las aplicaciones. Estamos seguros que personas con tu conocimiento, experiencia y humildad lograrán que la calidad reine en el mundo tecnológico.
Para aquellos que no nos conozcan y con tal de ponernos en contexto, en Excentia somos QA Lovers :) Nuestro ámbito de especialización es la calidad desde dos grandes campos o perspectivas: la gestión de procesos y la calidad propia del producto software. Con esa filosofía nacimos hace 10 años, y con esa misma visión seguimos ahora tratando, tanto de  mejorar nosotros, como de ayudar a nuestros clientes a hacerlo.
Para conseguirlo, trabajamos como partners codo con codo con dos grandes players en el mercado: Atlassian y SonarSource. Nuestro conocimiento experto en SonarQube es lo que nos permitió conocer a Víctor, y estar hoy aquí aportando nuestro granito de arena y tratar de generar una comunidad de amantes de la calidad software.

El título de este artículo es bastante explicativo de lo que a continuación nos disponemos a exponer: SonarQube es una herramienta para desarrolladores sí, no es una herramienta para fiscalizar los proyectos, medir la rentabilidad de un producto software o espiar a los equipos de desarrollo. Sin embargo, durante nuestros años de experiencia nos hemos encontrado con que esa era la realidad en muchas organizaciones.
Son multitud de situaciones a las que, o bien nos hemos enfrentado directamente, o bien, escuchamos en redes, blogs y foros de opinión.
SonarQube provoca frustración en muchos equipos de desarrollo. Tras haber estado trabajando en un nuevo código, añadiendo funcionalidades, habiendo echado humo el teclado… SonarQube detecta que algo no va bien. Además, los desarrolladores tienen en muchas ocasiones la sensación de que SonarQube fiscaliza erróneamente su esfuerzo (pista en algunas organizaciones sí ocurre, pero eso ¿es culpa de la herramienta? ¿Tiene culpa la espada o el caballero que la blande?). Incluso hemos sido testigos de quejas y negación de resultados hacia la herramienta, que no funciona correctamente… Amigos desarrolladores, SonarQube detecta falsos positivos, tenedlo en cuenta.
Pero lo interesante en todo esto es preguntarse por qué esta animadversión de los desarrolladores hacia SonarQube.
Son varios los motivos que en excentia hemos detectado:
1.     Una interpretación errónea de los datos: tenemos que entender que SonarQube es una herramienta de mejora continua que mide código estático y por tanto, cambios constantes. Es vital entender el concepto del “leak period” así como la filosofía “Fix the leak” (https://www.excentia.es/una-fuga-de-agua-cambia-el-juego-en-la) en la que SonarQube se basa.
2.     Introducción de alguna evidencia bloqueante o crítica que hace que la calificación del proyecto caiga. ¿No se ha mejorado? Por supuesto que sí, en el momento se corrige esa evidencia, seremos capaces de observar que el cómputo global es mejor.
3.     El peso de las calificaciones del código antiguo es mayor que el del código nuevo. Suele pasar cuando los equipos de desarrollo se enfrentan a proyectos que no han escrito ellos mismos, cuando tratan con legacy code, o cuando manejan proyectos muy grandes en los que hay que trabajar poco a poco.
4.     Actualización de la plataforma: actualizamos a la última versión de SonarQube y… ¡oh sorpresa!, se detectan más evidencias. ¿Está peor el código? No, la herramienta lo mide mejor y te permitirá mejorar la calidad todavía más.
Teniendo en cuenta estos escenarios, desde excentia proponemos una serie de iniciativas y actividades que permitan a los equipos de desarrollo  combatir esa desafección.  Una vez esa “fase de negación” haya sido superada, los desarrolladores serán capaces de aprovechar todas las ventajas que SonarQube, SonarCloud o SonarLint ofrecen.
Nuestro objetivo, y esperamos que el vuestro, sea conseguir una comunidad feliz.

Volviendo a las “soluciones” o a como remediar la desafección de desarrolladores hacia SonarQube, las propuestas son varias:
1.     Formación: ¿sabes usar realmente SonarQube?, ¿sabes interpretar adecuadamente los datos? Pero sobre todo: ¿conoces el nuevo paradigma de calidad?, ¿sabes aplicarlo al día a día de tu equipo de desarrollo? No hace falta que digamos que la formación no es una cosa puntual. Provee a tus equipos de una fuente de información en la que puedan conocer detalladamente nuevas métricas, novedades en la herramienta, etc.
2.     Pide al equipo de sistemas (o al equipo encargado) que documente los cambios en las actualizaciones, para que los desarrolladores entiendan por qué sus métricas han cambiado. Comunicar es clave.
3.     Usa SonarLint (https://www.sonarlint.org/). Corrige defectos en tu propio IDE, pero sobre todo, entiende el contexto y la razón por la que se producen. Edúcate como desarrollador haciendo lo que mejor sabes, desarrollar. ¡Ah! Y no te olvides de sincronizar tu SonarQube con tu SonarLint para mantener siempre actualizados y en la misma posición a todos los colaboradores, estén estos dispersos, sean proveedores distintos, etc.
Y con estos consejos y buenas prácticas llegamos al fin de nuestro artículo. Esperamos que haya sido de utilidad, que podáis aplicar nuevas prácticas y principios y que todos desarrollemos un código más seguro y de mayor calidad.
¡No dudéis en consultar cualquier duda con nosotros (https://www.excentia.es/)!
Siguiente Publicación

Comentarios