Startseite/Ressourcen/Engineering
Engineering6 Min. Lesezeit

Ein pragmatischer Leitfaden für Salesforce-Code-Reviews.

Eine praxisnahe Checkliste für das Review von Apex, LWC, Flow-naher Logik und Salesforce-Release-Qualität vor dem Produktiveinsatz.

Kernaussagen
  • Prüfen Sie zuerst Verhalten und Risiko, dann die Formatierung.
  • Bestehen Sie auf bulk-sicherer, testbarer Domain-Logik.
  • Prüfen Sie die operative Sichtbarkeit: Fehler, Logs, Limits und Rollback-Pfade.

Beginnen Sie mit der fachlichen Änderung

Ein Review sollte zuerst beantworten, ob der Code das beabsichtigte Verhalten sicher umsetzt. Reviewer brauchen die User Story, Edge Cases und den Rollback-Plan — nicht nur den Pull Request.

Bulk-Sicherheit ist nicht verhandelbar

Apex muss gegen Governor Limits, Datenvolumen und gemischte Automatisierung geprüft werden. Tests mit einem einzelnen Datensatz reichen nicht. Wir achten auf collection-basierte Logik, selektive Queries, klare Transaktionsgrenzen und vorhersehbares Fehlerhandling.

Tests sollten die Regeln erklären

Gute Tests dokumentieren fachliches Verhalten. Sie decken Positivpfade, Fehlerpfade, Berechtigungen, Datenaufbau und Edge Cases ab, die die Produktion schon einmal gebrochen haben. Coverage ist ein Ergebnis, nicht das Ziel.

Reviewen Sie den Betrieb, nicht nur den Code

Ein Release ist erst fertig, wenn der Support es betreiben kann. Logs, Fehlermeldungen für Nutzer, Feature Toggles, Retry-Pfade und Monitoring sollten vor dem Produktiveinsatz sichtbar sein — besonders bei Integrationen und Revenue-Workflows.

Brauchen Sie das in Ihrer Org?

Überlassen Sie den schweren Teil einem erfahrenen Salesforce-Engineering-Team.

Mit den Entwicklern über dieses Pattern sprechen