開発チームがVisual Studioの複数のプロジェクトに単一のソリューションを使用すると「相互依存の複雑さが増す」と主張するのはなぜですか？

既存の製品の新しいバージョンの開発を開始している外部チームの管理を支援しています。これまで、このチームは、展開可能なビルドを作成するために連携するVisual Studioの約30のモジュールに対して、単一のソリューションで単一のプロジェクトのモデルを常に使用していました。

これは、ビルドの信頼性と品質に有害な影響を及ぼします。常に最新のソースコードが送信されるとは限らないためです。すべての参照コードを単一のソリューションに統合するためにそれらを押すことを試みていますが、いくつかの抵抗があります-特に、すべてが配置されている場合、モジュール間の相互依存性（Visual Studioの「プロジェクト」を読む）が増加していることについて話し続けています単一のソリューションファイル。別のソリューションのコードは他で使用されていません。

これはナンセンスであり、優れた開発パターンはそのような問題を回避するだろうと私は主張します。

問題のチームは、既存の製品のバグ修正と新機能の開発も行いますが、その経験は控えめに言っても不十分であり、複数のソリューションに分割するというまったく同じ問題に苦しんでいます。ソース管理（TFS）へのアクセスを拒否されました。コードベースを統一するために取っているアプローチは、欠落している更新の数を減らし、時々発生する回帰よりも少なくすることです（はい、修正されたバグが再取得されています） -製品に導入されました）「ソリューションフォルダー全体のZIPを送信して、解凍し、Visual Studioで開き、F5 一般的な構造と品質の観点から、コードはかなり貧弱でサポートが困難です。この経験から、開発サイクルのできるだけ早い段階で作業プロセスを正しくしようと考えています。

私が見逃しているものはありますか？すべてのコードを分離しておく正当な理由はありますか？私のお金のために、それは一般的な知識になるほど説得力のある理由でなければなりませんが、私はすべてを知らないことを喜んで認めています。

プロジェクトをどのように構成するかを伝える必要はありません。代わりに、1つのスクリプトを実行して、エラーを発生させることなく、ソースからシステムを構築できることを厳しい要件にします。そのスクリプトがVisual StudioまたはMsbuildまたはその他のツールを実行し、それらが1回呼び出された場合、50回または100回は問題になりません。

そうすれば、すべてを単一のソリューションに入れることで得られるのと同じコードの「完全性のテスト」が得られます。もちろん、このスクリプトでは、チームがソース管理から最新バージョンを実際にチェックアウトしたかどうかはわかりませんが、コード全体を1つのソリューションに含めてもチェックされません。

応答として、「すべてが単一のソリューションファイルに配置されている場合、モジュール間の相互依存が増加している」 -これはproveableナンセンス、プロジェクト間の依存関係のいずれかを変更しないソリューションにプロジェクトを追加するので、依存関係の1つのプロジェクトからの結果であり、別のプロジェクトを参照するファイル。これは、どのソリューションがどのプロジェクトファイルを参照するかから完全に独立しています。すべてのプロジェクトを参照する単一のソリューションと、各プロジェクトが1つのプロジェクトのみを参照する個別のソリューションの両方を持つように、そのチームを止めることはできません。

それでも、ビルドスクリプトを追加することをお勧めします。これには、ソリューションファイルが1つしかない場合でも利点があります。たとえば、優先構成でVSビルドを実行し、展開用の最終ファイル（およびそれ以上）を「展開」フォルダーにコピーできます。また、ビルドを完了するために他のツールと手順を実行できます。参照してくださいF5は、ビルドプロセスではありません！、およびジョエルテスト。

コンパイルされたアセンブリが再利用される量に依存します。アセンブリの再利用がない場合、「モジュール」を分離しておく本当の理由はありません。私の経験では、これはより大きな障害です。

開発チームでは、複数の製品で個別のソリューションとして使用される独立したライブラリを作成しています。この場合、アプリケーションAをコンパイルしてアプリケーションBを最新の状態に保つ必要があります。アプリケーションCを最新の状態に保つために必要になる場合があります。

製品を構成する複数のプロジェクトがある場合でも、各製品は独自のソリューションに保持されます。このようにして、開発されたすべての製品で共有コードを最新の状態に保つために、ライブラリソリューションを構築するだけで済みます。

私が働いていたすべてのソフトウェア会社には、会社の製品の基本的なユースケースをカバーするヘッドブランチを提供するコア開発チームがありました。

コアリポジトリを使用するブランチ開発者は、改善を発見し、レビューのためにヘッドブランチにプル要求を送信する責任があります。これは、通常、コア開発者になる方法です。アーキテクチャの競合の炎を単に扇動するよりも優れた貢献ができることを示すことによって。

貴社には、ただちに「参照されているすべてのコードを単一のソリューションに統合する」ためのリソースがない可能性があります。予算上の制約を理解せずにそうすることを提案することは、（少なくとも）コアエンジニアになることを妨げる可能性があります。

そのため、コアに対するいくつかの壊滅的なプルリクエストにグランドビジョンを策定し、レビューで身を守る準備をしてください！

「複数のプロジェクトに単一のソリューションを使用すると相互依存の複雑さが増す」という主張には真実の核があります。

単一のソリューションにより、他のプロジェクトからプロジェクトを参照する（つまり、「相互依存の複雑さを導入する」プロジェクトのコードを再利用する）ことが簡単になります。

• 参照アセンブリのファイルシステム/グローバルアセンブリキャッシュ全体を参照する代わりに、ソリューション内の関連プロジェクトの限られたセットからプロジェクトを選択できます。そして、
• ソースコードを読み取る場合、任意の（バイナリ）アセンブリよりもソリューション内の参照プロジェクトにジャンプする方がはるかに簡単です。

したがって、単一のソリューションで複数のプロジェクトを使用する無秩序なチームの手に渡ると、不注意に多くの依存関係が発生する可能性があります。ただし、チームは、依存関係を慎重に管理するために必要な規律を学習し、使用ソリューションが提供する再利用の容易さを活用することをお勧めします。