Modèles de qualité de code

En savoir plus sur l’optimisation des ressources et des coûts bien archivée → Organisation du code

Cette page de schéma consolidé présente les pratiques de qualité et de maintenabilité du code pour l’optimisation des ressources. Il comprend des conseils sur les décisions de code standard et personnalisé, la gestion technique de la dette, les normes de conception, les pratiques de documentation et la gouvernance. Ces modèles aident à maintenir la vitesse de développement, à réduire les taux de défauts et à assurer la durabilité des solutions à long terme.

Modèles

Où chercher	À quoi ressemble le bien
Performances à l’échelle	✅ Les tests vérifient que les solutions déclaratives remplissent les exigences de performance aux volumes de données projetés. Les tests de chargement en sandbox Full Copy avec des données réalistes confirment l’évolutivité avant le déploiement en production.
Analyse de la maintenabilité	✅ L’analyse TCO compare la charge de maintenance à long terme des approches déclaratives et personnalisées, notamment les efforts de mise à niveau, les exigences de test et les compétences requises pour les futures équipes.
Architecture d’approche mixte	✅ Les solutions combinent des approches déclaratives et programmatiques le cas échéant. Flux orchestre la logique de haut niveau tandis qu’Apex gère les calculs complexes. Les champs de formule calculent de simples dérivations tandis qu’Apex traite les opérations en masse.
Évaluation AppExchange	✅ Avant d’élaborer un code personnalisé, évaluez les packages AppExchange existants qui fournissent des fonctionnalités similaires. Documentez les résultats de l’évaluation, notamment les packages examinés, les écarts dans les capacités et la comparaison du TCO.

Modèles

Où chercher	À quoi ressemble le bien
Visibilité du backlog	✅ Les éléments de dette technique suivis dans le backlog avec des étiquettes claires, le contexte expliquant les raisons pour lesquelles le code doit être amélioré, l’impact commercial de le laisser sans réponse, et l’effort estimé de correction. La dette invisible ne peut pas être priorisée ni gérée.
Amélioration incrémentielle	✅ Règle Boy Scout appliquée pendant le développement de fonctionnalités: laisser le code meilleur que trouvé. Les équipes remédient progressivement à la dette pendant le travail sur les fonctionnalités associées, plutôt que de nécessiter de grands projets de refactorisation dédiés. Les examens de code vérifient les améliorations incrémentielles.
Prévention plutôt que remédiation	✅ Les portes de qualité dans CI/CD appliquent les normes avant que le code n’atteigne la production. Scanner de code, ApexGuru et métriques de complexité intégrées dans la validation de requête d’extraction. Les problèmes de blocage empêchent la fusion jusqu’à leur résolution.

Anti-modèles

Où chercher	À quoi ressemble mal
Gestion du backlog	⚠️ Dette technique reconnue verbalement mais jamais suivie en arriéré. Aucune visibilité sur l’accumulation de dettes. La remise en état de la dette toujours différée au profit du travail de fond. Velocity décline progressivement, les équipes ne peuvent pas expliquer pourquoi.
Contournement de la porte de qualité	⚠️ Portes de qualité CI/CD fréquemment contournées sous la pression du planning avec l’intention de les fixer plus tard. “Plus tard” n’arrive jamais. Les échecs du lecteur de code marqués comme des problèmes connus et ignorés. Seuils de complexité relevés pour tenir compte des mauvaises implémentations.
Aucune capacité de dépollution	⚠️ 100 % de la capacité de sprint allouée au travail de fonctionnalité avec une capacité nulle pour la remise en état technique de la dette. La dette s’accumule indéfiniment. Les grands projets de refactorisation requis tous les 18-24 mois consomment des trimestres entiers.
Dette de configuration	⚠️ Les types de métadonnées personnalisées et les paramètres personnalisés s’accumulent sans nettoyage. La configuration inutilisée persiste indéfiniment. La production a 50 enregistrements de métadonnées, seuls 12 sont réellement utilisés. Aucune documentation expliquant l’objet des valeurs de configuration.

Modèles

Où chercher	À quoi ressemble le bien
Architecture de déclenchement	✅ Modèle de déclencheur appliqué de façon cohérente : Les déclencheurs légers délèguent aux classes de gestionnaire, les classes de gestionnaire organisent la logique par contexte de déclencheur (avant l’insertion, après la mise à jour), les noms de méthode clairs révèlent l’objet. Aucune logique métier dans les fichiers de déclencheur eux-mêmes.
Implémentation de la couche de service	✅ Logique métier encapsulée dans des classes de service séparées des contrôleurs, des déclencheurs et des points d’entrée par lot. Classes de service réutilisables à travers plusieurs points d’entrée sans duplication. Convention de nommage claire (AccountService, OrderProcessor).
Modèle de sélecteur	✅ Requêtes SOQL centralisées dans des classes de sélecteur par objet (AccountSelector, OpportunitySelector). Les méthodes de sélection renvoient des ensembles de champs cohérents. Les modifications de l’optimisation LDV s’appliquent une fois, affectant toutes les requêtes.
Modèle de référentiel	✅ Accès aux données abstrait derrière des interfaces permettant de tester avec des sources de données fictives. Les implémentations de référentiel encapsulent les stratégies de construction, de mise en cache et d’optimisation des requêtes. La logique métier dépend des interfaces de référentiel, pas des implémentations concrètes.
Normes de conception des composants	✅ Les composants Web Lightning suivent le principe de responsabilité unique, exposent les propriétés pour la configuration, émettent des événements pour la communication parente, conçus pour la composition et la réutilisation. Bibliothèque de composants documentée avec des exemples d’utilisation.
Organisation du code	✅ La structure logique du package regroupe les classes associées. Séparation claire entre logique de domaine, accès aux données, points de terminaison d’API et adaptateurs d’intégration. Les dépendances de package sont transmises dans une direction unique.

Anti-modèles

Où chercher	À quoi ressemble mal
Déclencheurs	⚠️ Toute logique métier incorporée directement dans des fichiers de déclencheur avec des conditionnels profondément imbriqués, sans séparation des préoccupations, sans classes de gestionnaire. Plus de 300 fichiers de déclencheur de ligne mêlant validation, logique métier et appels d’intégration. Impossible de tester efficacement.
Requête en boucle	⚠️ Requêtes SOQL exécutées dans des boucles d’itération. Fonctionne avec de petits volumes de données, mais enfreint la limite de 100 requêtes SOQL lors du traitement d’opérations en masse. Découvert uniquement lorsque les déclencheurs sont activés lors de chargements de données en masse en production.
DML en boucle	⚠️ instructions DML (insérer, mettre à jour, supprimer) exécutées dans des boucles d’itération. Enfreint la limite de 150 instructions DML avec des opérations en masse. Chaque enregistrement traite dans une transaction de base de données séparée plutôt que dans un traitement en masse efficace.

Modèles

Où chercher	À quoi ressemble le bien
Enregistrements de décision d’architecture	✅ Décisions architecturales importantes documentées dans les ADR stockés dans le contrôle de version. Les ADR capturent le contexte (moteurs métiers, contraintes techniques), la décision (ce qui a été choisi), les solutions envisagées (pourquoi elles ont été rejetées) et les conséquences (compromis, conditions de réexamen).