[Devoxx FR 2012] – De l’audit de Code à l’Inspection Continue

Lors d’un tools in action, Olivier Gaudin de Sonar Source nous a montré comment Sonar a évolué d’un simple outil d’analyse de code à un outil permettant de suivre l’évolution de la qualité du code dans le temps.

 Dans cette rapide présentation (30 minutes),  Olivier Gaudin a refait le parcours de l’outil Sonar les ayant menés à la version 3.0 qui vient de sortir. Le tout afin de mieux appréhender comment notre code, et surtout sa qualité, évolue dans le temps. Mais surtout de mettre à profit cet outil afin de faire de l’inspection continue.

Tout d’abord, Sonar a été créé à l’origine en tant que simple outil d’analyse de code. Il a rapidement permis de détecter les problèmes que ce soit au niveau de la couverture des tests, la duplication de code, de mauvaises pratiques ou même la détection de certains bogues.

Cependant, lors de l’utilisation interne de l’outil au sein de SonarSource, l’équipe maintenant le logiciel s’est rendu compte de plusieurs problèmes.

Dans un premier temps, ils ont instaurés une approche “jusqu’au-boutiste”, leur objectif était de passer à 0 anomalies remontées par Sonar. Au bout de quelques temps, ils se sont retrouvés avec une centaine de défauts qu’ils ne pouvaient pas corriger et qui étaient liés à des frameworks ou des décisions d’architectures sur lesquels ils ne voulaient/pouvaient pas revenir.

Ils ont donc commencé à mettre au point des métriques permettant de voir, en plus de la qualité du code à un instant T, l’évolution entre deux dates. Sonar est devenu capable de distinguer la qualité du code existant et la qualité du nouveau code.


Cette fonctionnalité est extrêmement importante pour les projets legacy et pourtant, reste méconnue. En effet, sur nos projets de tous les jours, nous avons déjà un passif énorme et le premier lancement de Sonar nous laisse souvent désœuvré devant les 14571 anomalies, la plupart critiques, trouvées.

En nous permettant de nous concentrer uniquement sur le nouveau code, il est beaucoup plus facile de ne pas se démoraliser et de faire baisser les anomalies et monter la couverture de code progressivement.

Avec cette évolution de l’application, l’équipe de SonarSource à donc changée son objectif, non plus à 0 anomalie, mais à 0 nouvelle anomalie. Malheureusement, il se sont rapidement rendu compte qu’il s’agit toujours d’une approche idéaliste.

Certaines anomalies sont acceptables, soit parce qu’elles sont temporaires (il est rarement pertinent de refactorer du code que l’on est sûr de supprimer dans les mois qui suivent uniquement pour faire plaisir à un outil d’analyse) ou parce qu’elles étaient induites par des décisions d’architecture qu’il était trop couteux de remettre en question à quelques jours de la livraison.

Sont donc arrivées de nouvelles fonctionnalités de revue de code directement dans Sonar. Les anomalies détectées peuvent donc être commentées et possèdent un workflow afin de les assigner à quelqu’un pour correction rapide, reporter la correction à plus tard, changer leur criticité, etc. Il devient possible d’orienter Sonar  pour qu’il ne vous embête plus avec des problèmes que vous ne corrigerez jamais sans voir sa liste de problèmes inévitablement augmenter.

Afin de faciliter la vie des développeurs, un plugin eclipse est également disponible afin d’intégrer toutes ces fonctionnalités directement dans l’IDE. Le plugin n’est pas encore optimal car il analyse tout le projet et non pas uniquement le delta depuis le dernier commit, mais d’après Olivier les équipes planchent sur le sujet afin d’améliorer grandement les performances.

 Au final, Sonar est bien plus qu’un simple outil d’analyse, bien utilisé il vous permet d’avoir un suivi très fin de l’évolution de votre code et surtout, permet d’améliorer du code legacy sans avoir à gérer, dans l’immédiat, les problèmes causés par le code existant.

Personnellement, je ne connaissais pas ces fonctionnalités et elles auraient été fort utiles sur de nombreux projets sur lesquels j’ai pu travailler, qui lançaient Sonar de temps en temps uniquement pour déprimer devant les chiffres sortis et, à la rigueur, vérifier que ça n’empirait pas trop. J’ai donc hâte de voir en pratique si elles permettront d’améliorer plus facilement la qualité de base du code existant.

Nombre de vue : 38

AJOUTER UN COMMENTAIRE