Vérification des personnalisations de votre organisation
Objectifs de formation
Une fois cette unité terminée, vous pourrez :
- Identifier la valeur commerciale et technologique de l’évaluation de l’état actuel
- Identifier les éléments à rechercher dans une base de code
- Identifier comment examiner les processus et la personnalisation déclarative
Dans un ouvrage intitulé La vie de raison, le poète et philosophe George Santayana écrivait : « Ceux qui ne peuvent se rappeler le passé sont condamnés à le répéter ». Il en est de même pour les équipes qui créent des applications. Pour réussir, vous devez prendre le temps d’identifier ce qui a été créé dans votre organisation (ainsi que les raisons de ces créations et les normes suivies).
Si vous entamez les efforts d’adoption en examinant l’état actuel de votre organisation, vous serez en mesure d’identifier clairement les problèmes avant de commencer à apporter des modifications. C’est le cas, par exemple, de l’identification de la dette technique, qui désigne les décisions d’implémentation qui étaient logiques à l’origine, mais qui empêchent à présent d’innover. Vous pouvez également trouver des moyens de mieux dialoguer avec les bonnes parties prenantes et apporter des ajustements à vos équipes avant que les processus ne soient trop avancés.
Examiner la façon dont vous travaillez avant de commencer à la modifier présente de nombreux avantages pour vos équipes de technologie et de livraison d’applications. Cela peut également vous donner l’occasion d’identifier quels problèmes ou frustrations dans vos systèmes actuels sont engendrés par des outils ou des technologies obsolètes, et quels problèmes ont des origines humaines. Ces problèmes d’origine humaine sont ceux que vous devez absolument résoudre avant d’essayer d’adopter une nouvelle technologie ou fonctionnalité.
Alors, comment commencer à examiner votre organisation telle qu’elle est aujourd’hui ?
Examen de votre code
Il peut sembler intimidant d’examiner votre base de code. Surtout si vous êtes nouveau dans une organisation ou si votre organisation a beaucoup de code. Mais comprendre comment les différents éléments de votre organisation sont liés les uns aux autres est essentiel et une condition sine qua non pour identifier la manière de commencer à décomposer votre organisation en unités plus précises et pertinentes.
Alors, que rechercher dans votre code ?
Type de code | Que rechercher | Questions à poser |
|---|---|---|
Triggers | 1. Modèles de déclenchement 2. Logique de déclenchement | Votre organisation a-t-elle un seul déclencheur par objet ? Une logique métier ou d’application est-elle écrite directement dans un déclencheur ? Les déclencheurs « transfèrent-ils » la logique ou la fonctionnalité à d’autres classes (c’est-à-dire aux gestionnaires de déclencheur) ? |
Classes Apex | 1. Conventions de nommage 2. Commentaires 3. Version d’API | Les classes Apex utilisent-elles des préfixes communs voire des espaces de noms pour regrouper les unités de code ? Les classes ont-elles des noms similaires, reposant sur la fonctionnalité ? Le but et l’auteur du code sont-ils consignés dans les commentaires ? Les classes sont-elles accompagnées de commentaires qui aident à clarifier leur fonction ? Quelles versions d’API les classes utilisent-elles ? |
Tests Apex | 1. Modèles/unités de test 2. Couverture de code 3. Gestion des données test | Comment les tests sont-ils liés au reste du code ? Chaque classe a-t-elle son propre test ? Vos tests sont-ils organisés en groupes fonctionnels ? Y a-t-il des parties de votre base de code qui ne sont pas couvertes par les tests ? Vos tests dépendent-ils de ressources statiques ou de facteurs de données communs ? L’un de vos tests utilise-t-il l’annotation « seeAllData=True » ou s’exécute-t-il sur une version d’API antérieure à 24 ? |
Composants et événements Lightning | 1. Conventions de nommage 2. Commentaires 3. Les contrôleurs Apex 4. Version d’API | Les composants utilisent-ils des préfixes communs voire des espaces de noms pour créer les groupes ? Les composants ont-ils des noms clairs, liés à la fonctionnalité ? Les événements Lightning sont-ils destinés à être des événements d’application ou des événements de composant ? Le but et l’auteur des composants et des événements sont-ils clairement consignés dans les commentaires ou les fichiers de documentation Aura ? Les composants utilisent-ils des contrôleurs Apex ? Quelles versions d’API les composants et les événements utilisent-ils ? |
Visualforce | 1. Conventions de nommage 2. Commentaires 3. Les contrôleurs Apex 4. Version d’API | Les composants et les pages Visualforce utilisent-ils des préfixes communs, voire des espaces de noms pour créer les groupes ? Les pages ont-elles des noms clairs, liés à la fonctionnalité ? Les pages Visualforce utilisent-elles des contrôleurs Apex ? Quelles versions d’API les pages utilisent-elles ? Les pages sont-elles utilisées avec des modèles d’e-mail ? |
Ces éléments vous aident à identifier les modèles dans le code de votre organisation, mais ces techniques ne vous aideront peut-être pas à comprendre tous les éléments de votre base de code. Par ailleurs, si votre base de code ne semble pas être organisée de manière cohérente, vous devrez peut-être essayer d’autres méthodes pour découvrir comment le code de votre organisation est connecté.
C’est là que la nouvelle API de dépendance peut vous aider. En exécutant de nouveaux types de requêtes, vous pouvez identifier comment votre code et vos métadonnées sont organisés. Vous pouvez, par exemple, examiner un composant Lightning sur une page donnée ou bien le contrôleur Apex d’une page Visualforce spécifique, puis retracer tous les autres éléments de métadonnées qui sont connectés d’une manière ou d’une autre au composant Lightning ou au contrôleur Apex. Vous pouvez également utiliser ces requêtes pour identifier des éléments de métadonnées qui ne sont plus utilisés et décider s’ils peuvent être supprimés en toute sécurité.
Examen de vos processus et de votre personnalisation déclarative
Alors, qu’en est-il des personnalisations déclaratives que vous avez effectuées dans votre organisation ? Comment pouvez-vous examiner des éléments que vous avez créés avec des clics et non du code ?
Une solution à votre disposition est d’utiliser Salesforce Optimizer. Cet outil recommande des façons d’améliorer certaines fonctionnalités de votre implémentation Salesforce. Après avoir consulté votre rapport Optimizer, vous pouvez examiner plus en détail les processus et les personnalisations déclaratives de votre organisation.
Que devez-vous rechercher ?
Type de personnalisation | Que rechercher | Questions à poser |
|---|---|---|
Flux/flux visuel | 1. Conventions de nommage 2. Modèles associés aux objets 3. Versions actives/inactives 4. Logique de flux 5. Écrans de flux | Les flux utilisent-ils des préfixes ou des noms similaires pour créer les groupes ? Les flux ont-ils des noms clairement liés à la fonctionnalité ? Les flux ont-ils des descriptions claires et à jour ? Avec quel(s) objet(s) un flux interagit-il ? Quelle est la relation entre les flux ou versions de flux inactifs et les flux actifs ? Les flux orientent-ils des fonctionnalités communes dans des flux secondaires, des actions invocables ou des actions rapides ? Si les flux ont des écrans, reposent-ils sur des composants Lightning ? Les écrans dépendent-ils de certains objets et champs ? Existe-t-il des automatisations obsolètes qui doivent être transformées en flux ? |
Objets et champs | 1. Conventions de nommage 2. Types d'enregistrement 3. Présentations de page 4. Autorisations 5. Remplacements d’action | Des objets personnalisés ont-ils été créés pour dupliquer le comportement d’un objet standard ? Plusieurs unités commerciales utilisent-elles les mêmes objets ou champs ? La logique métier et les validations sont-elles différenciées selon les types d’enregistrements ? Les objets et champs ont-ils des descriptions claires et à jour ? |
Nous vous recommandons de définir clairement l’état actuel de vos processus et personnalisations déclaratives. Si vous constatez que votre organisation n’est pas aussi organisée que vous le souhaiteriez, ce n’est pas grave. Pour y remédier, ciblez les domaines où votre équipe peut travailler pour améliorer la qualité et établissez des normes qui peuvent vous aider à protéger l’intégrité de votre organisation à l’avenir. Vous pouvez également identifier les projets que vous souhaitez mener à bien en premier, pour nettoyer des parties de votre organisation.
Restez avec nous
Nous ajouterons dans les mois à venir plus de ressources et d’exercices pratiques. Vous aurez la possibilité d’explorer le démêlage des métadonnées, de créer des packages et d’en savoir plus sur la gestion des packages déverrouillés.
Ressources
- Article du BA Times : Qu’en est-il de l’état actuel ?
- Article d’Atlassian : Comment échapper à la spirale de la dette technique
- Publication sur le blog : Remboursement de votre dette technique
- Aide Salesforce : Fonctionnalités évaluées dans Salesforce Optimizer