text: Bei der Erweiterung der OOTB-Verhaltensweisen ist es wichtig, Upgrades zu berücksichtigen. Wenden Sie immer Anpassungen im Ordner "/apps"und entweder Überlagerungen über den entsprechenden Knoten im Ordner "/libs"an oder verwenden Sie "sling:resourceSuperType", um das Verhalten "Out-of-the-Box"zu erweitern. Zwar können Änderungen erforderlich sein, um neue AEM-Versionen zu unterstützen, doch die neue Version sollte Ihre Anpassungen nicht überschreiben, wenn diese Best Practice befolgt wird.
  Dadurch lässt sich das Erscheinungsbild der Website vereinheitlichen und die Codepflege vereinfachen. Wenn eine neue Vorlage benötigt wird, stellen Sie sicher, dass sie von einer freigegebenen Basisvorlage erweitert wird, damit globale Anforderungen wie die clientlib-Einbindung an einer Stelle kodiert werden können. Wenn eine neue Komponente benötigt wird, suchen Sie nach Möglichkeiten, die von einer vorhandenen Komponente ausgehen können.
  Indem Sie die Komponenten definieren, die in den einzelnen Absatzsystemen auf der Seite enthalten sein können, können Sie Einfluss darauf nehmen, dass das Erscheinungsbild der Seite einheitlich ist. Durch die Beschränkung des Zugriffs auf das Design auf Seiten können "Super-Autoren"die zulässigen Komponenten pro Seite ohne Einmischung des Entwicklers ändern und gleichzeitig sicherstellen, dass die anderen Autoren die Unternehmensstandards einhalten.
  Grundsatz der Einzelverantwortung - jedes Modul, jede Klasse, jede Methode usw. sollte nur eines tun.
  Open/Closed Principle - Module sollten zur Erweiterung geöffnet und zur Änderung geschlossen werden.
  Substitutionsprinzip für Liskov - Typen sollten durch ihre Subtypen ersetzt werden können.
  Prinzip der Schnittstellensegmentierung - kein Client sollte gezwungen sein, von Methoden abhängig zu sein, die er nicht verwendet.
  Prinzip der Abhängigkeitskonvertierung - Module auf hoher Ebene sollten nicht von Modulen auf niedriger Ebene abhängig sein. Beide sollten von Abstraktionen abhängen. Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen.
  Der Robustheitsgrundsatz besagt, dass Sie streng sein sollten, bei dem was Sie senden, und offen bei dem, was Sie von anderen akzeptieren. Mit anderen Worten, wenn wir Nachrichten an Dritte senden, sollten wir die Spezifikationen vollständig einhalten, aber beim Empfang von Nachrichten von einem Dritten sollten wir nicht konforme Nachrichten akzeptieren, solange die Bedeutung der Nachricht klar ist.
  Sammlungen und Testcode sind ein integraler Bestandteil jeder agilen Software-Implementierung, allerdings sollten Sie sicherstellen, dass sie nicht ohne entsprechende Kontrolle in Ihre Produktionscodebasis gelangen. Daher wird empfohlen, Spitzen in einem eigenen Modul zu erstellen.
  Bei Datenmigrationsskripten handelt es sich zwar um Produktionscode, doch diese werden in der Regel nur einmal beim ersten Start einer Site ausgeführt. Sobald die Site also live ist, wird dies zu totem Code. Um sicherzustellen, dass wir keinen Implementierungscode erstellen, der von den Migrationsskripten abhängt, sollten sie in ihrem eigenen Modul implementiert werden. Dies ermöglicht uns auch, diesen Code sofort nach dem Start zu entfernen und zurückzuziehen, wodurch Code ohne Ende aus dem System entfernt wird.
  Apache has published style conventions at https://maven.apache.org/developers/conventions/code.html . Es ist am besten, sich an diese Konventionen zu halten, da dadurch die schnelle Bereitstellung neuer Ressourcen erleichtert wird.