Fermer

mai 4, 2021

Analyse de code statique avec des outils Open Source pour les projets AEM9 minutes de lecture



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.xml et 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 configLocaion correspond au fichier de configuration dans notre static-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 sur false afin que nous puissions passer à PMD.

Pour afficher le rapport, ouvrez le file at target / site / checkstyle.html .

PMD

 Adobe - Contenu pour tous
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.

Obtenir le guide

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 sur 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 .

À propos de l'auteur

Juan Ayala est un développeur principal dans la pratique Adobe chez Perficient, Inc., axé sur la plate-forme Adobe Experience et les choses qui tournent autour d'elle.

Plus de cet auteur






Source link

0 Partages