Accueil/Ressources/Ingénierie
Ingénierie6 min de lecture

Un guide pragmatique des revues de code Salesforce.

Une checklist pratique pour relire l'Apex, les LWC, la logique liée aux Flows et la qualité des releases Salesforce avant la production.

Points clés
  • Examinez le comportement et le risque avant le formatage.
  • Exigez une logique métier testable et sûre en traitement de masse.
  • Vérifiez la visibilité opérationnelle : erreurs, logs, limites et chemins de rollback.

Partez du changement métier

Une revue doit d'abord établir si le code implémente le comportement attendu de façon sûre. Les relecteurs ont besoin de la user story, des cas limites et du plan de rollback, pas seulement de la pull request.

La robustesse en masse n'est pas négociable

L'Apex doit être relu au regard des governor limits, des volumes de données et des automatisations combinées. Les tests sur un seul enregistrement ne suffisent pas. Nous recherchons une logique basée sur des collections, des requêtes sélectives, des frontières transactionnelles claires et une gestion d'erreurs prévisible.

Les tests doivent expliquer les règles

De bons tests documentent le comportement métier. Ils couvrent les chemins nominaux, les chemins d'échec, les permissions, la préparation des données et les cas limites qui ont déjà cassé la production. La couverture est un résultat, pas un objectif.

Relisez l'opérationnel, pas seulement le code

Une release n'est terminée que lorsque le support peut l'exploiter. Logs, erreurs visibles par l'utilisateur, feature toggles, mécanismes de retry et monitoring doivent être en place avant la production, en particulier pour les intégrations et les workflows de revenus.

Besoin de cela dans votre org ?

Confiez la partie difficile à une équipe d'ingénierie Salesforce senior.

Parler de ce pattern avec nos ingénieurs