L'inclusione di script in JSP rende difficile il debug dei problemi nel codice. Inoltre, includendo gli script in JSP, è difficile separare la logica aziendale dal livello di visualizzazione, che è una violazione del principio di responsabilità singola e del modello di progettazione MVC.
Il codice viene scritto una volta, ma letto più volte. Trascorrere un po 'di tempo in avanti per pulire il codice che scriviamo pagherà i dividendi lungo la strada come noi e altri sviluppatori hanno bisogno di leggerlo più tardi.
Idealmente, un altro programmatore non dovrebbe dover aprire un modulo per capire cosa fa. Allo stesso modo, dovrebbero essere in grado di capire cosa fa un metodo senza leggerlo. Meglio possiamo abbonarci a queste idee, più facile sarà leggere il nostro codice e più velocemente saremo in grado di scrivere e cambiare il nostro codice.
Nella base di codici AEM sono utilizzate le seguenti convenzioni:
<Interface>Impl
, ovvero ReaderImpl
.<Variant><Interface>
, ovvero JcrReader
e FileSystemReader
.Abstract<Interface>
o Abstract<Variant><Interface>
.com.adobe.product.module
. Ogni manufatto Maven o bundle OSGi deve avere un proprio pacchetto.Tenete presente che queste convenzioni non devono necessariamente essere applicate alle implementazioni dei clienti, ma è importante che le convenzioni siano definite e rispettate in modo che il codice possa essere mantenuto.
Idealmente, i nomi dovrebbero rivelare le loro intenzioni. Un test comune del codice per i nomi che non sono chiari come dovrebbero essere è la presenza di commenti che spiegano a cosa serve la variabile o il metodo:
Non chiaro |
Cancella |
int d; //tempo trascorso in giorni |
int elapsedTimeInDays; |
//get tagged images |
public List getTaggedImages() {} |
DRY afferma che lo stesso set di codici non deve mai essere duplicato. Questo vale anche per cose come i letterali stringa. La duplicazione del codice apre la porta a difetti ogni volta che qualcosa deve cambiare e deve essere ricercato ed eliminato.
Le regole CSS devono essere specifiche per l'elemento di destinazione nel contesto dell'applicazione. Ad esempio, una regola CSS applicata a .content.center sarebbe troppo ampia e potrebbe potenzialmente avere un impatto su un sacco di contenuto nel sistema, richiedendo ad altri di ignorare questo stile in futuro. .myapp- centertextè una regola più specifica in quanto specifica il ** testo centrato nel contesto dell'applicazione.
Quando un'API è obsoleta, è sempre meglio trovare il nuovo approccio consigliato invece di affidarsi all'API obsoleta. In questo modo, gli aggiornamenti saranno più fluidi in futuro.
Le stringhe che non vengono fornite da un autore devono essere racchiuse in una chiamata al dizionario i18n di AEM tramite I18n.get() in JSP/Java e CQ.I18n.get() in JavaScript. Questa implementazione restituirà la stringa che gli è stata passata se non viene trovata alcuna implementazione, quindi offre la flessibilità di implementare la localizzazione dopo l'implementazione delle funzionalità nella lingua primaria.
Mentre i percorsi nel JCR non devono contenere spazi, la loro presenza non deve causare l'interruzione del codice. Jackrabbit fornisce una classe di utilità Testo con i metodi escape() e escapePath(). Per i JSP, l'interfaccia Granite espone una funzione granite:encodeURIPath() EL.
AEM fornisce un'API XSS per pulire facilmente i parametri e garantire la sicurezza dagli attacchi di script tra siti. Inoltre, HTL ha queste protezioni integrate direttamente nel linguaggio di modellazione. Un foglio di supporto API è disponibile per il download all'indirizzo Sviluppo - Linee guida e best practice.
Per il codice Java, AEM supporta slf4j come API standard per la registrazione dei messaggi e dovrebbe essere utilizzato insieme alle configurazioni rese disponibili tramite la console OSGi per garantire la coerenza dell'amministrazione. Slf4j espone cinque diversi livelli di registrazione. Per scegliere quale livello registrare un messaggio, consigliamo di utilizzare le seguenti linee guida:
Nel caso di JavaScript, console.log deve essere utilizzato solo durante lo sviluppo e tutte le istruzioni di registro devono essere rimosse prima del rilascio.
Evitate di copiare il codice senza comprendere cosa fa. In caso di dubbi, è sempre meglio chiedere a qualcuno che ha più esperienza con il modulo o l'API su cui non si è chiari.