Quando si estendono i comportamenti OOTB, è importante tenere a mente gli aggiornamenti. Applicate sempre le personalizzazioni nella directory /apps e sovrapponete ai nodi corrispondenti nella directory /libs oppure utilizzate sling:resourceSuperType per estendere il comportamento out-of-the-box. Anche se possono essere necessarie alcune modifiche per supportare una nuova versione AEM, la nuova versione non deve sovrascrivere le personalizzazioni se questa procedura viene seguita.
In questo modo il sito potrà mantenere un aspetto e un aspetto più coerenti e semplificare la manutenzione del codice. Quando è necessario un nuovo modello, accertatevi di estenderlo da un modello di base condiviso in modo che i requisiti globali, come l'inclusione clientlib, possano essere codificati in un'unica posizione. Quando è necessario un nuovo componente, cercate le opportunità di estendere da un componente esistente.
Definendo quali componenti possono essere inclusi in ogni parsys della pagina, è possibile controllare l'aspetto del sito. Limitando l'accesso alla progettazione sulle pagine, è possibile consentire agli "autori super" di modificare i componenti consentiti per pagina senza l'intervento dello sviluppatore, garantendo nel contempo che gli altri autori seguano gli standard aziendali.
SOLID è un acronimo che descrive cinque principi architettonici che devono essere rispettati:
Il rispetto di questi cinque principi dovrebbe tradursi in un sistema che preveda una netta separazione delle preoccupazioni.
Il principio della solidità afferma che dovremmo essere conservatori in ciò che inviamo, ma essere liberali in ciò che accettiamo. In altre parole, quando inviamo messaggi a terzi, dovremmo essere completamente conformi alle specifiche, ma quando riceviamo messaggi da terzi, dovremmo accettare messaggi non conformi fintanto che il significato del messaggio è chiaro.
Picchi e codice di test sono parte integrante di qualsiasi implementazione software Agile, ma vogliamo assicurarci che non entrino nella nostra base di codice di produzione senza il livello appropriato di sorveglianza. Di conseguenza, si consiglia di creare picchi nel proprio modulo.
Gli script di migrazione dei dati, mentre il codice di produzione, vengono in genere eseguiti una sola volta all'avvio iniziale di un sito. Pertanto, non appena il sito è attivo, questo diventa codice morto. Per evitare che venga creato codice di implementazione che dipende dagli script di migrazione, questi devono essere implementati nel proprio modulo. Questo ci permette anche di rimuovere e ritirare questo codice subito dopo il lancio, eliminando il codice morto dal sistema.
Apache ha pubblicato le convenzioni di stile in https://maven.apache.org/developers/conventions/code.html. E' meglio seguire queste convenzioni, in quanto renderà più facile reperire rapidamente nuove risorse.