当数百名开发人员正在开发一个解决方案时的开发方法？

我们是一个由大约200名开发人员组成的组织，他们正在不断开发单个产品（使用版本控制Git），并计划在某个日期发布该产品。

由于开发人员数量众多，我们正在尝试创建“跨职能”团队，每个团队中约有10个开发人员，因此组织中大约有20个开发团队。

由于我们希望在主存储库中保持产品的连续“高标准”（意味着当开发人员进行拉动时，产品至少应是可编译的，等等），因此我们想使用某种质量保证。

我不太确定如何表达这个问题，但是我想知道是否可以为如此大量开发单个产品的开发人员提供一些开发方法的建议。

我们认为，范围的一端是允许每个开发人员直接提交到主存储库，但是我们担心由于开发人员/提交的数量过多，“主存储库”可能一直处于崩溃状态，这是由于我们不能为每次提交都提供苛刻的“质量门”。

频谱的另一端可能像是树或金字塔结构（我们认为是Linus Torvalds / Linux做到了），其中“主存储库”仅具有三个拉取源，这三个仅具有少数受信任的拉取源，依此类推但是，我们认为，采用这样的结构，为了进入“主存储库”，更改需要爬很长的链。另外，如果发生合并冲突，问题将落在“原始开发人员”之外的其他开发人员上。

陈述了所有这些背景信息和意见后，我们如何才能学习和阅读针对众多开发人员的推荐开发方法？大型组织（Microsoft，Facebook，Ubuntu等）如何组织其发展？

您当然应该考虑与接口团队将产品分成模块，将这些组成模块整合到一个产品中。反过来，这将意味着拆分存储库以匹配模块分区和层次结构。如果您似乎无法做到这一点，那么考虑到贡献的开发人员数量，该项目可能会陷入合并导致的停顿。

如果您打算使用Git进行版本控制，那么我建议您使用代码检查系统（例如Gerrit）来提高透明度并确保每个存储库的质量。这样，所有工作都必须先获得批准，然后才能合并到任何权威存储库中。在这种情况下，授予某些受信任的个人从代码审查系统下的存储库到另一个存储库（也可能是代码审查系统下）的权限是有意义的。如果正确使用，这将是一个快速且非常有益的过程，并且不会阻碍开发过程。

关于构建验证，您需要一个持续集成（CI）服务器，其目的是自动构建和验证代码。验证代码是指代码成功编译并通过测试。Infact Jenkins（CI Server）可以作为Gerrit验证阶段的一部分链接到Gerrit代码检查系统，从而使流程完全自动化。

除了这些集成工具外，重要的是要努力将频繁的集成作为开发方法的一部分，以最大程度地减少合并时间。

也许值得考虑像Scrum这样的敏捷开发过程，其目的是将复杂的产品分解为可管理的产品增量块（称为Sprint）。这些将提供存储库之间的集成机会。

显然，拥有200人的开发团队，您必须具有某种层次结构。一个人或一小群人就软件产品的设计做出决定。您的开发过程应反映出这一点：您需要进行代码审查和测试，以确保所创建的软件确实与您想要创建的软件相匹配（以及出于质量目的）。

即使是小型团队，也需要领导者来指导团队并在开发单个组件时回顾其工作。他们也应该在团队一级建立质量控制流程。

因此，是的，您应该遵循关于存储库的层次结构。这是为了匹配项目整体的层次结构。

在考虑将所有组件放在一起之前，应该构建并测试各个组件是否达到一定程度的适当性。允许200个人直接参与主要项目将是混乱的。对于每个组，您应该有单独的区域，个人可以在其中进行更改，而又不影响项目的主体结构。

如果“变更要爬进长长的链条才能进入主存储库”，这是一件非常好的事情，因为该链条可以确保质量。如果所有更改都立即应用到主存储库，这似乎会更快，但是实际上，这将是一个巨大的麻烦，因为您将不断遇到错误且无法使用的软件主版本。

“如果发生合并冲突，则问题将落在另一位开发人员上”也是一件好事，具体来说，应该由更高级别的开发人员来决定如何解决冲突。

当您拥有大件东西（结果是）难以管理时，解决之道就是将其分成较小且可管理的部分。

有几个步骤可以帮助您更好地维护团队和项目：

1. 将功能划分为模块。应使用高内聚性，低耦合性和依赖性反转原理将功能划分为最大的独立模块。第一条原则将帮助您创建逻辑上一致的模块。第二个将帮助保持这些模块尽可能独立。第三个将帮助同时开发依赖的模块（如果模块A依赖于模块B，则即使B尚未完全准备就绪，B也应提供A可以使用的接口）。

2. 有清晰的文档。当有这么多人一起工作时，事情很容易被忘记或误解。因此，您需要特别注意从需求到体系结构解决方案的所有文档。

3. 以人为本的任务（永远不要以人为任务）。将功能划分为较小的集合后，请创建团队来处理这些集合。在此阶段创建团队会更容易，因为您已经知道每个团队要从事的工作。诸如代码审查之类的任务将在每个团队内部完成。

4. 清晰的任务系统。200个开发人员中的每一个都应该清楚地知道该做什么。这将帮助您跟踪已完成的工作，每个人在做什么以及剩下多少工作。

5. 源代码管理。（我认为这在其他答案中也有很好的概述））

最后，尝试创建尽可能简单的团队和模块结构。如此庞大的项目无法承受复杂性。

除了暗示分层结构的其他答案外，这还意味着您必须安排“集成”时间点，这些时间点的重点是完全将代码移到层次结构中并“将其全部组合”。这与具有最后阶段的较小项目没有什么不同，在最后阶段，除了测试和错误修复以外，没有其他工作要做，只是更频繁地进行。由于您是一个为追求高标准而努力的团队，因此大多数（思维框架）可能已经就位。

除了hotpotato的答案（直接在恕我直言上标记）之外，我还建议您实现一些源代码控制门。当我们将庞大的团队和代码库迁移到git进行SCM时，我们决定使用所谓的“仁慈独裁者”方法，与您描述的模型类似。

在这种情况下，完整代码库的许多分支都从其源分支定期进行更新，但是将代码提升到可见/公共区域的责任由一个人（或一小群人）承担，通常是与代码审查过程相关。借助组织良好的分支结构，它可以很好地工作。有关更多信息，请查看此链接。

我开发了一个庞大的系统，其中有数百名开发人员同时使用约1.5亿个SLOC进行开发。这是在大型机上，因此我们不是在谈论Visual Studio，但是原理仍然可以采用。

首先，如果您使用的是Java，我肯定会说使用Maven。如果您使用的是VS，那么您也可以使用Nuget，尽管我不确定Maven是否已经安装了它（这也有所不同）。使用这样的系统将使您能够提取依赖项并使它们独立运行。您将拥有一个构建脚本来提取相关的依赖项并进行批量构建。

鉴于您不是直接提出问题，而是要求提供一种方法，我将告诉您前任雇主是如何处理的。

该系统被分解为集群。集群代表业务领域和系统基础架构领域。我不会说出它们的名字，但是对于一个庞大的零售企业，您可能会想到诸如营销，零售运营，在线运营，采购，分销之类的东西。系统基础架构代表了诸如客户和安全性之类的事物。在每个群集中，都有一些组件。使用前面的类比，您可以考虑安全性组件，例如，单点登录，目录服务，审计，报告等。每个组件中都存储有其相对例程。

例如，作为名称空间或包，您将拥有Organisation.Security.DirectoryServices。通过将所有逻辑包含在其相关区域中，团队可以相当自主地工作。显然，发生了需要多个团队投入的大型项目，但是它们基本上是平稳的运营。

我希望这有帮助。