Dieser Text wurde mit dem automatisierten Übersetzungssystem von Salesforce übersetzt. Nehmen Sie an unserer Umfrage teil, um Feedback zu diesem Inhalt zu geben und uns mitzuteilen, was Sie als Nächstes sehen möchten.
Composable – Packageability (Composierbar – Paketierbarkeit)
Erfahren Sie mehr über Gut entwickelte anpassungsfähige Komponenten → Composable → Packability → Dependency Management
| Wohin schauen? Produktbereich | Standort | Wie sieht gut aus? Muster |
|---|---|
| Plattform | Designstandards | ✅ Es gibt Standards zum Einführen oder Ändern von Abhängigkeiten |
| Plattform | Designstandards | ✅ Es gibt Standards zum Deklarieren von Abhängigkeiten |
| Plattform | Pakete | ✅ Keine Metadaten werden paketübergreifend dupliziert |
| Plattform | Pakete | ✅ Bei der Paketentwicklung werden alle Entwicklungsarbeiten in der frühen Phase in Testorganisationen durchgeführt |
| Plattform | Quellcodeverwaltung | ✅ Entwickler können Testorganisationen erstellen und Paketmetadaten erfolgreich über die Quellcodeverwaltung bereitstellen |
| Plattform | Quellcodeverwaltung | ✅ Paketversionen für entsperrte Pakete verwenden Aliasnamen (LATEST), um Abhängigkeiten in sfdx-project.json zu deklarieren |
Erfahren Sie mehr über Gut entwickelte anpassungsfähige Komponenten → Composable → Packability → Loose Coupling
| Wohin schauen? Produktbereich | Standort | Wie sieht gut aus? Muster |
|---|---|
| Platform | Apex | ✅ Von dynamischen Laufzeitinformationen abhängige Methoden verweisen auf geeignete benutzerdefinierte Metadatentypen |
| Platform | Apex | ✅ Allgemeine Services und Boilerplate-Code werden mit abstrakten oder virtuellen Apex-Klassen definiert |
| Plattform | Designstandards | ✅ (Optional) Alle genehmigten Anwendungsfälle für benutzerdefinierte Einstellungen sind klar aufgeführt (sofern vorhanden) |
| Plattform | Designstandards | ✅ Benennungskonventionen behandeln, wie Paketeinheiten angegeben werden |
| Plattform | Designstandards | ✅ Es ist möglich, eine Liste aller aktuell definierten Paketeinheiten (und der zugehörigen Benennungskonventionen) zu suchen und zu finden |
| Plattform | Designstandards | ✅ Es gibt Standards zum Vorschlagen von Paketeinheiten-Ergänzungen oder -Änderungen |
| Plattform | Organisation | ✅ Benutzerdefinierte Metadatentypen bieten dynamische Laufzeitinformationen für Code und deklarative Anpassungen |
| Plattform | Organisation | ✅ Es sind keine benutzerdefinierten Objekte vorhanden, um dynamische Laufzeitinformationen für Code oder deklarative Anpassungen bereitzustellen |
| Plattform | Organisation | ✅ Es sind keine benutzerdefinierten Einstellungen vorhanden oder es sind nur wenige benutzerdefinierte Einstellungen vorhanden und keine sind mit Paketfunktionen verbunden |
| Plattform | Pakete | ✅ In Produktions- oder Sandbox-Instanzen sind keine nicht verwalteten Pakete definiert |
| Plattform | Pakete | ✅ Organisationsabhängige entsperrte Pakete werden nur für Experimente in der Frühphase oder zum Nachweis des Konzepts verwendet |
| Plattform | Quellcodeverwaltung | ✅ package.xml werden nur in der frühen Phase oder in Proof-of-Concept-Projektmanifesten angezeigt |
Erfahren Sie mehr über Gut entwickelte anpassungsfähige Komponenten → Composable → Packability → Dependency Management
| Wohin schauen? Produktbereich | Standort | Was vermeiden? Anti-Pattern |
|---|---|
| Plattform | Designstandards | ⚠️ Designstandards sind nicht vorhanden oder befassen sich nicht damit, wie Abhängigkeiten deklariert werden |
| Plattform | Pakete | ⚠️ Abhängigkeiten werden durch Duplizieren von Metadaten in verschiedenen Paketen umgangen |
| Plattform | Pakete | ⚠️ Die frühzeitige Paketentwicklung erfolgt in Entwickler-Sandbox-Instanzen oder die frühzeitige Paketentwicklung kann nicht in Testorganisationen erfolgen |
| Plattform | Quellcodeverwaltung | ⚠️ Entwickler können nicht erfolgreich mit Testorganisationen mit Quellcodeverwaltung arbeiten |
| Plattform | Quellcodeverwaltung | ⚠️ Paketversionen für entsperrte Pakete werden explizit (ohne LATEST) in sfdx-project.json deklariert |
Erfahren Sie mehr über Gut entwickelte anpassungsfähige Komponenten → Composable → Packability → Loose Coupling
| Wohin schauen? Produktbereich | Standort | Was vermeiden? Anti-Pattern |
|---|---|
| Platform | Apex | ⚠️ Allgemeine Services und Boilerplate-Code lassen sich nicht einfach von anderen Klassen unterscheiden |
| Platform | Apex | ⚠️ Methoden verwenden keinen konsistenten Ansatz für den Zugriff auf dynamische Informationen, Laufzeitinformationen oder Methoden, die benutzerdefinierte Objekte nach Informationen zum Laufzeitverhalten oder benutzerdefinierten Codeverweisen abfragen |
| Platform | Apex | ⚠️ Interne Verweise über Klassen und Methoden hinweg sind schwer zu befolgen und in der Codebasis inkonsistent |
| Plattform | Designstandards | ⚠️ Designstandards sind nicht vorhanden oder beziehen sich nicht auf Paketeinheiten und Anwendungsfälle |
| Plattform | Organisation | ⚠️ Benutzerdefinierte Einstellungen werden verwendet |
| Plattform | Organisation | ⚠️ Benutzerdefinierte Objekte sind vorhanden, um dynamische Laufzeitinformationen für Code oder deklarative Anpassungen bereitzustellen |
| Plattform | Organisation | ⚠️ Benutzerdefinierte Metadatentypen werden nicht (oder nicht konsistent) verwendet, um dynamische Laufzeitinformationen für Code und deklarative Anpassungen bereitzustellen |
| Plattform | Pakete | ⚠️ Nicht verwaltete Pakete werden in Produktions- oder Sandbox-Instanzen definiert |
| Plattform | Pakete | ⚠️ Alle Pakete sind organisationsabhängige entsperrte Pakete |
| Plattform | Quellcodeverwaltung | ⚠️ package.xml-Dateien werden zum Steuern von Metadatenbereitstellungen verwendet |