SonarQube généralement appelé Sonar est un outil libre d’utilisation pour mesurer la qualité du code. Il est devenu très rapidement le chouchou de l’univers software craftsmanship. Cependant, nous voyons des dérives classiques sur l’utilisation de cet outil. Si cet outil est excellent, il ouvre aussi à de très mauvaises pratiques.
Rassurez-vous, cet article n’est pas à charge contre Sonar (SonarQube); cet outil est excellent et sa popularité est amplement mérité. Si vous ne le connaissez pas, il présente des dashboards qui permettent de suivre la qualité du code source qui constitue un produit en cours de développement.
Et en quelques clics, ses utilisateurs peuvent avoir plein de détails complémentaires pour les aider à trouver où apporter des améliorations. En effet, c’est idéal pour que l’excellence technique soit présente tout au long d’un produit.
Sonar (SonarQube) – les dérives
Cependant, je vois beaucoup de dérives sur l’utilisation de cet outil… Ou du moins sur l’utilisation imposée de cet outil.
Dans certaines structures, l’outil est tout simplement imposé aux équipes par des équipes de « craftsmen »… Mais pire encore, tous les indicateurs de suivi sont imposés… Alors que ces équipes de software craftsmanship devrait avoir un état d’esprit agile, elles vont dans un état d’esprit ITIL…
Mais pourquoi imposer son utilisation ?
Les causes root sont finalement très proches de celles où on impose aux équipes scrum de faire un suivi « précis » de leur vélocité !
Les entreprises vont utiliser ces indicateurs pour :
- surveiller la qualité technique des équipes
- réaliser des comparaisons entre équipes
- réviser le statut de certains prestataires
- rappeler à l’équipe sont obligation de fournir de la qualité
- …
Bref l’utilisation de Sonar (SonarQube) est malheureusement régulièrement utilisé pour de très mauvaises raisons. Les équipes perdent leur autonomie, la présence des prestataire est (sans l’avouer) soumis à condition et les petits malins sauront avoir de bons résultats avec du code moyen… Car oui, tout système se détourne.
Quand je vois que certaines entreprises imposent à des équipes, un audit d’un software craftsmanship… C’est juste oublier l’agilité elle même… Et on ne peut même plus parler de software craftsmanship à mon goût !!!
Donc attention, ce n’est pas le cas dans toutes les entreprises !
Alors comment utiliser Sonar (SonarQube) ?
SonarQube doit être un outil disponible pour chaque équipe qui considère qu’il l’aidera à améliorer la qualité de ses travaux. Nous ne l’imposons pas, nous mettons la solution à disposition.
Penser qu’imposer un outil permettra d’imposer de la qualité est une erreur ! Il y a plus de chance que ces indicateurs de qualité cachent une réalité désastreuse.
Par contre une équipe qui désire mettre Sonar (SonarQube) a 3 fois plus de chance de faire un vrai code propre. Pourquoi ? Parce qu’elle est motivé par son choix de suivre son travail.
Les software craftsmanship doivent surtout se rendre disponible pour aider ces équipes qui aimeraient être aidées pour continuellement s’améliorer. C’est dans ce cadre que ces coachs techniques seront très efficaces.
Imposer à une équipe ne sera que de la poudre aux yeux… Et les indicateurs résultant conforteront sur des chiffres détournés tout en cachant une réalité beaucoup plus grave. Nous parlons d’indicateurs pastèques !
En effet Sonar (SonarQube) est un excellent outil mais qui peut devenir un fléau si il est imposé. Restons agile et profitons réellement de l’apport que peut offrir cet outil !
lien utile : site officiel de sonarQube
Soyez le premier à commenter