Code-Qualitätsmuster

Erfahren Sie mehr über die gut durchdachte Ressourcen- und Kostenoptimierung → Codeorganisation

Auf dieser Seite mit konsolidierten Mustern werden die Vorgehensweisen zur Code-Qualität und Wartbarkeit für die Ressourcenoptimierung beschrieben. Sie enthält Anleitungen zu Entscheidungen im Vergleich zu benutzerdefiniertem Code, technischer Schuldenverwaltung, Designstandards, Dokumentationspraktiken und Governance. Diese Muster tragen dazu bei, die Entwicklungsgeschwindigkeit aufrechtzuerhalten, Fehlerraten zu reduzieren und die Nachhaltigkeit langfristiger Lösungen zu ermöglichen.

Muster

Wohin schauen	Wie gut aussieht
Leistung im Maßstab	✅ Durch Tests wird überprüft, ob deklarative Lösungen die Leistungsanforderungen bei prognostizierten Datenmengen erfüllen. Laden Sie Tests in der Full Copy Sandbox mit realistischen Daten, um die Skalierbarkeit vor der Produktionsbereitstellung zu bestätigen.
Wartungsanalyse	✅ Die TCO-Analyse vergleicht die langfristige Wartungslast deklarativer und benutzerdefinierter Ansätze, einschließlich Upgrade-Aufwand, Testanforderungen und Fertigkeitsanforderungen für künftige Teams.
Architektur mit gemischtem Ansatz	✅ Lösungen kombinieren deklarative und programmgesteuerte Ansätze, wo dies angemessen ist. Flow orchestriert Logik auf höchster Ebene, während Apex komplexe Berechnungen verarbeitet. Formelfelder berechnen einfache Ableitungen, während Apex Massenvorgänge verarbeitet.
AppExchange-Auswertung	✅ Bevor Sie benutzerdefinierten Code erstellen, sollten Sie vorhandene AppExchange-Pakete mit ähnlichen Funktionen auswerten. Dokumentauswertungsergebnisse, einschließlich überprüfter Pakete, Funktionslücken und TCO-Vergleich.

Muster

Wohin schauen	Wie gut aussieht
Rückstandssichtbarkeit	✅ Technische Schuldenposten, die im Rückstand verfolgt werden, mit eindeutigen Bezeichnungen, Kontext, in dem erläutert wird, warum Code verbessert werden muss, Geschäftsauswirkungen, wenn er nicht bearbeitet wird, und geschätzter Sanierungsaufwand. Unsichtbare Schulden können nicht priorisiert oder verwaltet werden.
Inkrementelle Verbesserung	✅ Pfadfinderregel, die während der Funktionsentwicklung angewendet wurde: Code besser lassen als gefunden. Teams beheben Schulden während der Arbeit an zugehörigen Funktionen inkrementell, statt dass große dedizierte Refaktoring-Projekte erforderlich sind. Codeüberprüfungen bestätigen inkrementelle Verbesserungen.
Prävention vor Sanierung	✅ Qualitäts-Gate in CI/CD erzwingen Standards, bevor Code die Produktion erreicht. Code-Scanner, ApexGuru und Komplexitätskennzahlen, die in die Validierung von Pull-Anforderungen integriert sind. Blockierungsprobleme verhindern die Zusammenführung, bis sie gelöst sind.

Antimuster

Wohin schauen	Wie schlecht sieht
Rückstandsverwaltung	⚠️ Technische Schulden wurden mündlich bestätigt, aber nie im Rückstand verfolgt. Kein Einblick in die Schuldenanhäufung. Die Schuldensanierung wurde immer zugunsten der Funktion zurückgestellt. Velocity nimmt allmählich ab, Teams können nicht erklären, warum.
Qualitätstorumgehung	⚠️ CI/CD-Qualitäts-Gatter werden häufig unter Plandruck umgangen, um sie später zu reparieren. “Später” passiert nie. Code Scanner-Fehler wurden als bekannte Probleme markiert und ignoriert. Angehobene Komplexitätsschwellenwerte für schlechte Implementierungen.
Keine Sanierungskapazität	⚠️ 100 % der Sprint-Kapazität für Funktionsarbeiten mit null Kapazität für die technische Schuldensanierung. Schulden häufen sich unbegrenzt an. Große Refaktorisierungsprojekte, die alle 18-24 Monate erforderlich sind und ganze Quartale in Anspruch nehmen.
Konfigurationsschulden	⚠️ Benutzerdefinierte Metadatentypen und benutzerdefinierte Einstellungen werden ohne Bereinigung kumuliert. Die nicht verwendete Konfiguration wird unbegrenzt beibehalten. Die Produktion verfügt über 50 Metadatensätze, von denen nur 12 tatsächlich verwendet werden. Keine Dokumentation, in der der Zweck von Konfigurationswerten erläutert wird.

Muster

Wohin schauen	Wie gut aussieht
Auslöserarchitektur	✅ Auslöser-Handler-Muster einheitlich angewendet: dünne Auslöser werden an Handler-Klassen delegiert, Handler-Klassen organisieren Logik nach Auslöserkontext (vor dem Einfügen, nach der Aktualisierung), eindeutige Methodennamen verraten den Zweck. Keine Geschäftslogik in Auslöserdateien selbst.
Implementierung der Serviceebene	✅ Geschäftslogik, die in Serviceklassen gekapselt ist, die von Steuerfeldern, Auslösern und Batch-Eingangspunkten getrennt sind. Serviceklassen können ohne Duplikate über mehrere Eintrittspunkte hinweg wiederverwendet werden. Konvention zur eindeutigen Benennung (AccountService, OrderProcessor).
Auswahlmuster	✅ SOQL-Abfragen zentralisiert in Auswahlklassen pro Objekt (AccountSelector, OpportunitySelector). Auswahlmethoden geben konsistente Feldsets zurück. LDV-Optimierungsänderungen, die einmal angewendet wurden und sich auf alle Abfragen auswirken.
Repository-Muster	✅ Datenzugriff, der hinter Schnittstellen abstrahiert wird und Tests mit simulierten Datenquellen ermöglicht. Repository-Implementierungen umfassen Strategien zur Erstellung, Zwischenspeicherung und Optimierung von Abfragen. Geschäftslogik hängt von Repository-Schnittstellen ab, nicht von konkreten Implementierungen.
Komponentendesignstandards	✅ Lightning-Webkomponenten folgen dem Prinzip der Einzelverantwortung, legen Eigenschaften für die Konfiguration offen und geben Ereignisse für die übergeordnete Kommunikation aus, die für die Zusammensetzung und Wiederverwendung vorgesehen sind. Komponentenbibliothek mit Nutzungsbeispielen dokumentiert.
Codeorganisation	✅ Logische Paketstruktur gruppiert verwandte Klassen. Klare Trennung zwischen Domänenlogik, Datenzugriff, API-Endpunkten und Integrationsadaptern. Paketabhängigkeiten fließen in eine Richtung.

Antimuster

Wohin schauen	Wie schlecht sieht
Auslöser	⚠️ Alle Geschäftslogiken, die direkt in Auslöserdateien mit tief verschachtelten Bedingungen eingebettet sind, ohne Trennung von Bedenken und ohne Handler-Klassen. Über 300 Zeilenauslöserdateien, die Validierungs-, Geschäftslogik- und Integrationsaufrufe mischen. Effektive Tests nicht möglich.
Abfrage in Schleife	⚠️ SOQL-Abfragen, die in Iterationsschleifen ausgeführt werden. Funktioniert mit kleinen Datenvolumen, verstößt jedoch bei der Verarbeitung von Massenvorgängen gegen die Obergrenze von 100 SOQL-Abfragen. Wird nur entdeckt, wenn Auslöser Massendaten in der Produktion laden.
DML in Schleife	⚠️ DML-Anweisungen (Einfügen, Aktualisieren, Löschen), die in Iterationsschleifen ausgeführt werden. Verstößt bei Massenvorgängen gegen die Obergrenze von 150 DML-Anweisungen. Jeder Datensatz wird in einer separaten Datenbanktransaktion verarbeitet und nicht in einer effizienten Massenverarbeitung.

Muster

Wohin schauen	Wie gut aussieht
Architekturentscheidungsdatensätze	✅ Wichtige Architekturentscheidungen, die in in der Versionskontrolle gespeicherten ADRs dokumentiert sind. AS erfassen Kontext (Geschäftsfaktoren, technische Einschränkungen), Entscheidung (was ausgewählt wurde), berücksichtigte Alternativen (Warum sie abgelehnt wurden) und Konsequenzen (Kontexte, Bedingungen für eine erneute Prüfung).