現代の開発のペースが速い世界では、プロジェクトが成功するか、それ自体の複雑さによって崩壊するかはアーキテクチャによって決まります。多くの開発者はアーキテクチャが重要であることを直感的に理解していますが、「なぜ」と「どのように」について議論されることはあまりありません。アーキテクチャはなぜそれほど重要なのでしょうか?また、選択が混乱ではなく明確になるようにするにはどうすればよいですか?
この記事は、React、Vue、Svelte、および Vanilla JS 開発者に役立ちます。 Angular はデフォルトで厳密なアーキテクチャ パターンを強制するため、Angular 開発者にとってはあまり役に立たないかもしれませんが、それでも価値は得られます。
私の意見では、インターネット上には建築に関する詳細な情報が不足しています。有用なリソースはほんのわずかしか見つかりませんでした。そこで、建築に関する一連の記事を作成することにしました。
ここでは、アーキテクチャとは何か、なぜアーキテクチャが必要なのかを探り、いくつかの重要な用語を紹介し、さまざまなタイプのアーキテクチャについて議論しましょう
アーキテクチャを計画せずに、コードに取り掛かるだけで新しいプロジェクトを開始することを想像してください。サブモジュールとコンポーネント間のリンクを含む最初のモジュールを開発します。次に、2 番目のモジュールを作成し、最初のモジュールにリンクします。このパターンは、モジュールと接続を追加するたびに継続します。
問題は、モジュールを削除または編集する必要があるときに発生します。プロジェクトが成長するにつれて、無数のモジュール、サブモジュール、およびそれらの間の接続が曖昧になり、複雑さも増します。最終的に、この複雑な Web は開発者にとって頭痛の種となり、企業にとっては維持コストが高くなります。
難易度 === 時間 === お金
多くの開発者は、アーキテクチャがフォルダー構造と同等であると誤解していますが、それは間違いです。アーキテクチャはファイル構成を超えています。プロジェクト システム内でモジュールとコンポーネントがどのように相互作用するかを説明します。
アーキテクチャにはプロジェクトのさまざまな要素が含まれており、モジュールとコンポーネントがどのように開発されるべきか、またそれらがどのように相互接続されるべきかを指定します。
フロントエンドでは、モジュールは通常、ビジネス ロジックを利用する UI コンポーネントです。これらは、ページなどの大きなコンポーネントから、入力、ボタン、タイポグラフィなどの小さなコンポーネントまで多岐にわたります。
プロジェクトのモジュールに次の要素があることを確認する必要があります。
Cohesion は、モジュールが実行できることを指します。凝集度が低いということは、クラスが非常に多様な行動を行うことを意味します。つまり、行動が幅広く、何をすべきかに焦点が当てられていないのです。高い凝集性とは、クラスが本来行うべきことに集中していること、つまりクラスの意図に関連するメソッドのみに集中していることを意味します。
カップリング は、2 つのモジュールが互いにどの程度関連または依存しているかを指します。低結合モジュールの場合、1 つのクラスで何か大きな変更を加えても、他のクラスに影響を与えることはありません。結合度が高いと、コードの変更と保守が困難になります。モジュールは密接に連携しているため、変更を行うにはシステム全体の改修が必要になる場合があります。
本質的に、凝集性が高いとは、関連するコードを 1 か所にまとめることを意味します。同時に、低結合には、コードベースの無関係な部分を可能な限り分離することが含まれます。
画像の説明は次のとおりです:
画像内のモジュールは、簡単に見つけられる円の個別のクラスターで表されています。モジュール内の各円は、特定のタスクの実行を担当するクラスまたはコンポーネントを表します。モジュール内の同じ色の円は、同じタスクを解決する要素を示します。画像内の矢印はモジュール間の接続を示し、モジュールがどのように相互作用するかを示しています。
God オブジェクト のアンチパターンを考えてみましょう。ゴッド オブジェクトは、複数のサブモジュールと相互接続を持ち、複数のタスクを同時に解決しようとするモジュールです。
これにより、単一のモジュールが複数のタスクを担当するため高い結合が得られ、さまざまなモジュールとサブモジュール間の接続が曖昧であるため高い結合が得られます。
このシナリオでは、モジュールは適切に分割されていますが、内部のサブモジュールは異なるタスクを解決します (画像内の異なる色で示されています)。ただし、モジュール間の接続はまだ不明です。
これは別のケースです。ここでは、モジュールが明確に分割されており、それらの間の接続は強固です。ただし、各モジュール内では複数のタスクを解決するため凝集性が低く、不必要な複雑さが生じます。
それでも、個々のモジュールを簡単に削除または変更できるため、これは前の 2 つの例よりも優れています。
理想的なアーキテクチャでは、モジュール間のリンクは「弱く」、モジュールの削除や変更が簡単になります。各モジュール内では、コンポーネントとクラスが 1 つの特定のタスクを解決します (均一な色で示されているように)。前の例とは異なり、責任が混在することはありません。
このような理想的なアーキテクチャはプロジェクトではまれですが、これには特定の知識と経験が必要ですが、私たち全員がそれを目指すべきです。
アーキテクチャは、モジュール、コンポーネント、およびそれらの間の接続の構造です。
アーキテクチャを成功させる鍵は、DRY、KISS、SOLID などの開発原則を実装することにあります。モジュールの削除と変更は、特に削除部分が簡単であることが重要です。
ご質問がある場合、またはどのアーキテクチャについて詳しく知りたい場合は、コメント欄でお知らせください。
以上が混沌から明晰さへ: 建築の重要な役割の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
