コーディングのヒント

可能な限り taglib または HTL を使用する

スクリプトレットを JSP に含めると、コード内の問題のデバッグが難しくなります。また、JSPにスクリプトレットを含めると、ビジネスロジックをビューレイヤーから分離するのが難しくなります。ビューレイヤーは、単一責任の原則とMVCの設計パターンに違反しています。

わかりやすいコードを記述する

コードを記述するのは一度ですが、何度も読まれます。我々が書いたコードをきれいにするのに少し時間を費やすと、我々や他の開発者は後で読む必要があるので、道路の配当を払う。

目的を明確に表す名前を選択する

別のプログラマーがモジュールを開かなくても内容がわかるようにすることが理想的です。同様に、メソッドを読まずに何を行うかを知ることができるはずです。 こうしたアイデアを購読すれば購読するほど、コードを読みやすくなり、コードを書いて変更するのが速くなります。

AEM のコードベースでは、次のような規則が使用されます。

  • インターフェイスの1つの実装は、<Interface>Implという名前です。ReaderImpl.
  • 1つのインターフェイスの複数の実装には、<Variant><Interface>という名前が付けられます。JcrReaderとFileSystemReader。
  • 抽象基本クラスの名前はAbstract<Interface>またはAbstract<Variant><Interface>です。
  • パッケージ名はcom.adobe.product.moduleです。 各MavenアーティファクトまたはOSGiバンドルには、独自のパッケージが必要です。
  • Java 実装は、その API の下の impl パッケージに配置します。

これらの規則を必ずお客様の実装に適用しなければならないというわけではありませんが、コードをメンテナンスしやすい状態に維持できるように、規則を定義してそれに準拠することが重要です。

名前を見れば、その目的が明らかになるようにすることが理想的です。名前が本来のように明確でない場合にテストされる一般的なコードは、変数やメソッドの目的を説明するコメントの存在です。

不明確

消去

int d; //elapsed time in days

int elapsedTimeInDays;

//get tagged images
public List getItems() {}

public List getTaggedImages() {}

繰り返しを避ける

DRY（Don't repeat yourself）は、同じコードセットを繰り返してはならないということです。これは、文字列リテラルなどにも当てはまります。 コードの複製は、何かが変更される必要があり、探し出され、削除される必要がある場合に、欠陥の扉を開きます。

範囲を限定しない CSS ルールを避ける

CSS ルールは、アプリケーションのコンテキスト内のターゲット要素に固有でなければなりません。例えば、.content .center​に適用されるCSSルールは過度に広く、システム全体の多数のコンテンツに影響を与え、将来、他のユーザーがこのスタイルを上書きする必要が生じる可能性があります。 .myapp-centertextは、ア プリケーションのコンテキスト内で中央のテキストを指定す ** るため、より具体的な規則になります。

廃止された API を使用しない

API が廃止された場合は常に、廃止された API を使用する代わりに、推奨される新しいアプローチを確認することをお勧めします。これにより、今後のアップグレードをよりスムーズに行うことができます。

ローカライズ可能なコードを記述する

作成者によって指定されない文字列は、JSP/Java の I18n.get() および JavaScript の CQ.I18n.get() を使用して AEM の i18n ディクショナリへの呼び出しでラップする必要があります。​​この実装は、実装が見つからない場合に渡された文字列を返すので、プライマリ言語で機能を実装した後に、柔軟にローカライゼーションを実装できます。

安全のためにリソースパスをエスケープする

JCR のパスにスペースを使用することはできませんが、スペースが使用されていても、コードが中断しないようにする必要があります。Jackrabbit では、escape() および escapePath() メソッドを含む Text ユーティリティクラスを提供しています。​ JSPの場合、Granite UIは​granite:encodeURIPath() EL​関数を公開します。

XSS API や HTL を使用して、クロスサイトスクリプティング攻撃を防ぐ

AEM では、パラメーターを簡単にクリーンにして、クロスサイトスクリプティング攻撃に対する安全性を確保するための XSS API を提供しています。さらに、HTLではこれらの保護機能がテンプレート言語に直接組み込まれています。 APIチートシートは、Development - Guidelines and Best Practicesからダウンロードできます。

適切なログ機能を実装する

Java コードについては、AEM では、メッセージをログに記録するための標準 API として slf4j をサポートしており、管理の一貫性を確保するために OSGi コンソールから使用可能な設定と組み合わせて使用する必要があります。Slf4jは、5つの異なるログレベルを公開します。 メッセージをログに記録するレベルを選択する際には、次のガイドラインを使用することをお勧めします。

  • ERROR：コードが中断され、処理を続行できない場合。これは、多くの場合、予期しない例外の結果として発生します。 通常、このシナリオにスタックトレースを含めると便利です。
  • WARN：正しく動作していない部分があるが、処理は続行できる場合。これは、多くの場合、PathNotFoundException​など、予期された例外の結果です。
  • INFO：システムを監視する際に役立つ情報。これがデフォルトであり、ほとんどのお客様が環境にこの設定を残すことに注意してください。 したがって、あまり使用しないでください。
  • DEBUG：処理に関するより詳細な情報。サポートを受けながら問題をデバッグする際に役立ちます。
  • TRACE：メソッドの開始／終了など、最も詳細な情報。これは通常、開発者のみが使用します。

JavaScript の場合は、開発時にのみ console.log を使用し、リリース前にすべてのログステートメントを削除する必要があります。**

カーゴカルトプログラミングを避ける

内容を理解せずに、コードをコピーしないでください。不確かな場合は、不明なモジュールやAPIの経験がある人に尋ねるのが常です。

このページ