为什么开发团队会坚持认为在Visual Studio中对多个项目使用单个解决方案会“增加相互依赖的复杂性”？

我正在帮助管理一个外部团队，他们正在开始开发某些现有产品的新版本。从历史上看，该团队一直在单个解决方案中使用单个项目的模型来处理Visual Studio中的大约30个模块，这些模块一起产生可部署的内部版本。

这会对构建可靠性和质量产生不利影响，因为它们并不总是向我们发送最新的源代码。我们试图让他们将所有引用的代码统一到一个解决方案中，但是我们遇到了一些阻力-特别是他们一直在谈论如果将所有内容都放置在模块之间，模块之间的相互依赖性（在Visual Studio中为“项目”）会增加。一个解决方案文件。单独解决方案中的代码均未在其他地方使用。

我坚持这是胡说八道，良好的开发模式将避免任何此类问题。

有问题的团队还对现有产品进行错误修复和新功能开发，至少可以说，其经验不足以解决多个解决方案的完全相同的问题。我们一直被拒绝访问其源代码管理（TFS），而我们采用的统一代码库的方法是尝试并至少减少丢失的更新数量，而不是偶尔进行回归（是的，固定的错误正越来越-产品介绍），说“向我们发送整个解决方案文件夹的ZIP文件，这样我们就可以解压缩，在Visual Studio中打开它，然后按F5 “用于测试”。在总体结构和质量方面，该代码非常差且难以支持。这种经验就是为什么我希望尽可能早地在开发周期中使工作流程正确。

有什么我想念的吗？是否有充分的理由将所有代码分开？为了我的钱，它必须是一个令人信服的理由，这将是常识，但是我更愿意承认我并不了解一切。

您无需告诉他们如何构建项目。相反，这是一个严格的要求，您可以通过运行一个脚本从源代码构建系统，而不会出现任何错误。如果该脚本运行Visual Studio或Msbuild或某些其他工具，并且被调用一次，则50或100次无关紧要。

这样，您将获得与将所有内容放入单个解决方案中相同的代码“完整性测试”。当然，该脚本不会告诉您团队是否真的从源代码管理中签出了最新版本，但是将整个代码包含在一个解决方案中也不会进行检查。

至于回复“如果一切都被放置在一个单一的解决方案的文件正在增加模块之间的相互依存关系” -这是proveable废话，因为增加项目的解决方案不会改变任何项目之间的依赖关系，依赖关系是从一个项目的结果文件引用另一个，这完全独立于哪个解决方案引用哪个项目文件。没有人会阻止团队同时拥有这两者-一个引用所有项目的解决方案，以及每个引用一个项目的单独解决方案。

不过，我建议添加一个构建脚本。即使只有一个解决方案文件，这也有好处。例如，它允许使用首选配置来运行VS构建，使您可以将要部署的最终文件（仅此而已）复制到“ deploy”文件夹中，并且可以运行其他工具和步骤来完成构建。另请参见F5不是构建过程！和Joel测试。

这将取决于已编译程序集的重用量。如果没有重复使用程序集，则没有真正的理由将“模块”分开。实际上，这更多是一个障碍。

在开发团队中，我属于我们的一部分，我们已经编写了独立的库，这些库在多个产品中用作单独的解决方案，在这种情况下，这样做很有意义，否则我们必须编译应用程序A才能使应用程序B保持最新状态，为了使应用程序C保持最新状态，可能需要这样做。

每个产品都保存在自己的解决方案中，即使有多个项目构成该产品。这样，我们只需构建库解决方案即可在所有开发的产品中保持其共享代码为最新。

我曾经工作过的每个软件公司都有一个核心开发团队，该团队提供了涵盖公司产品基本用例的分支机构。

使用核心存储库的分支开发人员负责发现改进并向主分支提交拉取请求以进行审查。通常，通过证明一个人可以做出比仅仅煽动架构冲突的火焰更好的贡献，这就是成为核心开发人员的方式。

您的公司很可能没有足够的资源立即“将所有引用的代码统一为一个解决方案”。暗示他们这样做（至少）不了解预算约束很可能会阻止他们成为核心工程师。

因此，将您的远见卓识化为对核心的一些毁灭性拉动请求，并准备在审查中捍卫自己！

断言“对多个项目使用单个解决方案会增加相互依赖性的复杂性”，这是事实的核心。

一个单一的解决方案使从另一个项目中引用一个项目变得容易（例如，重用一个项目的代码，也就是“引入相互依赖的复杂性”）：

• 您可以从解决方案中有限的一组相关项目中选择一个项目，而不必浏览整个文件系统/全局程序集缓存中所引用的程序集；和，
• 读取源代码时，跳转到解决方案中的引用项目比跳转到任意（二进制）程序集要容易得多。

因此，在一个无纪律的团队的手中，在一个解决方案中使用多个项目可能会导致大量不慎引入的依赖关系。但是，团队可以更好地尝试学习必要的规程，以仔细管理依赖项，然后利用解决方案提供的易用性进行重用。