現在表示中:

アップグレードのためのデザイン

OOTB 動作を拡張するときは、アップグレードを念頭に置いておくことが重要です。カスタマイズは必ず /apps ディレクトリで適用し、/libs ディレクトリの対応するノードの上にオーバーレイするか、または sling:resourceSuperType を使用して初期設定済みの動作を拡張します。新しい AEM バージョンをサポートするためにいくつかの変更が必要になることがありますが、このプラクティスに従う場合は、新しいバージョンでその変更が上書きされないようにする必要があります。

可能な場合はテンプレートおよびコンポーネントを再利用する

これにより、サイトの外観と操作性をより一貫性のあるものにし、コードのメンテナンスを簡素化できます。新しいテンプレートが必要なときは、共有基本テンプレートから拡張してください。このようにすると、clientlib のインクルードといったグローバルな要件を 1 箇所でコーディングできます。新しいコンポーネントが必要な場合は、既存のコンポーネントから拡張できるかどうかを検討してください。

テンプレートデザイン

ページで各 parsys にどのコンポーネントを含めることができるかを定義することで、サイトの外観と操作性における一貫性を制御できます。ページのデザインへのアクセスを制限することによって、他の作成者は企業の標準に従う一方で、「スーパー作成者」は開発者の介入なしでページごとに許可されたコンポーネントを変更できるようになります。

SOLID アーキテクチャを開発する

SOLID は、アーキテクチャに関する準拠すべき 5 つの原則を示す略語です。

  • S(単一責任の原則) - 各モジュール、クラス、メソッドなどはそれぞれ 1 つのことだけを行うようにします。
  • O(オープン/クローズドの原則) - モジュールは、拡張に対してはオープンにし、変更に対してはクローズドにします。
  • L(リスコフの置換原則) - 型は、派生型に置き換え可能である必要があります。
  • I(インターフェイス分離の原則) - クライアントに対して、利用していないメソッドへの依存を強制しないようにします。
  • D(依存性逆転の原則) - 上位のモジュールは、下位のモジュールに依存しないようにします。どちらも、抽象に依存する必要があります。抽象が詳細に依存しないようにします。詳細が抽象に依存するようにします。

この 5 つの原則に準拠しようと努力することによって、システムでの厳密な関心の分離が実現します。

堅牢性の原則に準拠する

堅牢性の原則では、送信内容に対しては保守的になり、受信内容に対しては寛容になることと規定しています。つまり、サードパーティにメッセージを送信するときには仕様に完全に準拠しますが、サードパーティからメッセージを受信するときには、仕様に準拠していないメッセージであっても、メッセージの意味が明白である限り、受け入れるようにします。

独自のモジュールにスパイクを実装する

スパイクおよびテストコードは Agile ソフトウェア実装の不可欠な要素ですが、それらが適切なレベルでの管理なしで実稼動コードベースに入り込まないようにする必要があります。結果として、独自のモジュールにスパイクを作成することをお勧めします。

独自のモジュールにデータ移行スクリプトを実装する

データ移行スクリプトは実稼動コードで、通常は、サイトの初期起動時に 1 回のみ実行されます。したがって、サイトが稼動中になるとすぐにデッドコードになります。データ移行スクリプトに依存する実装コードをビルドしないようにするには、独自のモジュールにデータ移行スクリプトを実装するようにします。こうすると、起動直後にこのコードを削除して廃棄できるので、システムからデッドコードが排除されます。

POM ファイルで公開済みの Maven 表記規則に従う

Apache が http://maven.apache.org/developers/conventions/code.html でスタイル規則を公開しています。新しいリソースを期待される水準にすることが容易になるので、この規則に従うことをお勧めします。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー