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.
SOLID ist ein Akronym, das fünf architektonische Prinzipien beschreibt, die Sie einhalten sollten:
Durch die Berücksichtigung dieser fünf Prinzipien lässt sich ein System erzielen, in dem eine strikte Trennung der Anliegen gegeben ist.
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 unmittelbar nach dem Start zu entfernen und zurückzuziehen, wodurch Code ohne Ende aus dem System entfernt wird.
Apache hat Stilkonventionen unter https://maven.apache.org/developers/conventions/code.html veröffentlicht. Es ist am besten, sich an diese Konventionen zu halten, da dadurch die schnelle Bereitstellung neuer Ressourcen erleichtert wird.