Petit-déjeuner jeudi dernier avec la présentation de SonarJ par Frédéric Brachfeld de PcMetric. Je vous propose de vous parler tout d’abord des besoins et du contexte d’utilisation de SonarJ avant de vous expliquer son utilisation et sa puissance. Je vous propose de ne pas vous faire une brochure commerciale mais d’essayer de vous donner un nouvel angle sur SonarJ
En une phrase, SonarJ est un outil qui permet de vérifier en temps réel qu’un ensemble de classe Java respecte une architecture au moment où l’on saisie une ligne de code. Après avoir décrit votre architecture par tranche et par couche dans SonarJ, un plugin permet dans Eclipse de rendre votre code « intelligent » afin qu’il respecte l’architecture de votre projet.
Le besoin et le constat
En Java, le nombre d’objet et la structure évolue de plus en plus au fur et à mesure des besoins. Le constat est que les coûts de maintenance, sans outils adaptés, vont en augmentant de manière exponentielle. Frédéric Brachfeld pendant la présentation utilise le terme d’érosion d’architecture, que je trouve très juste pour expliquer qu’un projet s’use.
Dans un premier temps, les changements d’équipe font que l’information d’architecture tend à disparaitre. On ne compte plus les projets qu’il faudrait reprendre à zéro après quelques années. La documentation de l’architecture n’empêche pas l’explosion des coûts de maintenance. Et les demandes de modification vont couter de plus en plus cher. En fait, et je reviendrai là dessus tout à l’heure, au moment même où le développeur tape sa ligne de code, finalement rien ne l’empêche d’importer une classe Java d’un autre module de n’importe quelle partie de son application. Or le souci est là. Sans architecture et découpage, le coût de maintenant d’une application explose.
Grâce aux patterns, les développeurs Java sont capables de concevoir du code architecturé afin de séparer les couches présentation, métier et accès aux données. Encore une fois cependant, il n’y a pas de documentation des relations inter-packages dans un projet Java. En clair, il est facile de transformer le plus beau code en une soupe difficile à maintenir.
Le constat est donc qu’il faut un cadre pour documenter l’architecture, s’assurer que les développeurs respectent l’architecture du logiciel et donc réaliser des économies sur le long terme.
Qu’est-ce que SonarJ ?
SonarJ est un produit développé par la société Hello2morrow en Allemagne. L’outil est utilisé par exemple pour le développement de Spring MVC pour en renforcer la qualité. Il s’agit donc d’un outil de rétro-ingénierie qui travaille au niveau du bytecode.
SonarJ se présente sous la forme d’une application Java développée avec SWT. Un plugin très pratique permet ensuite d’ajouter les fonctionnalités de SonarJ directement dans Eclipse. Après avoir lancé l’application, je crée un premier projet. Je décide d’importer le code de notre framework, Karma. 1800 classes Java environ et une dizaine de modules différents.
SonarJ vous propose de découper verticalement votre application par tranche (slice en anglais). Par exemple une partie « Sécurité », une partie « Rapports », une partie « Administration ». Ensuite vous devez découper par couche applicative votre application. Par exemple « web layer », « ejb layer » ou « data access layer ». Vous avez saisi l’idée.
Ce découpage horizontal et vertical constitue une matrice. A vous ensuite de définir les relations entre les différentes couches ou les différentes tranches. SonarJ peut alors vous donner des détails sur les violations d’architecture et les problèmes rencontrés.
Notification en temps réel
SonarJ m’a réellement convaincu lorsqu’au moment de taper un peu de code dans Eclipse, j’ai vu une erreur contextuelle apparaître dans Eclipse me signalant que la couche DAO ne devait pas être accedée directement de la Vue. Clairement, SonarJ rend votre code intelligent au moment même où vous tapez une ligne de code.
Une critique ?
Tout n’est pas rose et il faut aussi que je vous donne mon sentiment sur les points à améliorer. Tout d’abord dans la vue slice ou layer, le moteur de positionnement des boîtes n’est pas très facile à utiliser. Il faut s’y prendre à plusieurs fois pour connecter ses boîtes. Il serait souhaitable d’avoir un système de rangement de ces boites UML-like afin de faciliter notre travail.
Le modèle matricielle ne remplace pas à mon avis une grosse réflexion sur le découpage de son application. Avec 5 tranches verticales et 4 couches horizontales, cela fait autant de case où ranger vos packages. Et cette partie prend du temps. Ce n’est pas une critique, simplement un bémol essayant de dire qu’il faut prévoir du temps pour cette partie qui est très importante avant de commencer à utiliser le plugin dans Eclipse.
Un très bon point: le suivi des corrections
Avoir un outil qui vous signale 46 erreurs dans votre application c’est une chose. Mais là où SonarJ m’a aussi séduit c’est la capacité à créer des mini-tâches afin de les affecter à un développeur. Il est possible de s’intégrer à un outil comme Jira afin de créer des artefact directement à partir de SonarJ. Là encore on voit que le logiciel est clairement orienté industrialisation. Le suivi des corrections est une chose importante pour l’architecte ou le chef de projet.
La revue de code ne sert à rien
J’enfonce une porte ouverte mais c’est dans l’air du temps : la revue de code à posteriori pour vérifier la qualité du code. C’est une chimère qui repose sur le fantasme que deux personnes seraient plus performantes qu’une seule pour relire du code. En effet cela part d’une idée louable mais mieux vaut travailler en amont en programmant en binôme que de faire intervenir une personne pour relire son code. SonarJ remplace je pense le suivi nécessaire d’un architecte ou d’un coordinateur qui s’assure que les personnes n’ajoutent pas d’importation de la vue vers la couche d’accès aux données par exemple. Un très bon point pour SonarJ.
Etablir des règles dans un document Word est complétement inutile
Pourquoi ne pas établir des règles de codage dans un document ou sur un wiki ? Nous pourrions y décrire avec beaucoup de détails qu’une classe ne doit pas faire plus de 300 lignes, qu’il est interdit d’utiliser plus de 15 méthodes publiques. Qu’il faut préférer la délégation ou l’injection de contrôle… et bla bla bla et blaaa blaa bla… En fait l’idée c’est de mettre dans un document une forme d’intelligence en espérant que le développeur respecte à la lettre ces consignes… Je crois que c’est aussi stupide que de donner un gilet de sauvetage dans un 747 qui ne servirait pas à grand chose en cas de crash. Une fois que l’avion s’est écrasé, vous aurez fier allure en disant « et pourtant je vous avais donné les consignes de sécurité… »
SonarJ embarque des outils d’analyse de code et de définitions de métrique. J’ai cru comprendre qu’à la manière d’un Checkstyle ou FindBugs, SonarJ s’intègre à Ant ou Maven afin de générer des rapports au format HTML sur la qualité du code. Et ce, en temps réel. C’est là qu’il faut définir les règles et c’est là qu’il faut les implémenter.
Pour moi un code pourri doit littéralement faire exploser une intégration continue. Il ne faut surtout pas fantasmer sur un document de « règles d’architecture ». Cela dit si vous souhaitez vous lancer dans l’écriture d’un tel document, je cherche quelque chose pour allumer le barbecue cet été.
En conclusion
Objectivement, lorsque vous souhaitez changer l’architecture ou auditer du code, il existe 3 façons différentes de le réaliser. En premier vous faites appel à une équipe en interne, avec un œil neuf sur la question. A mon avis la plus mauvaise idée qu’il soit. En second, vous faîtes appel à une SSII. Si celle-ci n’est pas outillée avec SonarJ je pense que vous allez régler une facture douloureuse. De plus, une fois le contrat terminé, qui continuera à vous garantir de la qualité du code ?
En troisième solution je pense qu’en effet SonarJ apporte des barrières de qualité qui rende le code plus robuste, plus facile à maintenir et que donc nous pouvons réaliser des économies sur le long terme.
Il est possible de télécharger une version d’évaluation limité à 30 jours pour vous faire une idée de SonarJ.
Autres articles:
Article de Erwan Alliaume de Xebia : http://blog.xebia.fr/2008/06/25/sonarj-comment-gerez-vous-votre-architecture-et-votre-qualite-technique/
0 no like
Bonjour,
Sans vouloir faire trop de pub pour ma boîte, il existe une 4ème option : Kalistick. C’est une plateforme de pilotage de la qualité du code proposée en mode SaaS que les développeurs comme les décideurs peuvent utiliser pendant toute la durée du projet. En 2 mots, notre plus-value, c’est de mesurer la qualité du code en fonction des objectifs de qualité de l’application et sans demander le moindre paramétrage ; les exigences techniques sont automatiquement sélectionnées.
Indépendamment de Kalistick, je pense aussi que l’analyse du code doit être réalisée par un tiers parce que la sélection des exigences techniques est un processus complexe et qu’il n’est jamais bon que l’auditeur soit l’audité. Le problème, c’est que c’est souvent du one-shot, 2 audits successifs ne sont pas toujours comparable si la méthode d’analyse n’est pas automatisée. Et les résultats de l’audit sont rarement exploitables à la fois par le développeur (à quel endroit du code se trouve l’erreur) et par le décideur ou chef de projet (quel est l’état de qualité global du projet).
J’aurais pas mal de choses à développer mais je ne veux pas polluer votre blog :-), vous pouvez consulter notre site pour plus de détails.
Sylvain FRANCOIS
Responsable R&D
Kalistick, http://www.kalistick.fr