Sie sehen sich Hilfeinhalte der folgenden Version an:

Auslegen des Designs auf Upgrades

Bei der Erweiterung der OOTB-Verhaltensweisen ist es wichtig, Upgrades zu berücksichtigen. Nehmen Sie Anpassungen immer im Verzeichnis /apps vor und überlagern Sie entweder die entsprechenden Knoten im Verzeichnis /libs oder verwenden Sie „sling:resourceSuperType“, um das Standardverhalten 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.

Nach Möglichkeit Wiederverwenden von Vorlagen und Komponenten

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 gemeinsam verwendeten Basisvorlage erweitert wird, sodass globale Anforderungen wie die clientlib-Einbindung an zentraler Stelle kodiert werden können. Wenn eine neue Komponente benötigt wird, sollten Sie versuchen, eine bestehenden Komponente zu erweitern.

Gestalten von Vorlagendesigns

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 das Beschränken des Zugriffs auf das Design auf Seiten können „Superautoren“ die zulässigen Komponenten je Seite ohne Unterstützung eines Entwicklers ändern und gleichzeitig sicherstellen, dass die anderen Autoren die Unternehmensstandards einhalten.

Entwickeln von SOLID-Architekturen

SOLID ist ein Akronym, das fünf architektonische Prinzipien beschreibt, die Sie einhalten sollten:

  • Single Responsibility-Prinzip – Dieses Prinzip besagt, dass jedes Modul, jede Klasse, jede Methode usw. nur eine einzige Verantwortung haben sollte.
  • Open/Closed-Prinzip – Dieses Prinzip besagt, dass Module sowohl offen (für Erweiterungen) als auch geschlossen (für Änderungen) sein sollten.
  • Liskov Substitution-Prinzip – Dieses Prinzip besagt, dass Typen durch ihre Untertypen ersetzbar sein sollten.
  • Interface Segregration-Prinzip – Dieses Prinzip besagt, dass Clients nicht gezwungen werden sollten, von Methoden abzuhängen, die sie nicht verwenden.
  • Dependency Inversion-Prinzip – Dieses Prinzip besagt, dass Module höherer Ebenen nicht von Modulen niedriger Ebenen abhängig sein sollten. Beide sollten von Abstraktionen abhängen. Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen.

Durch die Berücksichtigung dieser fünf Prinzipien lässt sich ein System erzielen, in dem eine strikte Trennung der Anliegen gegeben ist.

Befolgen des Robustheitsgrundsatzes

Der Robustheitsgrundsatz besagt, dass Sie streng sein sollten, bei dem was Sie senden, und offen bei dem, was Sie von anderen akzeptieren. Das heißt, wenn Sie Nachrichten an Dritte senden, sollten Sie sich unbedingt an die jeweiligen Spezifikationen halten. Wenn Sie aber Nachrichten von Dritten empfangen, sollten Sie nicht konforme Nachrichten akzeptieren, solange die Bedeutung der Nachricht klar ist.

Implementierung von Sammlungen in eigenen Modulen

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. Entsprechend empfiehlt es sich, Sammlungen in ihrem eigenen Modul zu erstellen.

Implementieren von Datenmigrationsskripten in ihrem eigenen Modul

Bei Datenmigrationsskripten handelt es sich zwar um Produktionscode, doch diese werden in der Regel nur einmal beim ersten Start einer Site ausgeführt. Nach der Live-Schaltung der Site wird dieser folglich zu totem Code. Um sicherzustellen, dass Sie keinen Implementierungscode erstellen, der von den Migrationsskripten abhängig ist, sollten diese in einem eigenen Modul implementiert werden. Dies ermöglicht es Ihnen auch, diesen Code sofort nach dem Start zu entfernen und zu löschen, wodurch toter Code aus dem System entfernt wird.

Befolgen veröffentlichter Maven-Konventionen in POM-Dateien

Apache hat unter http://maven.apache.org/developers/conventions/code.html Stilkonventionen veröffentlicht. Es empfiehlt sich, diese Konventionen zu befolgen, da es damit neuen Mitarbeitern erleichtert wird, sich schnell zurechtzufinden.

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie