Nous travaillons sur un projet Web à partir de zéro et examinons les outils d'analyse de code statique suivants.
Le projet est construit sur Maven. Au lieu d'utiliser plusieurs outils à cette fin, je cherchais une solution flexible unique et suis tombé sur SonarQube.
Est-il vrai que nous pouvons obtenir les résultats de Checkstyle, PMD et Findbugs avec SonarQube?
Réponses:
Sonar exécutera CheckStyle, FindBugs et PMD, ainsi que quelques autres "plugins" tels que Cobertura (couverture de code) par défaut pour les projets Java. La principale valeur ajoutée, cependant, est qu'il stocke l'historique dans une base de données. Vous pouvez alors voir la tendance . Est -ce que vous améliorerez la base de code ou que vous faites le contraire? Seul un outil avec mémoire peut vous le dire.
Vous devez exécuter Sonar dans votre système CI afin que même les choses qui prennent un certain temps à s'exécuter (comme le CPD - détecteur de copier-coller) puissent s'exécuter. Et vous aurez votre histoire. Alors qu'avec un plugin Eclipse, par exemple, vous détecterez les violations plus tôt - ce qui est génial - mais vous serez tenté de l'exécuter moins souvent s'il commence à prendre trop de temps, ou d'exécuter moins de "plugins de qualité" (comme sauter CPD ou sauter l'analyse de la couverture du code). Et vous n'aurez pas d'histoire.
De plus, Sonar génère des rapports visuels , de style «Tableau de bord». Ce qui le rend très facile à saisir. Avec Sonar dans Jenkins, vous serez en mesure de montrer aux développeurs et à votre direction les effets du travail effectué sur la qualité de la base de code au cours des dernières semaines et mois.
Sonar utilise ces 3 outils comme plugins et agrège les données des trois en donnant une valeur ajoutée en affichant des graphiques et autres à partir de ces outils. Ils sont donc complémentaires du sonar.
Oui et non. En plus des autres réponses.
SonarQube est actuellement en train de désapprouver PMD, Checkstyle et Findbugs et d'utiliser leur propre technologie pour analyser le code Java (appelé SonarJava ). Ils le font, car ils ne veulent pas passer leur temps à réparer, mettre à jour (ou attendre dessus) ces bibliothèques (par exemple pour Java 8), qui utilisent par exemple des bibliothèques obsolètes.
Ils ont également obtenu un nouvel ensemble de plugins pour votre IDE personnel appelé SonarLint .
Sonar est génial, mais si vous souhaitez utiliser les outils mentionnés séparément tout en conservant de jolis graphiques, vous pouvez utiliser le plugin Analysis Collector dans le cadre de votre build Jenkins CI. Un léger avantage de ceci est que vous pouvez vérifier votre configuration PMD / Findbugs / Checkstyle dans votre SCM et l'intégrer dans votre build Maven, plutôt que de vous fier à un serveur Sonar séparé.
Sonar est bien plus que ces seuls outils. Le plus grand avantage est l'interface graphique, qui vous permet de tout configurer facilement. Les statistiques qu'il propose sont très détaillées (lignes de code, etc.). Et il offre même un excellent support pour la couverture des tests, etc. :)
Ici vous pouvez jeter un bon coup d'oeil: http://nemo.sonarsource.org/
J'utiliserais toujours ces outils en plus du sonar car ils peuvent échouer lors de la construction du maven lorsque quelqu'un enfreint une règle. Où comme sonar est plus rétrospectif.
... quelques années plus tard: non, ça ne l'est pas! SonarQube suppose de pouvoir couvrir toutes les règles avec son propre analyseur, mais il existe encore des règles de PMD ou CheckStyle non couvertes par SonarQube. Voir par exemple: PMD ReturnFromFinallyBlock.
Eh bien au moins depuis SonarQube 6.3+, il semble que Findbugs n'est (pour le moment) plus pris en charge en tant que plugin. Sonarsource travaille sur le remplacement des règles Findbugs par son propre plugin Java.
Ils ont même une liste pour le statut de remplacement de chaque règle ici: http://dist.sonarsource.com/reports/coverage/findbugs.html