A la suite de notre webinar Refonte vs Evolutions du 8 avril (voir le replay), nous avons décidé de lancer une série d’articles sur le sujet précis de la dette technique. En effet, ce sujet est souvent à l’origine de décision importante pour votre projet. Le fait de maintenir un niveau de dette technique raisonnable permet aussi de garantir la pérennité de votre projet.
Nous avons divisé cette série en 5 parties : comment mesurer la qualité du code, les performances back et front et quels outils sont pertinents pour la qualifier, une partie sur l’obsolescence technique et enfin les bonnes pratiques pour la limiter.
La mesure à la fois de la performance mais aussi de la qualité nous paraissent être des indicateurs au suivi de votre projet comme le suivi financier ou encore le suivi budgétaire. Sans cela il est difficile de piloter votre projet et savoir si il pourra durer dans le temps ou pas.
- Pour plus de détails sur la dette technique, vous pouvez lire les autres articles de cette série :
- Performance Back-End
- Performance Front-End
- L’obsolescence technique
- Les bonnes pratiques
Pourquoi et comment mesurer la qualité de votre code ?
On peut déjà se poser la question du Pourquoi ? Certains d’entre vous ne verront sûrement pas directement l’intérêt de mesurer la qualité de code, mais cela vous donne un très bon indicateur à suivre dans le temps. Ca permet de vérifier si le niveau de qualité augmente ou diminue et le cas échéant si cette diminution n’est pas trop rapide.
Des outils existent pour mesurer la qualité du code produit. Nous allons nous attarder sur SonarQube qui est l’un des leaders du marché. Cet outils permet de tester la qualité de votre code quel que soit votre projet ou le langage utilisé.
L’intérêt principal de SonarQube est que vous pouvez configurer ce que vous considérez comme étant des bonnes pratiques. Vous pouvez ainsi avoir des indicateurs correspondant à vos guidelines de développement (il existe aussi des configurations par défaut correspondant aux langages de programmation).
Ce tableau de bord vous permet de visualiser en un instant des calculs faits par SonarQube :
- Le nombre de bugs et vulnérabilités détectés selon une base de connaissance SonarQube
- La qualité de code exprimée en nombre de jours de développement pour rattraper la dette. Cet indicateur ne correspond pas toujours à la réalité sur le nombre de jours. En revanche il est très fiable quant à sa progression. S’il augmente, votre code est de moins en moins bon, s’il diminue votre code sera meilleur
- Le pourcentage de duplication de code, est aussi un très bon indicateur pour vérifier si vous n’avez pas plusieurs fois des bouts de code copié-collé, ce qui serait une mauvaise pratique dans le cadre de la maintenance (vous améliorer votre code à un endroit mais vous oubliez les autres …)
La vérification continue
Une autre fonctionnalité intéressante de SonarQube est la vérification continue :
Dès que vous envoyez un nouveau code, par exemple via Git, vous pouvez jouer une analyse sur ce code afin de valider sa qualité isolée. Cela vous donne par exemple l’information de code smell qui correspond à des mauvaises pratiques de développement par rapport aux règles que vous avez défini.
Vous pouvez aussi voir le pourcentage de couverture de code. De mon point de vue, il n’est pas utile de tendre tout le temps vers 100% de couverture, cet indicateur doit être mesuré en fonction du code.
Comme vous avez pu le constater, l’important dans la mesure de la qualité du code n’est pas plus dans le chiffre obtenu que dans son évolution.
Evidemment, lancer un projet dont la qualité est déplorable à la sortie serait une très mauvaise idée. Un indicateur à garder en tête est : est-ce que j’arrive à rattraper ma dette technique ou au contraire est-ce que ma qualité de code se détériore de jours en jours, jusqu’à à atteindre une limite insoutenable (plus maintenable) ?
partager
