Sonar (SonarQube) – Cuidado con la Trampa

Sonar (SonarQube) – Cuidado con la Trampa
Sonar (SonarQube) – Cuidado con la Trampa

SonarQube, comúnmente conocido como Sonar, es una herramienta de uso gratuito para medir la calidad del código. Rápidamente se convirtió en el favorito del universo del desarrollo de software. Sin embargo, estamos presenciando trampas comunes en su uso. Aunque esta herramienta es excelente, también puede llevar a malas prácticas.

Quédese tranquilo, este artículo no es un ataque contra Sonar (SonarQube); esta herramienta es excelente y su popularidad está bien merecida. Si no está familiarizado con ella, SonarQube proporciona paneles de control para seguir la calidad del código fuente que constituye un producto en desarrollo. Con solo unos pocos clics, sus usuarios pueden acceder a una gran cantidad de detalles adicionales para ayudarlos a identificar áreas de mejora. Esto es ideal para mantener la excelencia técnica a lo largo del desarrollo de un producto.

Sonar (SonarQube) – Las Trampas

Sin embargo, veo muchas trampas en el uso de esta herramienta… o, más precisamente, en el uso impuesto de esta herramienta.

En algunas organizaciones, la herramienta simplemente se impone a los equipos por equipos de « artesanos »… Pero aún peor, se imponen todos los indicadores de seguimiento. Mientras que estos equipos de desarrollo de software deberían tener idealmente una mentalidad ágil, se les presiona hacia una mentalidad ITIL.

Pero, ¿por qué imponer su uso?

Las causas fundamentales son en última instancia muy similares a las de los equipos Scrum a los que se les exige proporcionar un seguimiento « preciso » de la velocidad.

Las empresas utilizan estos indicadores para:

  • Monitorear la calidad técnica de los equipos.
  • Hacer comparaciones entre equipos.
  • Revisar el estado de ciertos proveedores.
  • Recordar al equipo su obligación de entregar calidad.

En resumen, lamentablemente, el uso de Sonar (SonarQube) a menudo está impulsado por razones muy equivocadas. Los equipos pierden su autonomía, la presencia de proveedores está condicionada (aunque no se admita), y las personas astutas pueden lograr buenos resultados con un código mediocre… Porque sí, cualquier sistema se puede manipular.

Cuando veo que algunas empresas exigen que los equipos sean sometidos a una auditoría de un experto en desarrollo de software… simplemente están olvidando la agilidad en sí misma… y, en mi opinión, ni siquiera podemos hablar de desarrollo de software. ¡artesanal!

Así que tenga en cuenta que esto no ocurre en todas las empresas.

Entonces, ¿cómo se debe usar Sonar (SonarQube)?

SonarQube debería ser una herramienta disponible para cada equipo que crea que les ayudará a mejorar la calidad de su trabajo. No la imponemos; ofrecemos la solución.

¡Pensar que imponer una herramienta garantizará la calidad es un error! Existe una mayor probabilidad de que estos indicadores de calidad oculten una realidad desastrosa.

Por otro lado, un equipo que quiera usar Sonar (SonarQube) tiene tres veces más posibilidades de producir un código limpio. ¿Por qué? Porque están motivados por su elección de dar seguimiento a su trabajo.

Los desarrolladores de software deben ponerse a disposición para ayudar a aquellos equipos que deseen asistencia en sus esfuerzos de mejora continua. Es en este contexto que los entrenadores técnicos pueden ser muy efectivos.

Imponerlo a un equipo no será más que una fachada… y los indicadores resultantes confirmarán cifras manipuladas mientras ocultan una realidad mucho más grave. Estamos hablando de métricas de sandía.

De hecho, Sonar (SonarQube) es una excelente herramienta, pero puede convertirse en una maldición cuando se impone. ¡Mantengámonos ágiles y aprovechemos realmente lo que esta herramienta puede ofrecer!

Soyez le premier à commenter

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*