SonarQube est un outil permettant d’analyser le code du projet (CSS, PHP, JS, HTML, XML, etc) pour s’assurer qu’il tiendra dans le temps: respect des conventions de code, testabilité, complexité, etc seront mesurées par Sonar, qui fournira un bilan de l’état de santé du projet (qualité).

Sonar, un outil répandu

Sonar est un outil répandu et éprouvé, permettant d’assurer qu’un projet n’est pas en train de partir dans le décor. Un projet part souvent dans le fossé s’il tombe dans certains écueils pourtant connus et faciles à éviter:

  • Non-respect des conventions de nommage
  • Duplication de code
  • Complexité algorithmique trop grande (code>if imbriqués, fichiers de 10.000 lignes,…)
  • Dépendances fortes d’une classe à l’autre
  • Failles de sécurité (XSS, injections, etc)

Sonar se charge d’éviter cela en analysant le code pour déterminer si vous respectez les conventions de code (variables en camelCase, classes en UpperCamelCase), si la complexité de votre code n’est pas en train d’exploser (trop de

if
imbriqués dans tous les sens), si votre code est testable (et si vos tests couvrent bien la totalité du code), s’il y a trop de code dupliqué, si votre code est lent (sélecteurs CSS mal conçus par exemple) etc.

Toutes ces mesures seront alors récapitulées pour chaque projet. Je ne vais pas vous faire le détail de l’installation de Sonar ou de son utilisation, mais en voici au moins un aperçu dans le cadre de mes projets. D’abord, la page d’accueil récapitulative (dashboard) vous indiquera d’un coup d’oeil les projets en rade (trop de “technical debt”, c’est à dire qu’il vous faudra passer beaucoup de temps pour remettre le projet dans les rails).

La page d’accueil de Sonar, récapitulant les projets

Ensuite, pour chaque projet, vous avez un récapitulatif qui vous indiquera les “issues” (problèmes) à traiter, le temps qu’il vous faudra (très très approximatif mais bon), le taux de code dupliqué, etc. Au bout de quelques mois, cela constitue un excellent outil pour savoir si le projet dégénère ou non. Pour Dracca, le nombre de lignes augmente, mais la dette technique diminue: c’est très bien!

Le détail pour un projet (Dracca)

Après, vous avez la liste des issues de chacun de vos projets. Le jour où vous voudrez faire le ménage dans votre code, vous saurez donc par où commencer et ce qu’il vous reste à faire.

Les “issues” du projet

Chaque issue est alors indiquée dans le code même du projet, pour vous permettre de mieux la visualiser. Il est également possible de brancher Sonar à votre IDE (disons Netbeans) pour que cette information soit directement remontée dedans. Ainsi, dans l’IDE, vous aurez un indicateur vous spécifiant quelles lignes de code présentent des issues. Reste pour vous à les corriger.

Pour chaque fichier du projet, les problèmes détectés sont indiqués

Enfin, vous pourrez ajouter vos propres métriques si besoin, et visualiser leur évolution à chaque analyse du code. Pour ma part, j’ai rajouté deux métriques: le temps moyen de chargement des pages du projet (avec une pondération: les pages les plus souvent vues auront plus de poids) et le temps maximum de chargement des pages. L’idée est donc d’avoir une information sur l’évolution de la réactivité du projet. Ce n’est pas très fiable pour Dracca, car ces métriques sont faites sur très peu de visites des pages, mais c’était une occasion pour les tester. On peut envisager d’autres métriques statiques plus fiables: poids du dépôt Mercurial, nombre de fichiers (cette métrique existe par défaut), nombre de commit entre les versions déployées, poids min/max/moyen de chaque image, etc.

Le dashboard d’un projet peut être personnalisé, et afficher des métriques spécifiques

Voilà pour un bref tour d’horizon de Sonar. Je vous invite à l’essayer, et même si l’intérêt vous semblera nul au début (ce fut mon cas!), vous verrez à terme qu’on peut en faire plein de choses et que sa puissance ne se ressent qu’après plusieurs mois d’utilisation, quand vous aurez un historique de l’évolution du projet. En effet, sans notion d’historique, Sonar n’a pas grand intérêt: il en a dès lors que vous pouvez visualiser l’évolution dans le temps de votre projet, et voir pourquoi vos codes partent dans le décor.