Retour sur le JUG de Lausanne sur l'analyse de la qualité du code Java
Il y a deux semaines a eu lieu le JUG de Lausanne sur l'analyse de la qualité du code. J'en ai été l'organisateur et la publication de la vidéo de cet événement m'a donné l'occasion de le revivre et m'a donné envie de le commenter. Voilà donc mes impressions personnelles sur cet événement.
Quelques explications pour commencer sur mes motivations : travaillant chez OCTO Suisse, j'audite régulièrement des applications sur des technologies variées, principalement JEE et C/C++ (personne n'est parfait). Comme tout le monde, j'ai mes habitudes et les outils que je maîtrise, et depuis quelques audits la sensation de faire un peu la même chose et de voir très souvent les mêmes problèmes (les deux sont certainement liés). D'où cette pulsion : découvrir de nouvelles manières d'auditer, de nouveaux outils, de nouveaux problèmes...
Tout d'abord je dis bravo aux éditeurs qui se sont tous pliés aux règles du jeu et qui ont réalisé ce mini-audit dans un format de présentation assez original et pas si facile. En deux mots, ils devaient présenter le résultat de l'audit de la même application avec leur outil, en 20 minutes et avec un maximun de démo et un minimum de slides (voir ici pour plus de détails). Ils l'ont tous fait de manière différente et je vais essayer de passer au travers de ce que j'ai aimé / moins aimé.
Sur la forme
J'avoue que j'ai été particulièrement impressionné par Freddy de Sonar. Pour moi c'est le seul à avoir réussi à donner une vision globale de la qualité d'IceScrum2 et qui a donné son plan d'action pour remédier à ces problèmes de qualité. En fait cela marque une différence d'approche très nette entre les éditeurs. Alors que Sonar a eu une approche top-down, les autres éditeurs ont eu plutôt une approche bottom-up. Henri d'XDepend a également eu une approche top-down mais c'était moins formalisé (il n'y a pas de dashboard dans l'outil) et il manquait un vrai plan d'action.
Autre élément de forme, Freddy a fait sa présentation en duo, avec lui en speaker et une personne au clavier pour la démo. C'était un plus indéniable, lui permettant de se concentrer sur le discours.
Sur le fond
3 éditeurs sur 5 (Coverity, Parasoft, Sonar) étaient d'accord, le logiciel IceScrum2 est d'une qualité moyenne selon leurs benchmarks. Sur ce point, j'ai été fortement impressionné par l'avis et par le benchmark de Coverity : 'IceScrum2, 4 bugs / 1000 LOC, un logiciel dans la moyenne'. Jusque là rien d'extraordinaire me direz-vous. Ce qui m'a marqué, c'est la pertinence de ces chiffres. La moyenne provient de lignes de codes analysées via le programme Coverity Scan, soit plus de 14,5 milliards de LOC ! Et pour ce qui est de la fiabilité de l'indicateur, le taux de vrai positif (bugs avérés) est au-delà de 70% (je ne me rappelle plus du chiffre exact). J'avoue que j'ai été scotché. J'ai tellement l'habitude de devoir trier les faux-positifs ou les violations mineures dans les outils de qualité que, pour moi, il s'agit d'un vrai différentiateur pour Coverity de ne se concentrer que sur des bugs avérés.
Pour les deux autres éditeurs, Headway et XDepend, la conclusion était moins élogieuse. Ces outils sont positionnés de manière un peu différente, ce sont plus des outils d'analyse de l'architecture que des chercheurs de bugs comme Coverity, Parasoft ou Sonar. Pour Headway, l'architecture était plutôt mauvaise de leur point de vue : le code est spaghetti, il n'y a aucune structure au dessus des classes (*). Du côté d'XDepend, on a plutôt eu le droit à un ensemble de constats mais pas de vraie conclusion sur la qualité globale. Dommage.
Un manque sur lequel pour moi tous les outils se rejoignent, c'est que la plupart des benchmarks nous ont été donné de manière orale par les éditeurs. Extraits choisis : '[ndlr pour les duplications] au-delà de 2%, c'est qu'on a des problèmes', '4 bugs / 1000 lines of code is average' etc… Pourquoi ne pas plutôt intégrer ces benchmarks dans les outils et les faire apparaître de manière visuelle (via une couleur, par exemple sur les différentes zones du dashboard Sonar) ?
Sur la technologie
Côté technologie, 3 produits m'ont impressionné : Coverity, (Re)Structure101 et XDepend.
Je ne m'étendrais pas sur XDepend, connaissant bien le produit puisqu'il est édité par OCTO. En deux mots, ce qui m'impressionne toujours avec cet outil c'est sa capacité à vous aider à rentrer dans le code et à l'explorer de manière visuelle. C'est également le seul outil du panel qui vous permet grâce à un langage SQL-like (le CQL) de requêter votre code au-delà des simples recherches sur des classes que vous pouvez faire dans votre IDE (usages, références, définition).
Structure 101 et Restructure 101 m'ont impressionné sur la façon dont ils restituaient et structuraient les dépendances. L'outil arrive à hiérarchiser les dépendances pour les rendre naturellement sous forme de couches. J'ai bien aimé également les notions de fat versus tangled que met en avant l'outil et aussi le discours qui va avec l'outil, notamment le fait que la structuration progressive des langages s'est arrêtée à la classe (label, fonction puis classe). Il y a une réelle valeur à structurer son logiciel à des niveaux d'abstractions supérieurs, ce qui devrait être fait au travers des packages et des binaires par exemple.
Mon troisième waouh va à Coverity. J'ai tout d'abord été impressionné par leur analyseurs. Par exemple leur analyseur 'Flow Analysis' est capable de détecter de manière statique des cas habituellement détectés au runtime, car il propage les valeurs de retours et d'appels entre fonctions, ce que ne fait pas l'analyseur 'Flow Analysis' de JTest par exemple. Il y avait notamment un cas de mauvaise synchronisation remonté par JTest au runtime alors que Coverity le remontait à l'analyse statique. Ensuite, un autre type d'analyse très impressionnante est leur 'intention checks', en français les vérifications de l'intention du développeur. Ces analyseurs détectent de manière statistique des comportements suspicieux. Par exemple un développeur qui ne vérifie pas la valeur de retour d'une fonction alors qu'elle est vérifiée dans 9 cas sur 10 dans le reste du code. Ou un développeur qui utilise l'opérateur == sur un objet alors que dans 5 cas sur 6 c'est equals() qui a été utilisé. Le dernier point, c'est que l'outil a l'air vraiment puissant pour analyser non pas une version d'un logiciel mais toute la vie d'un logiciel. L'analyse présentée par Coverity contenait tout l'historique et les différentes branches d'IceScrum2 et la démo mettait en avant quels défauts étaient présents dans quelle branche, les branches où le défaut avait été corrigé etc... Les autres éditeurs étaient loin de cela et le simple fait d'avoir été capable d'importer l'historique pour une simple démo montre que l'outillage de Coverity doit être à la hauteur. Enfin, c'est peut-être un détail mais les commentaires des erreurs paraissaient vraiment clairs.
Dernier point sur la technologie, je n'avais jamais vu d'analyseurs dynamiques en action et je dois avouer que cela m'a pas mal impressionné. Parasoft et Coverity ont démontré cette fonctionnalité dans leur sessions respectives et quand on voit les bugs qui en ressortent (à première vue surtout des bugs de concurrence) alors qu'ils n'ont stimulé l'application qu'avec quelques clicks, je n'ose pas imaginer la valeur des résultats de ces analyseurs en les faisant tourner sur des tests fonctionnels ou sur des tests de charge.
Sur l'utilisabilité
JTest est clairement le vainqueur ici car il s'intègre directement dans l'outil principal du développeur, son IDE. Pour les autres outils, Sonar et Coverity sont simples et ergonomiques. La difficulté pour maîtriser ces 3 outils ne vient clairement pas de l'outil mais de la compréhension des erreurs remontées par ces outils. Que veut dire cette erreur ? Est-elle importante ? Devrais-je la désactiver sur mon projet ?
Reste XDepend et Structure 101, qui sont deux clients lourds avec des interfaces assez évoluées et riches. Ces outils demandent néanmoins un vrai apprentissage avant d'être maitrisés, c'est très impressionnant en démo mais une fois seul face à la bête, mieux vaut se diriger vers les webcasts pour la prendre en main. Pour donner un ordre d'idée, j'ai encore découvert de nouvelles fonctionnalités sur XDepend au cours de la présentation d'Henri et il m'a bien fallu 2-3 audits avant d'avoir vraiment pris en main la bête.
Sur le prix
Je ne sais pas si on peut corréler le prix et la valeur mais les prix de ces 5 produits sont très différents, allant de gratuit à quelques milliers d'euros voire dizaine de milliers d'euros pour une licence serveur. Coverity est clairement l'outil le plus cher des cinq et ma perception est que ses analyseurs sont les plus évolués (parmi ses concurrents : Sonar et JTest). Reste la question sous-jacente : est-ce que ça en vaut le prix ?
Des regrets ?
Je dois dire que j'ai eu quelques regrets sur cette soirée. Premièrement l'absence d'un des leaders, à savoir CAST Software, qui n'a pas souhaité se joindre au comparatif. Ensuite, le fait qu'on ait principalement vu des problèmes remontés dans du code Java. Je m'attendais à au moins voir des problèmes sur la couche Web (HTML, JavaScript, CSS) et au mieux sur la base de données (schéma, requêtes etc…). Cette déception rejoint d'ailleurs le point précédent car c'est clairement une force de CAST ou de Metrixware d'être capable de faire des analyses multi-technos et aux frontières des technologies.
En parlant des absents, un autre regret est d'avoir dû se limiter dans le nombre d'éditeurs présents. Le concept de la soirée a en fait particulièrement séduit les éditeurs et deux éditeurs se sont montrés inventifs afin de pouvoir participer à l'événement : Kalistick et SQuoRING ont en effet publié dans la foulée leur analyse d'IceScrum2 et je vous encourage à les consulter ici et là.
Un point qui relève plus du détail est que j'espérais voir l'offre de JTest sur la partie génération de tests unitaires. C'est vrai que ça sortait du cadre de l'audit et je comprends donc qu'ils n'aient eu ni le temps ni l'occasion de l'aborder. Une prochaine fois, peut-être…
Enfin un dernier regret, qui est plus un souhait en fait, est de ne pas avoir (encore) essayé les outils. Je connais déjà assez bien Sonar et XDepend mais parmi les 3 restants, j'espère bien essayer sur un prochain audit, dans cet ordre, Coverity, Structure 101 et JTest. Histoire de pouvoir confirmer ou infirmer ce qui est aujourd'hui une première impression.
J'espère vous avoir donné envie d'en savoir plus sur ce thème et sur cette session, vous pouvez retrouvez les slides et la vidéo sur SlideShare et Parleys, bon visionnage !
- (*) ce constat est à prendre avec des pincettes car Headway a concentré sa présentation sur IceFaces, qui est la librairie JSF qu'utilise IceScrum2 et pas du code IceScrum2 à proprement parler