ソフトウェアプロジェクトではモジュール化が重要であることは明らかですが、それがどれほど重要で、どのような理由で重要であるかについての人々の意見を知りたいと思います。私はこれを求めているので明らかに私自身のアイデアを持っていますが、それは自分のソフトウェアプロジェクトをモジュール化する必要がある理由の「一般的なブレインストーミング」のように考えてください...
5 に答える
複雑な問題を一度に把握するには、人間には限界があります。しかし、私たちは、大きな問題に取り組むために、複雑な問題をあまり複雑ではない (おそらく非常に多くの) 個々の問題に分解する能力を持っています。
これは基本的に、「再利用」、「関心の分離」、「より簡単なメンテナンス」などの答えを導き出すものです。
これらの理由はすべて、複雑な問題を 1 人で分解して 1 つずつ取り組む場合でも、複数のチームで問題を分解して複雑さを分散させる場合でも当てはまります。
主な側面の1つは再利用だと思います。モジュール式に構築する場合、「ああ、これは以前に行ったことがあるが、それを使用するには、これとこの機能も取得する必要があります。これは、アプリケーションとはまったく関係ありません」などのことはほとんどありません。
また、理解しやすいです。たくさんのことを同時に頭に入れておくことはできません。コードがモジュール式の場合、それ自体で意味のあるものの「領域」を確立する方が簡単です。そして、この領域が小さくなりがちになると、断片ではなく全体として理解できます。
最後に、物事が小さい場合、テストと保守が容易になります。また、テストでは、アプリケーションのごく一部のみをテストすると、エラーが発生した場所がより速く示されます。
コードをさまざまなモジュールに配置する主な理由:
- 関心の分離:クラスが別々のモジュールに編成されている場合、クラスの内部に関する知識をさまざまなレベルまたはさまざまなタスクで制限する方が簡単だと思います。内部が十分に隠されている場合、内部に依存することは単に「汚い」と感じます。
- 小さなコンポーネントの保守が簡単:プロジェクトに数百のファイルが含まれている場合よりも、コードファイルの数が少ないプロジェクトで作業している場合は、通常、開発環境の応答性が高くなります。
- 名前空間の衝突の防止:Javaで名前空間を使用するなど、適切にモジュール化すると、Fooコンポーネントのprintout()関数がバーコンポーネント。
- セキュリティ上の懸念の分離:あるコンポーネントが別のコンポーネントのつま先を踏んだときの潜在的な損傷を最小限に抑えるのが簡単です。使用しているテクノロジーに応じて、各モジュールがメモリ内で再生できる場所を制限できます。
モジュール化とデカップリングは多くの理由で重要です。いくつかは次のとおりです。
- 再利用:特定の目的専用のソフトウェアモジュールを再利用する方がはるかに簡単です
- 複雑さの管理:分離されたモジュールでの作業(コードの記述、デバッグ、保守など)により、アプリケーションやソフトウェアシステムの他の側面に気を取られることなく、特定のドメインの問題に集中できます。
また、次のようなアプリケーション アーキテクチャの基本的なアクティビティと見なすこともできます。
- いくつかのビジネス仕様と機能仕様が必要です
- 非機能モジュールと純粋な技術的横断モジュールを識別しながら、主要な機能をアプリケーションにグループ化します
そのため、「財務ポートフォリオの計算」は実際には次のように分割されます。
- 計算モジュール
- ディスパッチャ モジュール (ポートフォリオが大きすぎて 1 つのサーバーで計算できないため)
- ランチャー モジュール (すべての計算をパイロットするため)
- GUI(実際に何が起こっているかを確認するため)
さらに、いくつかの横断的なもの:
- KPI ロギング
- 例外管理
そのような機能要件を 1 つの大きなモノリシック モジュールとして扱うと、開発者はすべてのサブルーチンを順番に実装する必要があります。
一方、明確なアプリケーション アーキテクチャを使用すると、より一般的で横断的なモジュールの作業を開始しながら、他のよりビジネス指向のモジュールを改良することができます。
また、より多くのインターフェイスを定義し、さまざまなモジュールが解決しなければならない相互通信の問題を分析する必要があります (直接 n 対 n のタイポロジー? バス? など)。