機能を使用して展開を管理する場合、機能を多くの小さな機能または1つの大きな機能に分割する必要がありますか？

私はに比較的新しいです特徴モジュールを、私は）それがAを維持するために最も簡単なのかどうかについては、オンラインで一つの大きな機能またはBを矛盾した勧告を読んで）いくつかの小さな機能し、「機能・コントローラー」タイプのモジュールリストは、すべての小さな機能することを依存関係として。

特定の状況について少し：私はlocal development -> dev server -> staging server -> live serverワークフローを使用しています。この特定のサイトは、ほぼ間違いなく、私がこれまでに開発した唯一のサイトです。featuresこのサイト用に作成したを他のサイトで使用するつもりはありません。

これにより、過去に複数の機能で同じルールを誤って定義して問題が発生したことがあるため、すべてを1つの大きな機能で実行することに傾倒します。ただし、構造の観点からは、これは私には間違っているように思われます。異なる機能/機能があるため、別々の機能に分割する必要があります。一方で、これを行うことで、自分に追加の作業とオーバーヘッドを作成するだけで、誰にも利益をもたらさないと感じています。

実際のプラクティスでは、1つの大きな機能と多くの小さな機能のどちらを維持する方が簡単ですか？

概念レイヤーごとに分割されたいくつかの小さなフィーチャーを作成します。

利点：

1. オーバーライドを確認し、元に戻すを実行するときの粒度— すべてを一度に元に戻す必要はありません。
2. モジュール性—個々のコンポーネントを再利用する予定がない場合でも、個別のモジュールに分割することで保守性が向上します。

単一のサイトを開発からテスト、実稼働まで展開するために、次の分類法を使用します（「サイト」はサイトの一意のマシン名に置き換えられます）—

• site_types機能-コンテンツタイプ、フィールド、ImageCache設定、ユーザーロールを宣言します
• site_structure機能-コンテキスト、ビュー、メニューおよびメニューリンク、ブロック、ユーザー権限、変数を 宣言します
  • site_types機能に依存
• site_content機能- ノードを宣言します
  • site_structure機能に依存

複数の異なるサイトセクションがある場合（たとえば、パブリックとプライベート）、さらに分割することを検討してください。

• site_types 特徴
• site_structure 機能-パブリックとプライベートの両方に共通の構造コンポーネントを宣言します
  • site_types機能に依存
• site_public_structure 特徴
  • site_types機能に依存
• site_public_content 特徴
  • site_public_structure機能に依存
• site_private_structure 特徴
  • site_types機能に依存
• site_private_content 特徴
  • site_private_structure機能に依存