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.
0 Comentarios