Lors de la Devoxx 2019 se déroulant au Palais des Congrès de Paris, Helen Wallace, développeuse Java, et James Mac Mahon, spécialiste Devops sont tout sourires sur la scène qui les élève au-dessus de la petite foule de développeurs venus les écouter. Ils nous expliquent tranquillement qu’il n’y a pas de fatalité à la lourdeur et aux défauts portés par du code legacy, aussi vaste et complexe soit-il. Murex, éditeur logiciel dans le domaine de la finance, a réussi à venir à bout d’une dette technique de plus de 3 000 jours et ce, selon leurs dires, dans la joie et la bonne humeur ! Leur méthode, dont le cœur technologique est SonarQube, est un savant mélange de compétition entre développeurs, analyse rigoureuse de code (Java) et management intelligent. C’est cette solution, baptisée Sonar Smash, qui m’a frappé par sa relative simplicité, son ingéniosité et son efficacité, que je me propose de vous présenter. Nous commencerons par la base, à savoir le produit-clé SonarQube.

SonarQube : quoi, pourquoi, comment ?

               SonarQube (ancien Sonar), développé par l’entreprise SonarSource, est un outil de review automatique de code permettant de détecter les bugs, les vulnérabilités, le test coverage et les codes smells de vos projets. Celui-ci permet une inspection continue du code dans toutes les branches des projets. Et également un suivi de métriques reflétant la qualité du code. Disponible pour plus de 25 langages (Java, C++, C#...), c’est un outil incontournable de la mouvance Clean Code, branche du Software Craftsmanship.

En prenant l’exemple du langage Java, qui est celui utilisé pour les projets Murex concernés par SonarSmash, SonarQube, via l’analyzer particulier SonarJava, permet la mise en évidence, le suivi et même parfois la correction automatique des problèmes suivants :

• Null pointers

• Conditions inutiles (ifs imbriqués)

• Vulnérabilité à l’injection de code

• Ressources allouées non-utilisées

• Problématiques de concurrence

• Non-respect des conventions et syntaxes…

On peut s’appuyer sur plus de 500 règles dédiées au langage Java.

SonarJava couvre aujourd’hui le langage jusqu’à

sa version 11, et est compatible avec les frameworks Struts, Spring et

Hibernate. Il s’intègre facilement avec Maven, Gradle ou Ant.

            SonarQube s’intègre aussi de façon fluide dans votre IDE (Eclipse ou IntelliJ), via le plugin Sonarlint. Cela vous permet de détecter immédiatement d’éventuels codes smells ou vulnérabilités mises en évidence par Sonarlint dans les classes que vous éditez. Le plugin propose aussi une fenêtre de suivi de problèmes et des vérifications automatiques lors de commits ou pushs, ce qui est très appréciable non seulement pour le refactoring de code défectueux mais également pour la prévention d’ajouts de nouveaux défauts (personne n’est infaillible !).

Pour les

détails techniques d’intégration de SonarQube (configuration du server

centralisé, de l’analyseur, le couplage Git, Jenkins, Maven/Gradle…), vous

pouvez consulter la documentation fournie en bas de l’article. L’installation

et le set up de SonarQube est assez simple pour un développeur un tant soit peu

expérimenté.

Autres Outils

            Lors de la mise en place de Sonar

Smash, les équipes d’Helen Wallace et James Mac Mahon ont utilisé des outils

auxiliaires à SonarQube. Lors de la présentation de la Devoxx, ils ne sont pas

rentrés dans le détail de l’imbrication et de l’architecture globale de leur

solution, on peut comprendre qu’ils aient gardé quelques secrets de

fabrication.

            Néanmoins, voici la liste des outils

logiciels qu’ils ont cité et rendant possible Sonar Smash chez Murex, avec leur

rôle probable dans le projet :

• JaCoCo : générateur de rapports de code coverage

• Walkmod : refactoring respectant les conventions de code

• CodeMaat : analyse de données d’un système de contrôle de versions

• Semmle : plateforme d’analyse de code

• Black Duck : intégration sécurisée d’outils dans un framework DevOps

La documentation relative à ces différents outils est disponible en fin d’article.

Sonar Smash

            Le principe de Sonar Smash est, selon ses créateurs, en anglais dans le texte : Fuelling the removal of technical debt through competition.

Concrètement, il s’agit de faire participer des équipes de développeurs à un

grand concours courant sur une période assez étendue, dont l’objectif est

d’améliorer la qualité du code managé par ces équipes. La compétition repose

sur un système de scoring lié aux indicateurs de Bug/vulnérabilités/Code

Smells/Coverage produits par SonarQube.

            Les équipes de Murex sont parties d’un constat simple et commun à toutes les entreprises développant des projets logiciels internes : leur dette technique, c'est-à-dire les parties de code historique mal documentées ou de mauvaise qualité pèsent de façon démesurées sur le développement de leurs projets en cours. Le code legacy est souvent confus, peu couvert par les tests, bourré de code smells selon SonarQube… Mais corriger des centaines de classes et des milliers de lignes de codes est un long et fastidieux travail auquel aucun développeur ne veut réellement prendre part. On peut penser qu’on a toujours mieux ou plus urgent à faire…

            Pour remédier à ce problème, Helen et James ont créé une compétition, le fameux Sonar Smash. Par équipes de quelques personnes constituées volontairement (souvent de séniorité et de départements différents), les développeurs jouent à celui ou celle qui nettoiera le plus possible le capharnaüm du code legacy. Un système de récompense (trophée, repas…) est mis en place pour motiver les participants. Ceux-ci profitent le plus souvent de temps morts pour s’atteler au refactoring du code. Ils utilisent parfois Sonar Smash comme l’équivalent d’une pause ludique entre deux plages de travail plus intenses.

            S’intégrant dans le cadre de

l’agilité, les responsables Sonar Smash publient à la fin de chaque Sprint (2

semaines) les scores de chaque équipe. Le système de points, issu d’un travail

d’ajustement assez long, est calculé ainsi :

            (issuesRemoved x 5) + (linesOfCode x changeInCoverage x 2)

Avec : 

• issuesRemoved : alertes Sonar résolues

• linesOfCode : lignes de code traitées

• changeInCoverage : nouvelles zones de code couvertes par les tests unitaires

Ces données sont récoltées grâce aux outils que nous avons décrits précédemment.

            A la fin de chaque sprint, l’équipe

ayant obtenu le plus de points se voit attribuer un score de 4 points, la

suivante 3 points et ainsi de suite. Ces scores sont enfin cumulés à la fin de

la compétition (3 sprints typiquement), et l’équipe avec le plus grand score

l’emporte ! Ce double système de points et score permet de ne pas créer un

écart trop important dès le début de la compétition, afin de préserver la

motivation des équipes en course.

Equipes

Round 1

Score

Round 2

Score

Round 3

Score

Total

Spiderman

150

2

255

2

523

3

7

Hulk

260

3

352

4

490

2

9

IronMan

104

1

145

1

650

4

6

Captain America

310

4

311

3

25

1

8

Tableau des scores au bout de 3 sprints (noms d’équipes authentiques)

            Après les premières éditions de Sonar Smash, Helen et James se sont rendus compte que de plus en plus de développeurs s’inscrivaient spontanément à la compétition. En effet, le titre de vainqueur du Sonar Smash était convoité et source de fierté (pour ne pas dire de vantardise !). De plus, la collaboration au sein des équipes a permis un échange des compétences et des savoirs qui a permis à bon nombre de projets en cours d’avancer plus rapidement (sans parler d’une meilleure maîtrise du code legacy). En s’habituant à refactorer régulièrement, les développeurs ont progressé techniquement. Ils ont davantage de plaisir à travailler avec un code plus propre. Et ils ont même mis à jour de vieux bugs perdus dans les poussières du temps… D’un point de vue social, technologique et opérationnel, l’expérience est donc une réussite !

Conclusion

Sonar Smash a été et continue d’être un succès au sein de Murex. En témoignent les résultats à l’issue des premières compétitions :

• 50 développeurs y ont participé

• 250 classes ont été refactorées

• 1208 alertes Sonar résolues

• 7186 lignes de code traitées

Si ces chiffres vous font rêver, sachez que je pense qu’il est possible de reproduire l’expérience dans beaucoup d’environnements de développement de taille et de configurations variées. Il faudra bien sûr à chaque fois s’adapter aux spécificités du code et des équipes concernés, mais les développeurs comme le code source en ressortiront plus sains et plus efficaces que jamais.

Documentations

• SonarQube : https://docs.sonarqube.org/latest/

• SonarJava : https://www.sonarsource.com/products/codeanalyzers/sonarjava.html

• Installation Sonar dans le détail et en français : https://www.troispointzero.fr/articles/sonarqube/

• Sonarlint : https://www.sonarlint.org/

• Walkmod : http://walkmod.com/

• CodeMaat : https://github.com/adamtornhill/code-maat

• Semmle : https://help.semmle.com/wiki/display/SD/Java+analysis+1.20

• JaCoCo : https://www.eclemma.org/jacoco/

• Black Duck : https://github.com/blackducksoftware?language=java

• Présentation de la conférence à la Devoxx 2019 : https://cfp.devoxx.fr/2019/talk/OTA-4226/Sonar_Smash_:_fueling_the_removal_of_technical_debt_through_competition

L'expertise JAVA organise un webinar d'initiation à la pratique de Sonar Smash le mercredi 22/04 à 12h15.