Avis d’experts de Salesforce sur les outils et processus d’examen du code pour les modifications du code Apex

Au cours d’une conversation qui s’est tenue récemment, lors d’un événement du Salesforce World Tour, les outils et processus d’examen du code pour les modifications du code Apex ont été abordés. Les examens du code garantissent que plusieurs membres de votre équipe aient au moins vu chaque ligne de code de votre application Salesforce. Les relecteurs s’intéressent à plusieurs aspects. Ils peuvent se pencher sur les erreurs de logique et la qualité du code, les critères d’acceptation non remplis et la couverture des tests. Pour faire simple, avec l’examen du code, les équipes utilisant Salesforce peuvent être tranquilles. Un code de meilleure qualité, une meilleure compréhension de base par les équipes, une sécurité renforcée et, de façon générale, une plus grande efficacité sont quelques-uns des avantages de ces examens.

Cependant, le but de cet article n’est pas seulement de faire comprendre les avantages des examens du code, mais aussi de partager avec les administrateurs et les développeurs plusieurs avis d’experts de Salesforce sur les outils et processus d’examen du code pour les modifications du code Apex. Nous avons posé une question à des gourous de Salesforce et voici ce qu’ils nous ont répondu.

La première réponse est celle d’Enrico Murru, Solution & Technical Architect chez WebResults (groupe d’ingénierie) et créateur d’ORGanizer for Salesforce. Enrico est un MVP de Salesforce qui anime un blog génial pour tous les professionnels informatiques utilisant Salesforce.

Sur le blog d’Enrico, dans son article Salesforce/VCS, The team factor or how a business analyst can affect the overall delivery speed (« Le facteur équipe ou comment un analyste peut affecter la vitesse de livraison globale »), il aborde le sujet des examens du code : « faire examiner votre développement présente des avantages trop nombreux pour s’en passer. Cela vous évite d’introduire une mauvaise conception qui handicape le projet à long terme au profit d’une réussite à court terme. Les renseignements exploitables sont partagés au sein de l’équipe si bien qu’il n’y a pas de surprises. Sans oublier que les retours font de vous un meilleur développeur. »

Voici la réponse d’Enrico Murru à notre question, « quels sont vos outils et processus d’examen du code bien documentés préférés pour les modifications du code Apex ? »

Quand on me parle des examens du code, je repense à mes débuts en tant que programmeur (Apex), il y a environ 10 ans. À l’époque, nous étions une petite entreprise, dotée de quelques développeurs très compétents, mais qui n’avait ni le temps ni le budget à consacrer aux examens de la qualité du code, si bien que les seuls examens dont je bénéficiais venaient de la programmation en binôme avec des développeurs expérimentés. Les projets étaient beaucoup trop importants pour nous, mais nous n’avions pas peur, et nous avons acquis un haut niveau de professionnalisme et de compétence, avec une certaine dose d’ingéniosité.

Au fil du temps, nous avons grandi (plus de 10 fois en 10 ans !) et compris que nous devions intégrer des examens de la qualité du code et de la configuration à nos projets. Nous avons commencé à créer un outil en interne pour :

• effectuer des calculs et générer des notifications de façon automatique concernant la couverture des tests Apex,
• inspecter quotidiennement les nouveaux déclencheurs, classes, pages, éléments Lightning, métadonnées pour voir s’ils respectaient les conventions de nommage (les jeunes développeurs faisant parfois preuve d’une grande fantaisie dans le choix des noms),
• suivre les tâches de façon asynchrone et
• générer des notifications concernant les erreurs des tâches Apex.

Cependant, cela ne suffisait pas : l’inspection manuelle des validations était coûteuse et faillible. Nous avions besoin d’une analyse automatique du code pour nous assister dans les tâches quotidiennes et répétitives.

Selon le type et la taille du projet, nous utilisions Checkmarx, la solution open source PMD ou un nouveau venu intelligent et facile à utiliser de l’écosystème Salesforce, Clayton

L’analyse automatique du code a permis de faciliter la vie des programmeurs, de réduire notre stress qui a atteint des niveaux acceptables (même si je pense que, pour les programmeurs comme moi, le stress est un carburant) et de nous concentrer sur le meilleur aspect de la programmation, la créativité !

Je ne peux pas vous indiquer quelle est la meilleure façon d’instaurer l’analyse du code dans votre société, car cela dépend de l’expérience des programmeurs ainsi que de la taille et du type de projet. Cependant, si je peux vous faire une suggestion, c’est simplement de le faire de la façon que vous souhaitez mais de le faire pour promouvoir une bonne culture de programmation.

 

La réponse suivante nous vient d’Abhilasha Singh. Abhilasha est une MVP de Salesforce et une développeuse Salesforce chez Dazeworks. Elle a un compte Twitter actif sur lequel elle partage nombre de bons conseils sur le monde du développement Salesforce.

Le développement Salesforce est unique parce qu’il se fait avec des clics plutôt que du code. Les examens du code sont tout de même bénéfiques aux fonctionnalités créées via l’IU de Salesforce. Git est l’un des meilleurs outils d’examen du code. L’examen du code fonctionne le mieux lorsqu’il est possible de créer des branches de votre code distinctes de la branche principale. Avec Git, c’est très simple à faire. Git permet aussi de comparer très facilement une nouvelle branche à une branche précédente.

Voici quelques outils que je recommande d’utiliser pour les modifications du code Apex :

1. Les ensembles de modifications (« change sets ») : Ils sont utiles lorsque vous devez migrer les métadonnées entre des organisations liées. Pour utiliser les ensembles de modifications, vous avez besoin d’une connexion de déploiement entre les organisations.
2. Developer Console : Il s’agit d’un environnement de développement par navigateur utilisé pour créer, tester et déboguer une application dans une organisation Salesforce. Il permet également d’écrire et de modifier des requêtes SOQL et SOSL.
3. Workbench : C’est l’une des suites d’outils en ligne conçues pour permettre aux administrateurs et aux développeurs utilisant Salesforce d’interagir avec une organisation à l’aide des API https://Force.com. Grâce à Workbench, les administrateurs et les développeurs peuvent facilement visualiser leurs données dans l’organisation. Ils peuvent également effectuer des requêtes SOQL et SOSL, tester, déployer, paramétrer les sessions et résoudre les problèmes de leurs propres applications.
4. L’EDI https://Force.com : Pour utiliser cet EDI, il faut d’abord installer Eclipse (un outil de développement utilisé par tous types de développeurs à travers le monde), puis l’EDI https://Force.com. Basé sur la plateforme Eclipse et conçu à partir de l’API Tooling, l’EDI https://Force.com fournit un environnement confortable aux programmeurs qui connaissent les environnements de développement intégrés. Il vous permet de programmer, compiler, tester, créer des packages et déployer, tout cela depuis l’EDI.
5. Ant Migration Tool : Ce toolkit est similaire à l’EDI Eclipse, si ce n’est qu’il est destiné à être utilisé comme un outil de déploiement Salesforce que l’on peut écrire à l’avance et automatiser sans interagir avec l’IU. Cela fait d’Ant Migration Tool un toolkit idéal pour l’intégration continue et le déploiement automatique.
   

La troisième réponse vient de Paarth Jolly, CEO et Fondateur d’YVExperts. Paarth est un blogueur actif que l’on peut retrouver sur et We Both Code ainsi qu’un leader de la communauté Salesforce depuis 2013. Il travaille avec Salesforce.com pour développer des applications de vente et de service dans le cloud. Celles-ci comprennent des fonctionnalités aussi bien standard que personnalisées. Voici ce que Paarth a souhaité ajouter à notre article :

L’examen du code est un aspect important de la mise en œuvre de Salesforce. Parfois, nous écrivons du code qui fonctionne parfaitement d’un point de vue métier mais comporte une erreur de syntaxe susceptible de causer des problèmes lors de la promotion du package ou du code vers l’AppExchange. Deux processus clés des examens du code sont l’optimisation du code et l’utilisation des directives de programmation sécurisée fournies par Salesforce.

Optimisation du code

L’optimisation du code est la première étape une fois la programmation terminée. Bien que Salesforce soit une plateforme géniale, ses limites sont nombreuses. Les développeurs doivent toujours garder à l’esprit les limites du système de gestion et essayer d’écrire du code de façon dynamique afin de pouvoir l’utiliser en divers endroits à l’avenir.

Quand je développe et écris du code, je me concentre toujours sur les aspects suivants :

1. éviter les requêtes SOQL ou les déclarations LMD à l’intérieur des boucles for,
2. utiliser l’API Bulk et les déclencheurs dans le code,
3. utiliser l’API Bulk avec les méthodes helper,
4. utiliser des collections, rationaliser les requêtes et améliorer l’efficacité des boucles for (utiliser des mappages et éviter les boucles for et while imbriquées),
5. écrire de nombreux commentaires facilement compréhensibles par un autre développeur,
6. utiliser les méthodes des limites Apex pour éviter d’atteindre les limites du gouverneur et

Utiliser les directives de programmation sécurisée.

Des directives de programmation sécurisée sont essentielles à tout développeur. Le guide complet fourni par Salesforce vous explique comment vous assurer que votre code ou package passe avec succès un processus d’examen de la sécurité afin de rendre votre application disponible sur l’AppExchange.

Vient ensuite Meighan Brodkey, Senior Consultant Community Specialist chez GearsCRM et leader du groupe d’utilisatrices Seattle Women in Tech. Depuis 2008, Meighan partage son expérience avec Salesforce ainsi que ses conseils, astuces et bonnes pratiques avec les administrateurs de tous horizons sur son blog. Voici ce que Meighan nous a répondu.

Il est essentiel de veiller à un bon équilibre des pouvoirs dans un projet. Pour chaque projet, je conserve une sauvegarde des métadonnées au fur et à mesure de la construction pour disposer d’une sorte de gestion des versions. Il est ainsi possible de s’y référer en cas de besoin et de s’assurer que toutes les modifications sont suivies et examinées avant le déploiement.

Lors de la résolution des problèmes ou de l’amélioration du code, des bugs peuvent survenir ; ces sauvegardes permettent de consulter la version précédente pour voir ce qui fonctionnait afin de trouver où les problèmes ont commencé. Vous devriez inclure non seulement votre code, comme les éléments Lightning et les classes, mais aussi l’ensemble des métadonnées, objets, flux… afin d’être toujours en mesure de revenir en arrière au lieu de recommencer à zéro. Il est important de conserver les sauvegardes en un seul endroit (GitHub, BitBucket, etc.) pour permettre à tout le monde de partir de la même branche principale pour ajouter une branche de fonctionnalité ou une branche unique avec laquelle tout le monde travaille. En fusionnant les éléments avec la branche principale au fur et à mesure de leur validation, vous vous assurerez de bien séparer le travail validé du travail en cours.

Le pull request (demande d’intégration d’une modification à la branche principale) est un très bon moyen d’y parvenir : chaque développeur soumet son travail une fois celui-ci terminé. Cependant, cette précaution ne suffit pas. Demander à un développeur qui n’a pas écrit le code ou à l’AT d’un projet d’effectuer un examen du code de chaque item vous garantit de bénéficier d’une seconde paire d’yeux et de ne pas rater les bonnes pratiques or une spécification. Même en tant qu’architecte des projets, je demande à un développeur d’examiner mon code pour m’assurer de n’avoir rien raté.

La cinquième réponse est celle d’Abhi Tripathi, Développeur Salesforce chez Homestar Financial Corporation et évangéliste de Salesforce. Sur son blog, Cloudyabhi, Abhi aborde des sujets comme les bonnes pratiques de Salesforce et dispense des conseils aux développeurs et aux administrateurs pour les aider à faire leur travail. Voici les suggestions d’Abhi en matière d’outils et de processus d’examen du code pour les modifications du code Apex.

Salesforce est une plateforme géniale. Elle dispose d’une communauté incroyable qui aide ses développeurs et ses administrateurs à progresser dans leur carrière. Grâce aux communautés de Salesforce, nous avons accès à de nombreux outils géniaux qui facilitent la vie des développeurs et des administrateurs. L’une des pratiques importantes en matière de mise en œuvre des projets est l’examen du code, car il garantit à votre équipe une visibilité sur le code de vos applications. Voici quelques outils que j’ai trouvés utiles pour examiner le code Apex :

1 Checkmarx : Checkmarx est un très bon outil pour sécuriser votre code Apex et Visualforce. Il s’intègre facilement à votre organisation Salesforce et vous fournit un rapport complet. Ce rapport contient les points de modifications et indique ce qu’il faut modifier. Je recommande personnellement cet outil pour la sécurité de votre application et de votre code.

2. Codescan :outil d’analyse du code pour Salesforce. Cet outil de l’AppExchange est très facile à utiliser et à installer dans votre organisation Salesforce. Il aide les développeurs à identifier les bugs et à améliorer la qualité du code. Cet outil dispose d’une IU incroyable pour analyser le code Apex de votre organisation.
3. PMD, analyseur du code source :L’utilisation de PMD est également recommandée pour votre code Apex, car cet outil détecte facilement les défauts de votre code Apex et fournit des renseignements exploitables sur la façon de les éliminer. Il recherche les variables non utilisées, les blocs catch vides et les objets dont la création est superflue. Cet outil aide vraiment à nettoyer le code Apex, Javascript ou Visualforce.
4. Clayton :Clayton est un outil de nouvelle génération qui fait tout le nécessaire pour que votre application Salesforce soit la meilleure. Il est très facile à configurer et à utiliser. Clayton s’intègre à vos dépôts de code et applique des normes de qualité et de sécurité à travers votre organisation, à tout moment, alors que vous construisez vos applications. Il vous fournit des analyses non seulement sur le code Apex mais également sur les éléments Lightning.
5. Code Climate: Cet outil automatise l’examen du code, notamment au niveau de la couverture des tests et de la maintenabilité, afin de vous faire gagner du temps. Il vous fournit des retours en temps réel concernant votre code pour vous aider à maintenir un bon code au fur et à mesure. Il apporte également une couverture des tests ligne par ligne intégrée à votre dépôt Github, effectue des analyses en local et facilite la gestion d’équipe grâce à une visibilité sur les permissions.

La dernière réponse est celle d’Alex Sutherland. Alex est un Salesforce Solution Lead Architect disposant d’une grande expérience de la conception et de la livraison de solutions d’entreprise uniques sur la plateforme Salesforce pour le secteur public. Suivez Alex sur Twitter pour obtenir des renseignements exploitables partagés par un technologue, stratège et partisan de Salesforce. Voici ce qu’Alex nous a répondu concernant son processus d’examen du code.

This block renders a quote for the post drawn from the post's custom fields. Modify the quote below the content editor in the Quote fields.

L’ensemble d’outils le plus important pour suivre et examiner les modifications des métadonnées et du code est une solution robuste de contrôle des versions distribué qui dispose d’une IU en ligne comme Github, Gitlab ou BitBucket. J’utilise actuellement Github et j’ai utilisé BitBucket par le passé avec d’autres projets. Utiliser un système de dépôt Git qui dispose d’une IU en ligne vous permet de suivre visuellement ce qui se passe dans le dépôt pour l’ensemble des branches, validations et différences du code.  Être en mesure de comparer visuellement les différences du code et des métadonnées présente un avantage énorme. Davantage de clients de Salesforce devraient adopter des systèmes de contrôle de version distribués, notamment ceux qui comptent mettre en œuvre Salesforce DX dans leur processus de développement.

 

En plus de Git, dans une équipe de développement collaboratif, il est absolument essentiel de disposer d’un environnement de développement qui facilite la validation des modifications dans le dépôt par les membres de l’équipe. Mon outil préféré est actuellement Illuminated Cloud, un plugin pour les EDI JetBrains IntelliJ et WebStorm. Une intégration étroite au dépôt Git augmente de façon significative la cohérence et la qualité des validations dans le dépôt par l’équipe de développement.

 

Je suggérerais enfin d’utiliser un outil d’analyse du code statique commeCheckmarx, PMD ou Panaya. L’analyse du code statique aide à identifier les motifs de conception problématiques et les défauts de sécurité du code. Détecter ces lacunes dans le code en amont du cycle de développement permet d’augmenter les chances de les résoudre tant que cela est encore rentable.

 

Enfin, je pense qu’il est crucial que la communauté des développeurs Salesforce reconnaisse l’importance de la couverture des tests unitaires et les avantages des scénarios et suites de tests robustes. Certains membres de la communauté Salesforce sont mécontents de devoir écrire des tests unitaires pour leur code afin de le déployer en production. Cependant, ils sous-estiment la valeur des tests unitaires appropriés ainsi que les efforts et dépenses que ces tests peuvent leur faire économiser par la suite s’ils les mettent correctement en œuvre. Les tests unitaires devraient constituer l’étape finale permettant de s’assurer que les modifications de l’environnement produisent les résultats attendus. Ils sont essentiels à un processus de gestion des versions robuste.

Nous avons également posé cette question à notre propre experte Salesforce, Ira Dizengof. Ira a ajouté un dernier élément à un processus d’examen du code Salesforce réussi : l’analyse d’impact pour toute modification que l’on souhaite apporter au code. L’analyse d’impact permet aux analystes, développeurs et administrateurs de comprendre les répercussions de l’ensemble du code développé avant de commencer à développer quoi que ce soit. En affichant une liste exhaustive des éléments impactés ainsi que leurs statistiques d’utilisation, les équipes peuvent mieux hiérarchiser les modifications.

Ira s’appuie sur Panaya Release Dynamix pour Salesforce pour garantir non seulement la qualité du code mais également celle des versions. Panaya Release Dynamix offre aux équipes une visibilité et un contrôle en temps réel sur l’ensemble des projets et versions de SFDC. Grâce à un tableau de bord des risques détaillé, les équipes bénéficient d’une vision complète du projet ou de la version et de ses risques, notamment au niveau de la progression des spécifications, du développement, de l’étendue du plan de test ainsi que de la progression de l’exécution des défauts et des tests.