Sonar – Surveillance de la Qualité du Projet et du Code Open Source
Olivier Gaudin, Freddy Mallet, SonarSource, http://www.sonarsource.com
Qu’est-ce que le sonar ?
Sonar (maintenant appelé SonarQube) est une plate-forme open source utilisée par les équipes de développement pour gérer la qualité du code source. Sonar a été développé avec un objectif principal en tête: rendre la gestion de la qualité du code accessible à tous avec un minimum d’effort.
En tant que tel, Sonar fournit des analyseurs de code, des outils de rapport, des modules de recherche de défauts et une machine à temps comme fonctionnalité de base. Mais il embarque également un mécanisme de plugin permettant à la communauté d’étendre les fonctionnalités (plus de 35 plugins disponibles), faisant de Sonar le guichet unique pour la qualité du code source en répondant non seulement aux besoins des développeurs mais aussi des gestionnaires.
En termes de langages, Sonar supporte l’analyse de Java au cœur, mais aussi de JavaScript, PHP, PL/SQL et Cobol via des plugins (Open Source ou commerciaux) car le moteur de reporting est indépendant des langages.
Depuis la version 2.0, le Sonar permet de couvrir la qualité sur 7 axes et ainsi de faire des rapports sur:
- Code dupliqué
- Normes de codage
- Tests unitaires
- Code complexe
- Bugs potentiels
- Conception et architecture
Le sonar peut être utilisé pour des audits ponctuels, mais a été conçu pour soutenir la stratégie globale d’amélioration continue de la qualité du code dans une entreprise et peut donc être utilisé comme un outil partagé référentiel central pour la gestion de la qualité.
Site Web : https://www.sonarqube.org/
Version du produit : Sonar 2.0
Licence: LGPL V3
Prise en charge: https://www.sonarsource.com/support/
Plugins: https://docs.sonarqube.org/display/PLUG/Plugin+Library
Pourquoi devriez-vous gérer la qualité du code source ?
Un programme bien écrit est un programme où le coût d’implémentation d’une fonctionnalité est constant tout au long de la durée de vie du programme It Itay Maman
En introduction rapide, c’est la meilleure définition de la qualité du code source que j’ai pu trouver. Il devient encore plus fort lorsqu’on le dit dans l’autre sens: un programme abadly written est un programme où le coût de mise en œuvre d’une fonctionnalité augmente au fil du temps.
Ça sonne mal, n’est-ce pas?
Nous avons tous vu des situations où un nouveau projet démarre dont l’objectif est de développer à partir de zéro une application dans une technologie de pointe. Tout va très vite; première, deuxième, troisième sortie, puis tout à coup, la vitesse de l’équipe commence à diminuer. La quatrième version est reportée pour la troisième fois, réparer quelque chose casse autre chose…
Que se passe-t-il ici ? Compte tenu des symptômes, nous pouvons supposer que l’équipe souffre entre autres d’une dette technique et que les parties prenantes n’en sont pas conscientes et ne peuvent donc pas y faire face.
Mais cela sera très probablement résolu car le projet est nouveau, a de la visibilité et donc quelqu’un va s’en occuper (du moins on peut l’espérer).
Mais cet exemple n’était qu’un début, car nous, informaticiens, ne travaillons pas la plupart du temps sur des applications dont le développement a commencé il y a moins de 6 mois ! Notre travail consiste principalement à mettre à niveau des applications existantes. C’est là où la majeure partie de l’argent y est dépensée, où il y a moins de visibilité, où il y a souvent une grosse enveloppe annuelle pour faire le plus possible, où il y a des gens qui sont clés parce qu’ils sont les seuls capables de comprendre le code, où nous n’avons aucune idée de la durée d’un changement, où les régressions sont fréquentes et où les gens ont peur de faire des changements. Et il n’y a fondamentalement aucune attention de la part de l’entreprise à ce sujet, faites-le!
La gestion de la qualité du code source consiste à optimiser le retour sur investissement car cela vous donnera de la visibilité et donc plus de contrôle sur:
- à quel point la maintenance va être difficile, à quoi peut-on s’attendre
- le fait que les choses ne s’aggravent pas
- le fait qu’une certaine attention devrait être accordée à la partie critique du système, pour augmenter par exemple la couverture par les tests unitaires, supprimer les cycles, supprimer les duplications
De plus, cela donne une sauvegarde aux développeurs pour lever la main quand ils croient que certains un refactoring est requis qui ajouterait un peu à achange mais aurait un bon retour sur investissement.
Comment gérer la qualité du code source ?
Il y a sept axes techniques qui doivent être examinés lors de l’analyse du code source d’un projet et Sonar est capable de prendre en charge la gestion des sept. Dans l’équipe Sonar, nous aimons les appeler les 7 péchés capitaux du développeur:
- non respect des normes de codage et des bonnes pratiques
- manque de commentaires dans le code source, en particulier dans les API publiques
- ayant des lignes de code dupliquées
- ayant un composant complexe ou / et une mauvaise répartition de la complexité entre les composants
- n’ayant pas ou peu de couverture de code par des tests unitaires, en particulier dans une partie complexe du programme
- laissant des bogues potentiels
- ayant une conception spaghetti (cycles de paquets…)
La première étape de la gestion de la qualité du code source consiste vraiment à définir lequel de ces axes est important pour vous et dans quelle mesure.Ensuite, en fonction de la situation actuelle, un plan devrait être établi pour atteindre le niveau cible (cela pourrait être simplement pour maintenir un niveau de qualité élevé). Il est très important de commencer petit et d’aller plus grand lorsqu’il est pleinement adopté par toute l’équipe de développement.
Voyons maintenant comment utiliser le sonar dans cette approche.
Profils de qualité
Sonar permet de gérer plusieurs profils de qualité afin d’adapter le niveau requis au type de projet (support uniquement, nouveau projet, application critique, lib technique…). La gestion d’un profil consiste en :
activer / désactiver / règles de codage de poids
définir des seuils sur les métriques pour l’alerte automatique
définir l’association projet / profil
Tableaux de bord
Sonar contient 2 tableaux de bord qui donnent une vue d’ensemble pour obtenir des indices sur les problèmes éventuels et comparer les projets:
- une vue consolidée qui montre tous les projets
- un tableau de bord de projet est également disponible au niveau des modules et des packages
Outils de chasse
Pour confirmer que ce qui semble être un problème est vraiment un problème, Sonar propose un ensemble d’outils de chasse qui permet de passer de l’aperçu aux détails les plus petits:
- explorez toutes les mesures affichées pour voir ce qui se cache derrière les nuages de classes
- pour trouver les classes moins couvertes par les tests unitaires
- hotspots pour avoir sur une page le plus et le moins de fichiers
- et une entrée multiple (duplication, couverture, violations, succès des tests…) visionneuse source pour confirmer les résultats obtenus avec les outils de chasse
TimeMachine
Il ne fait aucun doute que savoir où se trouve une application est très important. Mais encore plus important est de connaître et de comprendre son évolution.En effet, que vaut-il de savoir qu’il y a 20% de couverture de code par les tests unittests? Est-ce bon ou mauvais? La réponse est-elle différente s’il y a deux mois, elle était de 15% ou de 25%? TimeMachine permet de regarder l’évolution et de rejouer le passé, d’autant plus qu’il enregistre les versions du projet
Comment fonctionne le Sonar ?
Le sonar est constitué d’une architecture assez simple et flexible composée de trois composants:
- Un ensemble d’analyseurs de code source regroupés dans un plugin Maven et déclenchés à la demande. Les analyseurs utilisent la configuration stockée dans la base de données. Bien que Sonar s’appuie sur Maven pour exécuter des analyses, il est capable d’analyser des projets Maven et non-Maven.
- Une base de données permettant non seulement de conserver les résultats de l’analyse, des projets et de la configuration globale, mais également de conserver l’analyse historique pour TimeMachine. 5 moteurs de base de données sont actuellement pris en charge : Oracle, MySQL, Derby (démo uniquement), PostgreSQL et MS SQLServer
- Un outil de reporting web pour afficher des tableaux de bord de qualité de code sur des projets, rechercher des défauts, vérifier la machine à temps et configurer l’analyse.
Dans le cadre de ses analyseurs, Sonar core embarque les meilleurs outils pour détecter les violations des règles de codage (PMD, Checkstyle), détecter les bogues potentiels (Findbugs) et mesurer la couverture par des tests unitaires (Cobertura, Clover). Mais ce qui rend Sonar vraiment unique est Squid, son propre analyseur de code qui analyse non seulement le code source, mais aussi le code d’octets et mélange les résultats.
Étant donné que l’analyse est exécutée via un plugin Maven, Sonar peut être lancé facilement dans des environnements « d’intégration continue ».
Cas d’utilisation sur le projet Apache commons-collection
Une condition préalable pour exécuter Sonar est d’avoir Java et Maven installés sur la boîte. Une fois que c’est le cas, vous pouvez exécuter le sonar en 5 étapes simples :
1. Téléchargez la distribution à partir de https://www.sonarqube.org/ téléchargements / et décompressez-la
2. Ouvrez une console et démarrez le serveur:
> $ SONAR_HOME\bin\windows-x86-32\StartSonar.bat sur windows
> $SONAR_HOME/bin//sonar.sh sur d’autres plateformes
3. Ouvrez une console où vous souhaitez extraire la source et exécutez :
svn co http://svn.apache.org/viewvc/commons/proper/collections/trunk/.
4. Exécutez mvn install sonar: sonar dans le même répertoire
5. Parcourir http://localhost:9000
La page d’accueil de l’application affiche la liste des projets sous contrôle de qualité avec quelques métriques configurables.
Pour zoomer, il vous suffit de cliquer sur le projet et d’obtenir son tableau de bord
De là, vous avez accès à une série d’outils de chasse parmi lesquels:
Le hotspot pour connaître les fichiers qui ont « le plus » ou « le moins »…
De plus, n’importe quelle mesure du tableau de bord est cliquable pour sauter à la fin de la scène et obtenir une vue de la mesure par composant sous-jacent
Chaque outil de chasse amène finalement le chasseur au code source où les proies sont mises en évidence
L’écosystème Sonar
Il existe un écosystème très dynamique autour de Sonar
- Une communauté active composée de plus de 300 personnes sur la liste de diffusion des utilisateurs et de plus de 150 personnes sur la liste de diffusion du développement
- 35+ plugins sur la forge (http://docs.codehaus.org/display/SONAR/Sonar+Plugin+Library/) qui se répartissent en quatre catégories
- Intégration avec des outils externes tels que Jira, Hudson, Bamboo, GateIn, AnthillPro, Crowd
- Extension directe des fonctionnalités de base en ajoutant un nouveau comportement, calculez des métriques avancées ou consolidez des projets, ajoutez de nouvelles métriques
- Ajout d’une couverture de langages tels que PL / SQL, ActionScript3
- Intégration avec desEs pour obtenir des informations sur les défauts du code lorsqu’il est modifié
- Plus de 3 000 téléchargements par mois
- Une équipe de développement de base dirigée par SonarSource (http://www.sonarsource.com)
Conclusion
Après l’adoption massive de moteurs d’intégration continue et pratiques de développement pilotées par les tests, la gestion de la qualité des sources ressemble à la prochaine étape naturelle pour les équipes de développement dans leur effort d’industrialisation. Le sonar permet d’atteindre cet objectif avec peu d’efforts et avec plaisir.
En 2010, la plate-forme Sonar va continuer d’évoluer, les principaux axes de développement étant la couverture de nouveaux langages et l’amélioration de l’intégration avec lesEs.