潜在的にモノリシックなアプリケーションをいくつかの小さなアプリケーションに分割すると、バグを防ぐことができますか？[閉まっている]

これを求める別の方法は次のとおりです。なぜプログラムはモノリシックになる傾向があるのですか？

Mayaのようなアニメーションパッケージのようなものを考えています。人々はさまざまなワークフローに使用します。

アニメーション機能とモデリング機能を独自の個別のアプリケーションに分割し、それらの間でファイルをやり取りして個別に開発した場合、それらの保守は容易ではないでしょうか？

はい。一般に、2つの小さく複雑でないアプリケーションは、1つの大きなアプリケーションよりも保守がはるかに簡単です。

ただし、アプリケーションがすべて連携して目標を達成すると、新しいタイプのバグが発生します。それらを連携させるには、メッセージを交換する必要があり、すべてのアプリケーションが完全に機能する場合でも、このオーケストレーションはさまざまな方法で失敗する可能性があります。100万個の小さなアプリケーションを持つことには、独自の問題があります。

モノリシックアプリケーションは、単一のアプリケーションにさらに多くの機能を追加する場合に実際に使用するデフォルトのオプションです。各機能を単独で検討する場合、これが最も簡単なアプローチです。全体が大きくなってから「XとYを分離すればうまくいく」と言うことができるのは一度だけです。

潜在的にモノリシックなアプリケーションをいくつかの小さなアプリケーションに分割すると、バグを防ぐことができますか

物事は現実にはめったにありません。

分割しても、そもそもこれらのバグを防ぐのに役立ちません。バグをより迅速に見つけるのに役立つ場合があります。小さく分離されたコンポーネントで構成されるアプリケーションでは、それらのコンポーネントに対してより個別の（「ユニット」のような）テストが可能になる場合があります。

しかしながら、

• 外部からモノリシックに見えるアプリケーションでさえ、内部で多くのユニットテスト可能なコンポーネントで構成されている可能性があるため、モノリシックアプリのユニットテストは必ずしも難しくない

• ユアンが既に述べたように、いくつかのコンポーネントの相互作用は、追加のリスクとバグをもたらします。また、複雑なプロセス間通信を使用したアプリケーションシステムのデバッグは、単一プロセスアプリケーションのデバッグよりも大幅に困難になる場合があります。

これは、より大きなアプリをコンポーネントに分割できる度合い、コンポーネント間のインターフェースの広さ、およびそれらのインターフェースの使用方法にも大きく依存します。

要するに、これはしばしばトレードオフであり、「はい」または「いいえ」の答えが一般的に正しい場合は何もありません。

なぜプログラムはモノリシックになる傾向があるのか

彼らですか？あなたの周りを見てください、私には非常にモノリシックに見えない、まったく逆の世界の膨大な数のWebアプリがあります。プラグインモデルを提供する多くのプログラムも利用可能です（言及したMayaソフトウェアでも提供されています）。

保守が簡単ではないでしょうか

ここでの「メンテナンスの容易化」は、多くの場合、アプリケーションのさまざまな部分をさまざまなチームがより簡単に開発できるため、分散ワークロードが改善され、より明確な焦点を当てた専門チームなどに起因します。

私はこれに関する大多数に反対する必要があります。アプリケーションを2つの別々のアプリケーションに分割しても、それだけではコードの保守や推論が容易になりません。

コードを2つの実行可能ファイルに分離すると、コードの物理構造が変更されるだけですが、それは重要ではありません。アプリケーションの複雑さを決定するのは、それを構成するさまざまな部分がどれほど緊密に結合されているかです。これは物理的な特性ではなく、論理的な特性です。

さまざまな懸念事項とシンプルなインターフェースを明確に分離したモノリシックアプリケーションを作成できます。他のマイクロサービスの実装の詳細に依存し、他のすべてのマイクロサービスと緊密に結合されたマイクロサービスアーキテクチャを持つことができます。

本当のことは、1つの大きなアプリケーションを小さなアプリケーションに分割するプロセスは、各パーツの明確なインターフェースと要件を確立しようとする場合に非常に役立ちます。DDDで言えば、境界のあるコンテキストが思い浮かぶでしょう。しかし、多数の小さなアプリケーションを作成する場合も、同じ論理構造を持つ1つの大きなアプリケーションを作成する場合も、技術的な決定になります。

はい。分割が完了したら、メンテナンスが簡単になります。しかし、それらを分割することは必ずしも簡単ではありません。プログラムの一部を再利用可能なライブラリに分割しようとすると、元の開発者が継ぎ目がどこにあるべきかを考えることができなかった場所が明らかになります。アプリケーションの一部がアプリケーションの別の部分に深く到達している場合、修正が難しい場合があります。継ぎ目をリッピングすると、内部APIをより明確に定義する必要があり、これが最終的にコードベースの保守を容易にします。再利用性と保守性は、どちらも明確に定義された継ぎ目の製品です。

相関関係は因果関係ではないことを覚えておくことが重要です。

大きなモノリスを構築し、それをいくつかの小さなパーツに分割すると、良いデザインになる場合とそうでない場合があります。（設計を改善できますが、保証はされていません。）

しかし、優れた設計では、多くの場合、大きなモノリスではなく、いくつかの小さな部品としてシステムが構築されます。（モノリスができる最高のデザインも、それがあることをちょうどはるかに少ない可能性があります。）

なぜ小さな部品が優れているのですか？彼らが推論するのが簡単だからです。また、正確性について推論するのが簡単な場合は、正しい結果が得られる可能性が高くなります。

CAR Hoareを引用するには：

ソフトウェア設計を構築する方法は2つあります。一つの方法は存在しないこと、それは非常にシンプルにすることです、明らかに無欠陥、および他の方法は、それがそう全く存在しないことを複雑にすることです明白な欠陥が。

もしそうなら、なぜ誰かが不必要に複雑な、またはモノリシックなソリューションを構築するのでしょうか？ホアは次の文で答えを提供します。

最初の方法ははるかに困難です。

その後、同じソースで（1980年のチューリング賞講演）：

信頼性の代償は、最大限のシンプルさを追求することです。それは、非常に金持ちが最も支払いが難しいと感じる価格です。

これは、「はい」または「いいえ」の回答を含む質問ではありません。問題はメンテナンスの容易さだけではなく、スキルの効率的な使用の問題でもあります。

一般に、適切に記述されたモノリシックアプリケーションは効率的です。プロセス間およびデバイス間の通信は安価ではありません。単一のプロセスを分割すると、効率が低下します。ただし、すべてを単一のプロセッサで実行すると、プロセッサが過負荷になり、パフォーマンスが低下する可能性があります。これが基本的なスケーラビリティの問題です。ネットワークが状況に入ると、問題はさらに複雑になります。

単一のサーバー上で単一のプロセスとして効率的に動作できる適切に作成されたモノリシックアプリケーションは、メンテナンスが容易で、欠陥がないように維持できますが、コーディングとアーキテクチャスキルを効率的に使用することはできません。最初のステップは、プロセスをライブラリに分割し、それらは同じプロセスとして実行されますが、結合と疎結合の規則に従って独立してコーディングされます。このレベルで良い仕事をすると、保守性が向上し、パフォーマンスにほとんど影響しません。

次の段階では、モノリスを個別のプロセスに分割します。難しい地域に入るため、これは難しくなります。競合状態エラーを導入するのは簡単です。通信のオーバーヘッドが増加するため、「チャットインターフェイス」に注意する必要があります。スケーラビリティの壁を破るので、見返りは大きいですが、欠陥の可能性も高まります。マルチプロセスアプリケーションはモジュールレベルでのメンテナンスが容易ですが、システム全体がより複雑でトラブルシューティングが困難です。修正は非常に複雑な場合があります。

プロセスが別々のサーバーまたはクラウドスタイルの実装に分散されると、問題はより困難になり、見返りは大きくなります。スケーラビリティが急上昇します。（スケーラビリティをもたらさないクラウド実装を検討している場合は、よく考えてください。）しかし、この段階で発生する問題は、特定して考え抜くことが非常に難しい場合があります。

いいえ。保守が容易になるわけではありません。何か問題があれば歓迎します。

どうして？

• プログラムは直交しておらず、合理的な範囲でお互いの作業を維持する必要があり、これは共通の理解を意味します。
• 両方のプログラムの多くのコードは同一です。共通の共有ライブラリを維持していますか、それとも2つの別々のコピーを維持していますか？
• これで2つの開発チームができました。彼らはどのように通信していますか？

• 次の2つの製品が必要です。

  • 共通のUIスタイル、相互作用メカニズムなどです。設計上の問題が発生しました。（開発チームはどのように再び通信していますか？）
  • 下位互換性（モデラーv1をアニメーターv3にインポートできますか？）
  • クラウド/ネットワーク統合（機能の場合）は、2倍の製品で更新する必要があります。

• モデラー、アニメーター、モデラーアニメーターの3つの消費者市場があります。

  • 優先順位が相反する
  • 対立するサポートニーズがあります
  • 競合する使用スタイルがあります
• Modeller Animatorsは、同じファイルで作業するために2つの別個のアプリケーションを開く必要がありますか？両方の機能を持つ3番目のアプリケーションがありますか。1つのアプリケーションが他のアプリケーションの機能をロードしますか？
• 等...

より小さなコードベースはアプリケーションレベルでのメンテナンスが容易であると言われているので、無料のランチを手に入れることはできません。これは、Micro-Service / Any-Modular-Architectureの中心にある同じ問題です。万能薬ではなく、アプリケーションレベルでのメンテナンスの難易度は、オーケストレーションレベルでのメンテナンスの難易度と引き換えになります。これらの問題は依然として問題であり、もはやコードベースにないため、回避するか解決する必要があります。

オーケストレーションレベルで問題を解決する方が各アプリケーションレベルで解決する方が簡単な場合は、2つのコードベースに分けてオーケストレーションの問題に対処するのが理にかなっています。

そうでない場合は、それをしないでください。アプリケーション自体の内部モジュール性を改善することで、より良いサービスが得られます。アプリケーションがプラグインとして機能するライブラリを、まとまりのある保守しやすいライブラリにプッシュします。結局、モノリスは図書館のランドスケープのオーケストレーションレイヤーにすぎません。

たくさんの良い答えがありましたが、ほとんど死んだスプリットがあるので、リングにも帽子を投げます。

ソフトウェアエンジニアとしての経験では、これは単純な問題ではないことがわかりました。それは実際に依存する大きさ、 規模、および目的のアプリケーションの。それらを変更するために必要な慣性のおかげで古いアプリケーションは、これが長い間一般的な慣行であったため、一般にモノリシックです（Mayaはこのカテゴリに該当します）。あなたは一般的に新しいアプリケーションについて話していると思います。

多かれ少なかれ単一の懸念である十分に小さいアプリケーションでは、多くの別個の部品を維持するために必要なオーバーヘッドは、一般的に分離を持つことの有用性を超えています。1人で保守できる場合は、多くの問題を引き起こすことなくモノリシックにできます。このルールの例外は、多くの異なる部分（フロントエンド、バックエンド、おそらくその間のいくつかのデータ層）が（論理的に）便利に分離されている場合です。

非常に大規模な単一の懸念アプリケーションでも、それを分割することは私の経験では理にかなっています。他の（場合によっては簡単に解決できる）バグと引き換えに、可能なバグのクラスのサブセットを減らす利点があります。一般に、生産性を向上させるために、単独で作業する人々のチームを持つこともできます。しかし、最近の多くのアプリケーションは非常に細かく分割されており、場合によっては独自の損害が発生しています。私はまた、アプリケーションが不必要に多くのマイクロサービスに分割されているチームに参加していたため、物事が互いに話をやめたときに多くのオーバーヘッドが発生しました。さらに、各パーツが他のパーツとどのように通信するかに関するすべての知識を保持しなければならないことは、連続するスプリットごとに非常に難しくなります。バランスがあり、ここの答えからわかるように、その方法は非常に明確ではありませんが、

UIアプリの場合、バグの全体的な量を減らすことはまずありませんが、バグミックスのバランスをコミュニケーションに起因する問題にシフトします。

ユーザー向けのUIアプリケーション/サイトと言えば、ユーザーは非常に非患者であり、短い応答時間を要求します。これにより、通信の遅延がバグになります。結果として、単一のコンポーネントの複雑さの減少によるバグの潜在的な減少と、非常に難しいバグ、およびプロセス間/マシン間の通信のタイミング要件とを交換します。

プログラムが扱うデータの単位が大きい場合（画像など）、プロセス間の遅延は長くなり、排除するのが難しくなります-「10mb画像に変換を適用する」のようなものは、即座に+ 20mbのディスク/ネットワークIOを追加で獲得しますインメモリ形式からシリアル化形式への変換、およびその逆。ユーザーからそうするために必要な時間を隠すためにできることは本当に多くありません。

さらに、すべての通信、特にディスクIOは、ウイルス対策/ファイアウォールチェックの対象になります。これにより、再現が困難なバグや遅延がさらに増えることになります。

モノリシックな「プログラム」の分割は、通信の遅延が重大でないか、すでに避けられない場合に効果的です

• 個々の手順を大幅に改善するためにわずかな余分な遅延を引き換えにできる情報の並列化可能な一括処理（市販の1回使用することでカスタムコンポーネントの必要性を排除することもあります）。個々のステップのフットプリントが小さいため、たとえば単一の高価なマシンではなく、複数の安価なマシンを使用できます。
• モノリシックサービスを結合度の低いマイクロサービスに分割-おそらく1つではなく複数のサービスを並行して呼び出しても、余分な遅延は追加されません（個々のサービスが高速で依存関係がない場合、全体の時間を短縮することさえできます）
• ユーザーが長時間かかると予想される操作を排除-複雑な3Dシーン/ムービーのレンダリング、データに関する複雑なメトリックの計算、...
• あらゆる種類の「オートコンプリート」、「スペルチェック」、およびその他のオプションの補助機能を外部にすることができます-最も明らかな例は、入力が常に外部サービス（検索エンジン）に送信されるブラウザーのurl自動提案です。

これは、デスクトップアプリとWebサイトに適用されることに注意してください-プログラムのユーザー向け部分は「モノリシック」になる傾向があります-単一のデータに関連付けられたすべてのユーザーインタラクションコードは通常、単一のプロセスで実行されます（分割することは珍しくありません） HTMLページや画像などのデータ単位で処理しますが、この質問とは直交しています）。ユーザー入力のある最も基本的なサイトでも、サーバー側をよりモジュール化し、複雑さ/コードの重複を減らしても、クライアント側で検証ロジックが実行されていることがわかります。

バグの防止に役立ちますか？

防ぐ？まあ、いや、そうでもない。

• バグの検出に役立ちます。
  つまり、自分が持っていることすら知らなかったすべてのバグは、その混乱全体を小さな部分に分割しようとしたときに初めて発見したものです。そのため、ある意味では、これらのバグが本番環境で出現することを防ぎましたが、バグはすでに存在していました。
• バグの影響を軽減するのに役立ちます。
  モノリシックアプリケーションのバグは、システム全体をダウンさせる可能性があり、ユーザーがアプリケーションとやり取りできないようにします。そのアプリケーションをコンポーネントに分割すると、ほとんどのバグは設計上、コンポーネントの1つにのみ影響します。
• 新しいバグのシナリオを作成します。
  ユーザーエクスペリエンスを同じ状態に保ちたい場合は、それらのすべてのコンポーネントが（RESTサービスを介して、OSシステムコールを介して、何を持っているか）通信する新しいロジックを含めて、ユーザーのPOVからシームレスに対話できるようにする必要があります。
  簡単な例として、モノリシックアプリを使用すると、ユーザーはアプリを離れることなくモデルを作成してアニメーション化できます。アプリを2つのコンポーネント（モデリングとアニメーション）に分割します。ユーザーはモデリングアプリのモデルをファイルにエクスポートしてから、ファイルを見つけてアニメーションアプリで開く必要があります...それに直面して、一部のユーザーはそのようなことをしないので、新しいロジックを含める必要がありますファイルをエクスポートするアプリをモデル化し、アニメーションアプリを自動的に起動し、ファイルを開きます。そして、この新しいロジックは、可能な限り単純ですが、データのシリアル化、ファイルのアクセスと許可、ユーザーがアプリのインストールパスを変更することなどに関して、多くのバグを抱えている可能性があります。
• 多くの必要なリファクタリングを適用するのに最適な言い訳です。
  モノリシックアプリをより小さなコンポーネントに分割することを決定した場合、システムが最初に設計されたときよりも多くの知識と経験を使用して（できれば）分割します。そのおかげで、多くのリファクタリングを適用してコードを作成できますよりクリーンで、シンプルで、効率的で、回復力があり、安全です。そして、このリファクタリングは、ある意味で、バグの防止に役立ちます。もちろん、同じリファクタリングをモノリシックアプリに適用して同じバグを防ぐこともできますが、UIの何かに触れてビジネスロジックを壊すのが怖いほどモノリシックなので、そうではありません¯\ _（ツ） _ /¯

ですから、モノリシックなアプリを小さなコンポーネントに分割するだけでバグを防いでいるとは言いませんが、バグを簡単に防げるポイントに到達しやすくしているのです。