L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
Analyse de code statique avec des outils Open Source pour les projets AEM
La mise en œuvre de l'analyse de code statique peut sembler une tâche ardue. Dans certains cas, cela peut être vrai en fonction de la logistique, du calendrier et d'autres facteurs. Il existe cependant un moyen simple et rapide de l'implémenter pour les projets AEM. En utilisant des outils open-source tels que CheckStyle SpotBugs, PMD et JaCoCo vous ne paierez rien et en récolterez tous les bénéfices. En tirant parti de ces outils, vous pouvez:
- Assurez-vous que tout le monde suit les mêmes normes pour garder votre base de code uniforme
- Attrapez tôt les erreurs courantes et les vulnérabilités de sécurité connues
- Accélérez les révisions de code car il agit comme un réviseur automatique
- Enseignez parce que des années d'utilisation des analyseurs transformeront les codeurs en programmeurs .
Gardez à l'esprit que c'est dans le contexte du développement d'AEM. D'une manière générale, il existe 3 langues. HTL, JavaScript et Java. Nous nous concentrerons ici sur l'analyse Java.
Commençons par créer un archétype projet:
mvn -B archetype: generate -D archetypeGroupId = com.adobe.aem -D archetypeArtifactId = aem-project-archetype -D archetypeVersion = 25 -D appTitle = "Mon site" -D appId = "monsite" -D groupId = "com.mysite" -D aemVersion = 6.5.5
Fichiers de règles
Chaque scanner aura besoin d'un ensemble de règles personnalisé. Le moyen le plus simple de les rendre disponibles pour votre build est de les empaqueter dans un fichier jar. Dans le projet d'archétype que vous avez créé, ajoutez un nouveau dossier appelé static-analysis . À l'intérieur, créez ce fichier POM:
4.0.0 com.mysite static-analysis 1.0.0-SNAPSHOT UTF-8
Créez un dossier de ressources et à l'intérieur du suivant 2 fichiers XML:
-
src / main / resources / my-checkstyle.xml -
src / main / resources / my-pmd.xml
For CheckStyle 8.41, vous pouvez télécharger les conventions de codage Sun par défaut à partir de ici .
Pour PMD, vous pouvez utiliser l'ensemble de règles vide suivant. Nous aborderons la configuration plus tard.
Assurez-vous d'ajouter static-analysis à la liste des modules dans le POM racine. Ces fichiers seront désormais disponibles via une dépendance au module static-analysis . Si vous souhaitez le rendre disponible pour d'autres projets, vous pouvez publier ce module dans un référentiel Maven.
CheckStyle
CheckStyle scanne votre code Java et recherche les erreurs de style. Indentation correcte, accolades, etc. Cela aide à appliquer les normes de codage. Vous pouvez trouver la liste des vérifications pour CheckStyle 8.41 ici .
Sur mes projets AEM, j'utilise les vérifications Sun par défaut. Les seuls changements que j'apporte sont:
... ...
... ... ......
- Editez le
core / pom.xmlet ajoutez le plugin suivant
org.apache.maven.plugins maven-checkstyle-plugin 3.1.2 package [19659034] checkstyle false true true false my-checkstyle.xml false false com.mysite static-analysis 1.0.0-SNAPSHOT com.puppycrawl.tools checkstyle 8.41
Vous pouvez vous référer à la documentation de l'objectif checkstyle: checktyle pour voir ce que fait chaque drapeau. Les choses importantes à signaler sont:
- Nous intégrons notre dépendance
static-analysis. - Le
configLocaioncorrespond au fichier de configuration dans notrestatic-analysis - Nous intégrons la version souhaitée de CheckStyle via une dépendance. Il correspond au lien de fichier Sun Checks ci-dessus pour des raisons de cohérence.
Maintenant, vous pouvez exécuter mvn clean install à la racine du projet et nous obtenons:
[ERROR] Impossible d'exécuter l'objectif org.apache. maven.plugins: maven-checkstyle-plugin: 3.1.2: checkstyle (par défaut) sur le projet mysite.core: Une erreur est survenue lors de la génération du rapport Checkstyle: Échec lors de l'exécution du checkstyle: Il y a 47 erreurs signalées par Checkstyle 8.41 avec my- ensemble de règles checkstyle.xml. -> [Help 1]
CheckStyle signale 47 erreurs et la construction a échoué. Vous pouvez essayer de les corriger, mettre à jour le fichier de règles afin qu'elles soient exclues ou définir l'indicateur du plug-in false afin que nous puissions passer à PMD.
Pour afficher le rapport, ouvrez le file at target / site / checkstyle.html .
PMD
Contenu pour tous
Les entreprises qui peuvent répondre rapidement et systématiquement aux demandes des consommateurs prospèrent à une époque de contenu infini. Découvrez comment créer des expériences fluides pour vos clients omnicanaux.
Comme CheckStyle, PMD analysera votre code Java. Au lieu de vérifier le style du code, il plonge pour voir ce que fait votre programme. Ma règle préférée vérifie la complexité cyclomatique . En plus de cela, il fait également CPD (copier-coller-détection). Vous pouvez trouver la liste des règles pour PMD 6.32.0 ici .
Auparavant, nous avons créé un fichier de jeu de règles vide my-pmd.xml . Maintenant, nous allons le construire en référençant les fichiers de règles OOTB qui peuvent être importés. Ensuite, nous excluons de manière sélective les règles dont vous ne voulez pas.
La plupart des règles exclues sont obsolètes. Nous les excluons pour faire taire les avertissements. Sinon, il n'y en a vraiment que 6 que nous excluons car ils ne sont pas pratiques (ou c'est ce que j'ai trouvé) dans les projets AEM. Sinon, j'exécute mes projets avec toutes les règles par défaut OOTB.
Editez le core / pom.xml et ajoutez le plugin suivant:
org.apache.maven.plugins maven- pmd-plugin 3.13.0 package pmd cpd check false true true false my-pmd.xml [19659078] 11 com.mysite static-analysis 1.0.0-SNAPSHOT net.sourceforge.pmd pmd-core 6.32.0 net.sourceforge. pmd pmd-java 6.32.0
Vous pouvez maintenant exécuter mvn clean install à la racine du projet et nous obtenons:
[ERROR] Impossible d'exécuter l'objectif org.apache .maven.plugins: maven-pmd-plugin: 3.13.0: check (par défaut) sur le projet mysite.core: Vous avez 32 violations de PMD. Pour plus de détails, voir: /monsite/core/target/pmd.xml -> [Help 1]
PMD signale 32 violations et la compilation a échoué. Vous pouvez essayer de les corriger, mettre à jour le fichier de jeu de règles afin qu'ils soient exclus ou définir l'indicateur du plug-in false afin que nous puissions passer à SpotBugs.
Pour afficher le rapport, ouvrez le sur target / site / pmd.html .
SpotBugs
CheckStyle et PMD fonctionnent sur des fichiers de code source. SpotBugs d'autre part fonctionne sur le code d'octet compilé. Comme son nom l'indique, il détecte mieux les bogues que les deux autres. Il existe environ 400 modèles de bogues standard.
Tout comme CheckStyle et PMD, vous pouvez créer des fichiers de filtre personnalisés qui peuvent être utilisés pour exclure des vérifications. En pratique, j'ai trouvé que les valeurs par défaut fonctionnent assez bien et s'appliquent raisonnablement aux projets AEM. Nous allons simplement configurer le plugin Maven.
Editez le core / pom.xml et ajoutez le plugin suivant:
com.github.spotbugs spotbugs-maven-plugin 4.2 .0 false true true target / site spotbugs check com.github.spotbugs spotbugs 4.2.2
Now lancez mvn clean install à la racine du projet et nous obtenons un succès de compilation. Aucun bogue repéré. Allez jeter un œil aux descriptions de bogues . Essayez de créer un bogue dans un bundle principal pour voir si SpotBugs le détecte.
Pour afficher le rapport, ouvrez le fichier à target / site / spotbugs.xml .
JaCoCo
JaCoCo est l'outil de reporting qui mesure la couverture du code et génère des rapports visuels. Il s'appuie sur des tests unitaires pour exécuter vos lignes de code, collectant des métriques en cours de route.
S'il est utilisé correctement c'est un bon outil pour écrire des tests unitaires. Il vous aidera à créer des tests unitaires qui explorent tous les aspects possibles de votre code.
Lorsqu'il est utilisé incorrectement, il fournit une mesure de qualité dénuée de sens. J'ai entendu des chefs de développement ou des gestionnaires se vanter d'une couverture d'environ 90%. Ensuite, je découvre que beaucoup sinon tous les tests atteignent les lignes de code, sans test réel. Allez comprendre.
Editez le core / pom.xml et ajoutez le plugin suivant
org.jacoco jacoco-maven-plugin 0.8.6 default-prepare-agent prepare-agent default-report prepare-package report default-check check CLASS LINE COVEREDRATIO [19659135] 0,90 BRANCH COVEREDRATIO 0,90
Dans la configuration, j'ai réglé la couverture LINE et BRANCH à au moins 90%. Consultez les autres compteurs disponibles ici et la configuration des règles ici .
Vous pouvez maintenant exécuter mvn clean install à la racine du projet et nous obtenir un succès de construction. La couverture de l'archétype est assez élevée. Pour faire échouer la règle, supprimez l'un des tests unitaires.
Pour afficher le rapport, ouvrez le fichier à l'adresse target / site / jacoco / index.html .
Conclusion
Si vous traitent d'une base de code existante, la configuration de l'analyse de code peut être impossible. Vous devrez peut-être le configurer pour qu'il signale uniquement au lieu d'échouer la construction comme je l'ai fait ici. Vous aurez un meilleur succès au démarrage d'un projet. Configurez votre analyse de code statique tôt avant le début du développement majeur. Ma suggestion serait d'aller avec autant de valeurs par défaut que possible. Si vous examinez la documentation de chaque règle, elles sont raisonnables. Bien sûr, les choses deviennent subjectives.
Il existe des outils propriétaires tels que SonarQube, Fortify ou CodeClimate. Ils offrent la même analyse avec des fonctionnalités de gestion et de reporting supplémentaires. Si vous êtes toujours dans le processus d'approvisionnement, il n'est pas nécessaire de reporter votre configuration d'analyse statique. J'ai découvert que les projets mis en place avec les outils mentionnés ici passaient facilement lorsqu'ils étaient intégrés à l'outil propriétaire.
Après des années d'utilisation de ces analyseurs de code, je suis devenu assez bon pour les prédire. En fait, mon Java s'est amélioré. Et en tant que réviseur de code, je trouve que cela élimine 90% de l'ivraie et me permet de me concentrer sur la fonctionnalité implémentée.
Si vous vous trouvez en mesure de mettre en œuvre l'analyse sous forme de rapport uniquement, utilisez le Plugin de site Maven. Consultez notre blog où cela (et Clover au lieu de JaCoCo) est discuté ici .
Source link