Visual Studioで複数のプロジェクトに単一のソリューションを使用すると「相互依存の複雑さが増す」と開発チームが主張するのはなぜですか。
既存の製品の新しいバージョンを開発し始めている外部チームの管理を支援しています。歴史的に、このチームは常に、単一のソリューションの単一プロジェクトのモデルをVisual Studioの約30のモジュールに使用しており、これらを組み合わせてデプロイ可能なビルドを作成してきました。
これはビルドの信頼性と品質に有害な影響を及ぼします。なぜなら、常に最新のソースコードを送信するわけではないからです。すべての参照コードを単一のソリューションに統合するためにそれらを押し付けようとしていますが、いくつかの抵抗を得ています-特に、すべてが配置されている場合、モジュール間の相互依存関係（Visual Studioの「プロジェクト」の読み取り）の増加について話し続けています単一のソリューションファイル。別のソリューションのコードは他では使用されません。
これはナンセンスであり、良い開発パターンはそのような問題を回避すると主張します。
問題のチームはまた、既存の製品のバグ修正と新機能の開発も行います。その経験は控えめに言っても過不足がなく、複数のソリューションに分割するというまったく同じ問題に悩まされています。ソース管理へのアクセスは拒否されました（ [〜＃〜] tfs [〜＃〜] ）。コードベースを統一するために取っているアプローチは、 「ソリューションフォルダ全体のZipを送信して、解凍してVisual Studioで開き、押すことができるようにしてください。 F5 一般的な構造と品質の点で、コードはかなり貧弱でサポートが困難です。この経験が、開発プロセスのできるだけ早い段階で作業プロセスを正しくすることに専念している理由です。
行方不明のものはありますか？そのすべてのコードを分離しておく正当な理由はありますか？私のお金については、それが常識になるほど説得力のある理由でなければならないでしょうが、私はすべてを知っているわけではないことを認めたいと思っています。
彼らに彼らのプロジェクトをどのように構成するかを教える必要はありません。代わりに、1つのスクリプトを実行して、エラーが発生することなく、ソースからシステムを構築できるようにすることが難しい要件になります。そのスクリプトがVisual StudioまたはMsbuildまたはその他のツールを実行する場合、およびそれらが1回呼び出される場合、50回または100回は問題になりません。
これにより、すべてを1つのソリューションにまとめた場合と同じように、コードの「完全性のテスト」を行うことができます。もちろん、そのスクリプトは、チームがソース管理から最新バージョンを本当にチェックアウトしたかどうかを通知しませんが、1つのソリューションにコード全体を含めても、チェックされません。
への返信として、「すべてが単一のソリューションファイルに配置されている場合、モジュール間の相互依存性が増加します」-これは証明可能ですナンセンス、プロジェクトをソリューションに追加してもプロジェクト間の依存関係は変更されないため、依存関係は別のプロジェクトファイルを参照する結果であり、どのソリューションがどのプロジェクトファイルを参照するかとは完全に独立しています。すべてのプロジェクトを参照する単一のソリューションと、それぞれが1つのプロジェクトのみを参照する個々のソリューションの両方をチームが止めることはありません。
それにもかかわらず、ビルドスクリプトを追加することをお勧めします。これには、ソリューションファイルが1つしかない場合でもメリットがあります。たとえば、適切な構成でVSビルドを実行し、展開用の最終ファイル（およびそれ以上）を「展開」フォルダーにコピーし、他のツールや手順を実行してビルドを完了することができます。 F5はビルドプロセスではありません！ および The Joel Test も参照してください。
コンパイルされたアセンブリが再利用される量に依存します。アセンブリの再利用がない場合、「モジュール」を分離しておく本当の理由はありません。実際のところ、私の経験では、これは妨げになっています。
開発チームでは、複数の製品で個別のソリューションとして使用される独立したライブラリーを作成しています。この場合、アプリケーションBを最新の状態に保つためにアプリケーションAをコンパイルする必要があります。これは、アプリケーションCを最新の状態に保つために必要になる場合があります。
製品を構成するプロジェクトが複数ある場合でも、各製品は独自のソリューションに保持されます。この方法では、ライブラリソリューションを構築するだけで、すべての開発済み製品で共有コードを最新の状態に保つことができます。
私がこれまで働いたすべてのソフトウェア会社には、会社の製品の基本的なユースケースをカバーするヘッドブランチを提供するコア開発チームがいました。
コアリポジトリを使用するブランチ開発者は、改善を発見し、レビューのためにヘッドブランチにプルリクエストを送信する責任があります。通常、これはコア開発者になる方法であり、建築紛争の炎を扇動するだけでなく、より良い貢献をすることができることを示します。
あなたの会社には、すぐに「参照されたすべてのコードを単一のソリューションに統合する」ためのリソースがないだけの可能性があります。予算の制約を理解せずにそうすることを提案すると、（少なくとも）コアエンジニアになることが妨げられる可能性があります。
ですから、コアに対するいくつかの破壊的なプルリクエストにあなたのグランドビジョンを組み入れ、レビューであなた自身を守る準備をしてください！
「複数のプロジェクトに単一のソリューションを使用すると相互依存の複雑さが増す」という主張には、真実の核があります。
単一のソリューションは、他のプロジェクトからプロジェクトを参照することを容易にします（つまり、プロジェクトのコードを再利用して、別名「相互依存の複雑さの導入」）を簡単にします。
- 参照されているアセンブリのファイルシステム/グローバルアセンブリキャッシュ全体を参照する代わりに、ソリューション内の関連プロジェクトの限定されたセットからプロジェクトを選択できます。そして、
- ソースコードを読み取るときは、任意の（バイナリ）アセンブリに比べて、ソリューション内の参照プロジェクトにジャンプする方がはるかに簡単です。
そのため、単一のソリューションで複数のプロジェクトを使用する、規律のないチームの手に渡ると、不注意に導入された依存関係が多数発生する可能性があります。ただし、チームは依存関係を注意深く管理するために必要な規律を学習し、ソリューションを使用して提供される再利用の容易さを利用することをお勧めします。