La version 2.1 de Sonar vient de sortir. Parmi une cinquantaine d'améliorations et corrections de bogues se trouvent également trois fonctionnalités majeures qui viennent enrichir l'analyse de la conception et de l'architecture :
- La cartographie des bibliothèques : qui utilise quelle bibliothèque et en quelle version ?
- Détection des appels aux méthodes obsolètes ;
- Détection du code mort.
Cette version améliore également la gestion des langages dans la plate-forme. L'analyse de nouveaux langages est apparue par l'intermédiaire de greffons open source (pour PHP, Flex, .Net) ainsi que commerciaux (pour Cobol, Visual Basic, PL/SQL).
Aller plus loin
- Sonar (14 clics)
- Démonstration de l'application (9 clics)
- Les copies d'écran de Sonar 2.1 (1 clic)
- Utilisation des nouvelles règles Squid (4 clics)
- Notes de publication de la version 2.1 (1 clic)
- Sortie de la version 2.0 de Sonar (8 clics)
# Précisions
Posté par franck villaume (site web personnel) . Évalué à 4.
Un changement intéressant à noter entre la 2.0 et la 2.1 est la modification d'API qui rend certains plugins incompatibles. Attention avant de migrer.
# arf...
Posté par kowalsky . Évalué à 9.
===> [ ]
[^] # Re: arf...
Posté par El Titi . Évalué à 4.
http://linuxfr.org//2010/05/26/26896.html
[^] # Re: arf...
Posté par kowalsky . Évalué à 2.
[^] # Re: arf...
Posté par Mat (site web personnel) . Évalué à 9.
Je l'utilise depuis plus d'un an pour un projet commencé from scratch. Je le précise car dès le début nous avons mis en place des conventions assez strictes sur la qualité du code. Je sais par expérience que c'est quelque chose de quasi impossible à mettre en place sur un gros projet existant.
Nous avons donc rapidement utilisé sonar en conservant sa configuration initiale sur les règles PMDs, checkstyle et cobertura.
Nous avons placé des alertes assez élevées sur le pourcentage de réussite des tests unitaires (100% sinon alerte), de code violation (100% également) et de couverture de code par les tests unitaires (95%).
Les pourcentages paraîssent élevés, mais lorsqu'on en a pris l'habitude, cela devient très rapide du code qui les respecte. Le plus difficile a été d'écrire des tests unitaires qui couvrent jusqu'à 100% du code.
À l'usage il faut reconnaître que ça prend du temps, que ce n'est pas toujours amusant à faire, mais nous n'avons jamais hésité un instant lors de phases de gros refactoring car nous savions qu'il y avait un vrai garde fou.
D'autre part, le fait que sonar centralise toutes ces données au même endroit permet d'un coup d'oeil de savoir quel module ne respecte pas les conventions. Cela a créé dans notre équipe une sorte de jeu : faire en sorte que notre code atteigne 100% sur chacun des compteurs.
Nous avons d'autres conventions aussi (mais là je sors du cadre sonar) :
- placer commentaire sur chaque classe
- modulariser le code (On pourrait presque le mesurer avec la complexité cyclomatique. Il me semble que sonar a introduit une nouvelle métrique dans une version récente pour la modularité)
D'un côté purement pratique, maven [1] s'installe très vite et n'exige pas d'administration. Les pages sont réactives, c'est très lisible, on voit très vite où est le code fautif.
Avec maven c'est d'une simplicité enfantine de lancer un build pour sonar.
Pour ceux qui utilisent l'intégrateur continu hudson [2], il existe un plugin pour que chaque build lance aussi l'instrumentation nécessaire pour sonar.
Bref, je suis un utilisateur convaincu et je conseille vivement !
[1] http://maven.apache.org/
[2] http://hudson-ci.org/
[^] # Re: arf...
Posté par Mat (site web personnel) . Évalué à 6.
je sais que c'était une vanne, mais je pense que ça intéresse du monde qd meme
:P
# Pour demain
Posté par Sytoka Modon (site web personnel) . Évalué à 0.
[] <- pas vu de bull dans les centres scientifiques publiques...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.