Début de la nouvelle saison du Paris JUG ce mardi 15 septembre avec une soirée sur la qualité du logiciel. La soirée était divisée en 4 sessions de 30 minutes. Après une présentation de la démarche qualité et des différents types d’outils open-sources, nous avons eu 3 présentations sur Sonar, SonarJ et Squale. Une superbe soirée avec 200 personnes dans une salle comble.
1)Contrôle Qualité avec des outils open-source par François le Droff et Romain Pelisse
Romain Pelisse et François le Droff débutent par une bonne présentation afin passer en revue les outils open-sources. Romain est contributeur du projet PMD et leader du projet XRadar. François est contributeur sur XRadar. Tout d’abord, quelques mots sur la qualité. Mesurer la qualité de son logiciel, c’est d’abord contrôler sa complexité. Lorsque votre logiciel ne fonctionne plus, vous êtes victime d’une tragédie, pas d’une statistique. J’en profite pour vous parler d’un document de 1995 qui ne fait que 8 pages et qui résume plus globalement le Chaos du développement logiciel : The Chaos Report par the Standish Group Report. Bref la qualité c’est fun, et l’on peut même parler de Développement Piloté par la Qualité.
Qui est responsable de la qualité ? Tout le monde. Du développeur au Chef de projet en passant par l’Architecte. Quand ? Tout le temps. La Qualité n’est pas une option que l’on ajoute à posteriori. C’est une démarche qui doit faire partie du cycle de compilation et de déploiement de votre logiciel. Comment mettre en place des outils d’analyse de la qualité ? L’intégration continue est un bon endroit pour mettre en place ces outils. Ce qui est intéressant par contre dans un produit comme SonarJ que l’on verra ensuite, c’est qu’il est possible de mettre en place ces outils dans l’environnement de développement. Un des points forts d’IDEA IntelliJ c’est l’intégration d’un moteur de qualité qui est présent au moment de l’écriture de votre code. C’est bien souvent quelque chose que les développeurs découvrent, alors que finalement cela devrait être obligatoire dans un IDE en 2009.
Il existe différents types d’outils pour l’analyse du code Java. Des outils d’analyse statique, du bytecode, des archives Java et d’autres comme l’analyse de la couverture de tests de votre code. PMD est un moteur d’analyse du code source Java, intégré avec un grand nombre d’IDE. Il permet d’identifier les bugs potentiels, le code mort, le code mal optimisé, le tout avec environ 250 règles. C’est un appareil de radiographie qui vous permet d’analyser du code de manière statique. Mon favori c’est aussi FindBugs, un projet qui ne paye pas de mine mais qui génère des statistiques vraiment intéressantes pour trouver des bugs dans votre code. Les outils d’analyse du bytecode sont un peu moins précis mais permettent de détecter des cas que l’analyse de code source ne peut pas trouver. L’analyse du bytecode permet de générer des métriques de package sur le nombre de classes concrètes, abstraites et publiques. Il permet de détecter les dépendances cycliques, de calculer le degré d’abstraction ou d’instabilité du package. Je pense que le produit XDepend dont je vous ai parlé il y a quelques mois, correspond à cette description. Il y a aussi des outils d’analyse des dépendances. Pratique afin de voir le sac de noeuds de votre projet Maven. Vous pouvez d’ailleurs retrouver une liste des outils d’analyse statique sur Wikipedia si vous cherchez un outil pour du C/C++/Java ou .NET.
En conclusion pour cette première présentation, c’était un sans faute. Rythme parfait, et après 30 minutes nous étions en plein dans le sujet.
La présentation complète est en ligne :
2)Sonar par Olivier Gaudin
Olivier est l’un cofondateur de la société SonarSource, éditeur du logiciel open-source Sonar. Sa présentation était construite autour de la définition des 7 péchés capitaux du développeur, et de la réponse de l’outil Sonar. Sonar permet de collecter, d’analyser et de générer des rapports de la qualité pour la plateforme Java. Intégré à Maven, l’outil permet de mettre en place et de suivre l’évolution dans le temps d’indicateurs de qualité.
Olivier commence sa présentation avec la phrase suivante : « A well-written program is a program where the cost of implementing a feature is constant throughout the program’s lifetime. » de Itay Maman. Ce sera d’ailleurs la même idée qui sera reprise ensuite avec la présentation de SonarJ. L’objectif de Sonar est de proposer un moyen de maîtriser l’érosion technique et de conserver un indicateur de la qualité, capable de remonter dans le temps.
Les métriques d’analyse de la complexité d’un logiciel ne sont pas neuves. La complexité cyclomatique, les standards de programmation, les tests unitaires, en fait tout ceci a bientôt 20 ans. Sonar propose de mesurer, de visualiser, d’agir et de suivre les améliorations dans le temps. Avant de commencer avec Sonar, Olivier appuie le fait qu’il soit indispensable de mettre en place un gestionnaire de code source, un environnement d’intégration continue, un moteur de construction du logiciel maîtrisé comme Maven et un gestionnaire d’incident comme Jira. Quelque part, la gestion des incidents devrait faire partie de Sonar pour moi. Ce serait aussi le moyen de mesurer les progrès réalisés non ?
Les 7 péchés capitaux s’appliquent très bien à ce que nous faisons, nous, les développeurs. Que ce soit l’avarice, l’envie ou la gourmandise, en effet on pense aux non-respect des standards de programmation, à la duplication de code, au manque de tests unitaires, aux mauvais commentaires, aux bugs potentiels, à la complexité du code, bref à tout ce qu’un développeur peut produire. Pour répondre à cela, Sonar propose un tableau de bord avec une vue synthétique plutôt bien pensée. Un indicateur vous donne ainsi le montant de votre dette technique en dollars. Ce montant est calculé si votre équipe devait fixer l’ensemble des problèmes identifiés, avec un prix unitaire par élément. Cela donne une idée du prix de la dette technique de votre logiciel.
Olivier termine par une démonstration de l’interface de Sonar. L’interface est plutôt bien pensée. Les indicateurs radars, les courbes d’évolution, tout ceci nous donne un sentiment de qualité sur le logiciel. Je pense que Sonar est un produit rapide et simple à mettre en oeuvre, et qu’il est dommage de s’en passer si votre projet est déjà en place avec Maven par exemple. La version 2.0 est prévue pour la fin de cette année
3)SonarJ
Frédéric Brachfeld présente ensuite le produit SonarJ, dont la version 5.0 vient justement de sortir. SonarJ est un produit dont j’ai déjà parlé plusieurs fois sur le Touilleur Express (ici et surtout là). C’est un produit qui se résume par une image : une ceinture de sécurité. Il permet de définir des règles d’architecture en se reposant sur le découpage par package Java, mais surtout via un plugin dans Eclipse, de s’assurer que ces règles sont respectées lors de l’édition du code et de la création de nouvelles classes. La démonstration s’est terminée un peu difficilement, ce que je regrette pour Frédéric. Moi j’ai vu ce produit, et j’ai vu une présentation de Frédéric chez mon ancien employeur qui m’avait bluffé. Vraiment l’effet « Wahouu » pendant la démonstration. Ce qu’il faut bien comprendre, c’est que c’est un moyen de rendre plus intelligent votre code source, pour un effort relativement simple. C’est aussi un outil qui vous permet de réorganiser votre code source. J’entendais des gens critiquer la séance de découpage des packages et dire « ouais dans la vraie vie les packages ne sont jamais si bien rangés »… ce qui est tout à fait vrai. Mais justement, cet outil permet de reprendre la main sur un sac de noeuds, il permet de reranger le code. Et surtout, il permet de s’assurer que le code ne redevient pas n’importe quoi en quelques semaines.
J’en parle comme si j’avais des actions chez SonarJ, ce qui n’est pas le cas. J’en parle car j’étais déçu que la démonstration ne se passe pas comme prévu. J’aurais aimé cet effet « Wahouu… ». Testez le produit, c’est le seul qui apporte de la Qualité non pas à posteriori mais à priori. Il vous aide au moment d’écrire votre code, pas une fois qu’il est commité dans Subversion.
Version open-source de SonarJ.
4)Squale
Enfin pour terminer, et là j’ai trouvé que la présentation venait conclure parfaitement la soirée, nous avons eu une présentation de Squale (Software QUALity Enhancement) par Fabrice Bellingard. La démarche du produit est de proposer une offre différente des produits existants. Squale analyse du code Java, du C, du C++ et du Cobol. Le point fort que Fabrice présente dès le début, c’est l’élaboration de modèles évolués. Je m’explique. Plutôt que de définir des métriques à effet de seuil, le moteur travaille avec des métriques linéaires. Là où un produit affiche un carré vert si la méthode doSomething fait 30 lignes, et un carré rouge si celle-ci fait 31 lignes, Squale propose une approche différente en lissant justement cet effet. Cela permet de rendre plus pertinent l’analyse et de donner des résultats plus précis afin de suivre la qualité de votre logiciel.
Squale s’adresse au développeur afin qu’il identifie les zones à risque. Il s’adresse au Chef de projet qui souhaite par exemple contractualiaser un niveau de qualité, et mettre en place des exigences en terme de tests afin de travailler avec un prestataire exterieur. Enfin il s’adresse aux responsables du produit, en offrant des indicateurs de plus haut niveau, afin de donner une idée de la complexité d’une application.
Les métriques dans le développement logiciel sont certainement aussi nombreuses que le nombre de langage existant. Mais l’un des indicateurs qui marche bien, c’est le « WTF per minut ». Lorsque vous lisez du code écrit par quelqu’un d’autre, combien de fois dites-vous à voix haute : « mais c’est quoi ce b… ? ». Plus sérieusement, Fabrice explique par contre que la recherche a validé avec des modèles des axiomes comme « la probabilité d’avoir un bug dans une méthode est proportionnel à la complexité cyclomatique de celle-ci ». Et c’est une des caracteristiques importantes de Squale.
Squale est aussi développé en collaboration avec l’Inria-Futurs de Lille et LIASD-Paris 8. Les modèles de qualité sont donc validés par des chercheurs. De plus, l’entreprise Qualixo qui développe le produit, travaille avec PSA et Air France afin d’utiliser de réels projets pour affiner les modèles. C’est aussi une caractéristique importante du produit.
Après cette présentation, Fabrice a effectué une démonstration du produit. L’approche de l’analyse s’effectue sur 4 niveaux. Tout d’abord la collecte des données brutes, ensuite l’analyse des pratiques (comme les règles de nommage), le respect de critères ensuite et enfin des facteurs qualitatifs comme l’estimation du coût de maintenance. L’interface Web de Squale permet en fait de naviguer dans son projet. Des indicateurs de ROI, en plus des indicateurs classiques de complexité du code, offrent aussi une vue plus pour les managers et les décideurs. Ainsi j’imagine qu’il sera possible de décider de ne pas refactorer un module de code, car sa dette technique est trop élevée.
L’interface gagnerait à être un peu plus jolie, et un ergonome pourrait aussi aider à classer l’information et à proposer un modèle de navigation. Les données par contre et le principe des modèles est le point fort du logiciel Squale. Une bonne présentation qui m’a intéressé, surtout lorsque l’on pense qu’il permet de supprimer cet effet de seuil « bien/pas bien » qui n’est pas très constructif sur les autres outils.
Conclusion
Pour terminer finalement je repense à la première présentation, où faire de la qualité a été expliqué très simplement. C’est pour votre bien, c’est bon et c’est indispensable. Mesurer permet de contrôler, et d’évaluer aussi la quantité de travail en plus de la qualité. Il faut faire de la qualité, mettre en place ces outils sur vos projets.
Post-Scriptum:
1) Alexandre Boutin sur son blog pointe une conférence Agile 2009 sur le thème « Tout d’abord, tuer toutes les métriques » en anglais.
Je cite :
« L’approche proposée est assez intéressante puisqu’il s’agit de regarder les métriques sous un nouvel angle, celui du comportement. Pour chaque métrique il est intéressant de se poser les 3 questions suivantes : En quoi cette métrique génère un comportement positif ? En quoi elle génère un comportement négatif ? Quel type de comportement permet de contourner la métrique ?
Les orateurs ont également insisté sur le fait que le comportement ( »behaviour ») est émergent et changeant, donc ce qui est vrai à un instant ne l’est plus quelques mois après … et donc il faut être prêt à changer de métrique. […] »
2) Le Spag est une unité de mesure de la dette technique, présenté par James Shore. Encore merci au blog d’Alexandre qui est très complet.
0 no like
Je trouve ce compte rendu plutôt fidèle à ce que j’ai en mémoire. On peut effectivement regretter la démo SonarJ qui a de plus légèrement trainé en longueur (trop de couches dans l’exemple).
Par ailleurs, est-ce réellement Open Source ? J’ai surtout des liens vers une version « Community », limitée à 500 classes par projet (limite très rapidement atteinte). De plus, il faut s’inscrire pour pouvoir télécharger cette version, et l’inscription est vérifiée… Un peu parano.
Sinon, la démo Squale est restée très opaque pour moi… ce n’est que vers la moitié que j’ai réalisé qu’il s’agissait d’un outil du même type que Sonar.
Ceci dit, les 4 présentations furent intéressantes.
C’était une super soirée du JUG et ce post en fait un bon résumé.
Où comment, en une soirée, il était possible d’avoir un bon tour d’horizon de la gestion qualité en Java.