• Accueil / Salesforce / Utilisation du scanner…
, Utilisation du scanner CLI Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">8</span> minutes de lecture</span>

Utilisation du scanner CLI Salesforce8 minutes de lecture


, Utilisation du scanner CLI Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">8</span> minutes de lecture</span>

introduction

Il y a quelques semaines, j’ai eu ma première exposition au scanner CLI Salesforce et il est juste de dire que j’ai bien aimé – deux articles de blog en deux jours sont au-dessus de ma cadence habituelle. La première chose que je voulais faire était de savoir si je pouvais l’adapter à mes besoins spécifiques, ce que j’ai été heureux de découvrir que je pouvais en créant des règles XPath personnalisées et en les installant dans mon instance CLI.

Le travail suivant consistait à les introduire dans mon flux de travail et à prendre des mesures lorsque des problèmes étaient signalés, ce sur quoi j’ai travaillé dans quel délai je pourrais résoudre.

Personnalisation des jeux de règles par défaut

Certaines des règles par défaut du scanner CLI n’étaient pas applicables à tous mes projets – un exemple étant le Application CRUD / FLS. Si je ne cible pas l’échange d’applications, mon code a souvent besoin de pouvoir effectuer des actions sur des objets et des champs spécifiques, quel que soit le profil de l’utilisateur – je compte sur l’exécution en mode système. Je ne vois pas l’intérêt de laisser cela être signalé comme des avertissements, puis de les cacher ou de les ignorer, alors j’ai voulu exclure cette règle spécifique. Au moment de la rédaction de cet article (octobre 2020), le scanner CLI n’autorise pas l’exclusion ou l’inclusion de règles au moment de l’exécution, j’avais donc besoin d’un moyen de les supprimer du jeu de règles.

Après quelques recherches, j’ai trouvé les configurations de jeu de règles par défaut dans mon ~ / .sfdx-scanner répertoire, je les ai donc copiés et supprimé les règles CRUD. L’exécution du scanner sur mon exemple de base de code a montré que cela n’avait aucun effet, j’ai donc vérifié le fichier pour m’assurer que j’avais supprimé toutes les instances. J’en ai trouvé quelques-uns, les ai supprimés et exécuté à nouveau le scanner avec le même résultat. La vérification des fichiers a montré à nouveau que les règles CRUD étaient toujours en place, et cette fois, je savais que j’avais définitivement supprimé toutes les références, alors j’ai réalisé que ces fichiers de configuration étaient générés au moment de l’exécution, donc toutes les modifications que j’avais apportées étaient écrasées. Retour à la planche à dessin.

Clonage des ensembles de règles par défaut

Comme PMD est open source, les règles sont disponibles dans le Repo Github, donc créer une copie était assez simple. J’ai modifié les ensembles de règles pour supprimer les règles qui ne m’intéressaient pas et pour changer le nom – je ne voulais pas remplacer les valeurs par défaut car il y a des moments où je veux que toutes les règles soient appliquées.

Une autre chose que j’ai apprise depuis mon article original est que si vous vous fiez aux classes de règles Java existantes, vous n’avez pas besoin de créer un fichier JAR contenant le jeu de règles XML, vous pouvez simplement installer le fichier XML lui-même, ce qui m’a sauvé un peu temps. Une fois les règles personnalisées en place, j’étais prêt à partir.

Ajout au flux de travail

Le scanner CLI fait maintenant partie de mon traitement d’intégration continue pendant la nuit sur notre nouveau Accélérateur de gestion d’événements BrightFORUM. Cela n’a pas une grande quantité de code personnalisé et nous avons eu un ensemble très clair de normes et de règles qui sont appliquées au moment de la révision du code, donc je ne m’attendais pas à beaucoup de problèmes, et j’ai été heureux de constater que c’était le Cas. Toutes les violations étaient également de niveau 3 ou inférieur, et j’aurais été assez ennuyé contre moi-même s’il y en avait plus.

Satisfaire le scanner

Effacer les violations était un exercice intéressant. Certains étaient très simples, comme variables locales inutilisées. La plupart du temps, c’était trop zélé de conserver une référence qui n’a pas été utilisée plus tard, mais parfois il s’agissait de véritables restes d’une approche précédente. Comme ils avaient été révisés par le code, je ne vois pas que nous les aurions récupérés manuellement à l’avenir, à moins que nous n’ayons apporté d’autres modifications.

D’autres nécessitaient plus d’efforts, comme cyclomatique ou complexité cognitive, ce qui signifie généralement des méthodes qui essaient d’en faire trop à la fois. Une approche automatisée aide ici car ce n’est pas aux développeurs individuels de décider qu’une méthode est un peu longue ou un peu compliquée, et de convaincre les autres que c’est le cas. Un outil signalant cela enlève toute l’émotion. La correction de ceux-ci a nécessité une refactorisation, ce que je n’ai eu aucun problème à entreprendre car nous avons une excellente couverture de test pour confirmer que je n’ai rien cassé par inadvertance.

Suppression des violations

Cependant, je n’ai pas changé le code dans tous les cas – par exemple, j’avais un potentiel Injection SOQL marqué, car les champs de la requête ont été générés dynamiquement. La chaîne utilisée dans la requête avait été générée à partir des classes de schéma intégrées, quelques lignes plus tôt, il était donc garanti qu’elle ne contenait que des noms de champ valides et il n’y avait aucune chance d’inclure une entrée utilisateur non échappée ou similaire. Je pouvais quand même m’incliner devant le scanner et échapper à la chaîne, mais cela suggérerait à quiconque lisant le code qu’il provenait d’une source non fiable, ce qui n’était pas le cas. Cela m’a donné l’occasion d’essayer une annotation Apex dont je n’avais aucune idée il y a deux semaines – @Supprimer les avertissements.

À partir de la documentation Apex:

Cette annotation ne fait rien dans Apex mais peut être utilisée pour fournir des informations à des outils tiers.

Pour désactiver la violation, j’ai ajouté l’annotation suivante à la méthode qui contenait la requête SOQL:

@SuppressWarnings (‘PMD.ApexSOQLInjection’)

et la violation a disparu. Vous pouvez supprimer plusieurs avertissements en les séparant par des virgules entre les guillemets simples, et vous pouvez également l’appliquer au niveau de la classe pour supprimer tous les avertissements du ou des types spécifiés.

C’est quelque chose qui doit absolument être utilisé avec précaution – une fois que j’ai supprimé les avertissements d’injection SOQL pour une méthode, tout code ajouté qui introduit une véritable vulnérabilité d’injection SOQL ne sera pas détecté. J’ajoute généralement un commentaire pour expliquer pourquoi j’ai supprimé l’avertissement et pour dire que la méthode ne devrait pas être modifiée sans en tenir compte. Je mets également du temps régulier dans mon calendrier pour revoir les annotations de suppression des avertissements et confirmer que je n’ai pas de meilleure approche.

Je n’utiliserais pas cette annotation pour exclure une classe de toutes les règles – cela pourrait être fait, mais ce serait une grande liste de suppressions et il serait plus simple d’exclure la classe de celles traitées. J’ajouterais également un billet indiquant qu’il y a une dette technique à régler dans cette classe, afin que cela ne soit pas oublié et ne me gêne pas à l’avenir.

À emporter

Le principal à retenir de mes dernières semaines d’expérience est que l’analyse automatisée du code conduit à un code plus propre – les choses qui ne sont pas nécessaires ont disparu, les choses qui étaient difficiles à comprendre sont maintenant plus faciles et j’ai des règles personnalisées qui garantissent que les préoccupations sont séparés de manière appropriée. L’inclure dans mon CI garantit que je détecte tous les problèmes dès qu’ils sont ajoutés à la base de code, et je prévois également que l’équipe de développement exécute le scanner avant de pousser son travail. Mis à part l’effort initial pour mettre en place cela, il n’y a pratiquement aucun effort pour beaucoup d’avantages.

Cependant, l’analyse de code statique ne doit pas remplacer les révisions manuelles de code – un outil automatisé est configuré pour rechercher un code / balisage spécifique qui indique des problèmes. Un développeur effectuant une révision du code comprend l’objectif du code et peut déterminer s’il semble faire ce qu’il est censé faire. Les revues de code sont également un excellent moyen de partager des connaissances au sein d’une équipe de développement. En ajoutant l’automatisation, vous évitez aux réviseurs de code de vérifier si chaque variable est utilisée et de déterminer ce qui rend une méthode trop complexe. En utilisant les deux, vous rencontrerez plus de problèmes plus tôt, alors qu’est-ce qu’il ne faut pas aimer?

Ressources





Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Voulez-vous utiliser Pardot à sa capacité maximale et avoir
+ DE LEADS QUALIFIÉS

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer