如果您负责组织的代码库架构，那么如何以可扩展的方式管理这种增长的问题是您迟早要处理的问题。有两种常见的架构选项可供选择：一种是“多代码库”架构，我们将代码库划分为越来越小的代码库，以小团队或项目为界。另一个是“单一代码库”，它维护着一个庞大且不断增长的代码库，其中包含来自许多项目和库的代码，多个团队围绕这些代码库进行协作。多存储库方法看起来很容易实现，一开始可能很诱人，我们只是在需要时创建更多的存储库！我们几乎不需要任何特殊工具，并让每个团队更好地控制代码管理。极大的自主权。不幸的是，在实践中，多个代码库架构通常会导致代码库脆弱、不一致且难以更改。这反过来又助长了工程部门本身的孤岛。相比之下，单一代码库解决方案是一种更好、更灵活、更具协作性的长期扩展解决方案。为什么会这样？代码库架构中的困难部分涉及管理存在依赖关系的代码更改，反之亦然。在多存储库架构中，代码库通过发布的版本化工件使用来自其他代码库的代码；这使得传播更改变得更加困难。具体来说，当我们作为代码库A的所有者需要对我们正在使用的代码库B进行一些更改时会发生什么？首先，我们必须找到代码库B的看门人并说服他们接受并发布新版本的变更。然后，在理想情况下，有人会找到代码库B的所有其他消费者，将他们升级到这个新版本，然后重新发布。现在我们要找到那些原始用户的用户，升级和重新发布新版本，等等，等等。但是谁来做所有这些工作呢？他们将如何找到所有这些消费者？毕竟，依赖元数据驻留在消费者端，而不是消费者端，并且没有简单的方法来追溯依赖关系。当问题的归因不直接且解决方案不明显时，它往往会被忽略，因此实际上不会发生回溯工作。这可能在短时间内无关紧要，因为其他代码库固定在早期版本的依赖项上。但这种舒适的状态是不可持续的，因为迟早会有一些消费者被集成到一个可部署的工件中，并且有人将不得不为工件选择单一版本的依赖项。因此，我们最终会遇到由过去的团队引起的传递版本冲突，它就像一颗埋在代码库中的定时炸弹，如果其他团队需要将代码集成到生产环境中，就会爆炸。如果这个问题看起来很眼熟，那是因为它是臭名昭著的“依赖地狱”问题的内部版本，这个问题经常困扰着代码库的外部依赖。在多代码库架构中，第一方依赖项在技术上被视为第三方依赖项，即使它们恰好由同一组织编写和拥有。所以，如果是多代码库架构，我们基本上会选择面临大规模扩展的依赖地狱。一个单一的代码库则相反：所有的消费者都在同一个源代码树中，所以找到它们就像使用grep一样容易。并且由于没有发布步骤，所有代码共享一个版本（由当前提交表示），因此以传递和同步的方式更新消费者简单直观。如果我们有良好的测试覆盖率，那么我们什么时候做对了就很清楚了。当然，“简单直观”并不等同于“容易”：同步升级代码库本身可能并不容易。但这就是代码更改的本质。没有任何代码库架构可以消除工程问题中不可简化的部分。但是单一的代码库至少迫使我们现在摆脱必要的困难，这样我们就不会在以后造成不必要的困难。多代码库架构倾向于在未来将依赖地狱外化给其他人，这是与康威定律相关的一个更广泛的问题：“任何设计系统的组织都会开发一种设计，其结构与组织沟通结构齐头并进。”反之亦然：一个组织的结构通常是这种沟通所围绕的结构的副本。在这种情况下，支离破碎的代码库架构会促进工程部门本身内部的支离破碎，而代码库设计最终会离开具有独立门槛和责任的组织，而不是共同努力实现未在架构上表达的共同目标。单一代码库以温和的方式实现并实现组织统一：每个人都在单一代码库上协作，这正是沟通渠道组织需要成功构建一个统一的产品。单一的代码库不是万能的。它也确实需要正确的工具和流程来保持性能规模和工程有效性。但是有了正确的架构和工具，您可以确保您的代码库和组织具有凝聚力并在规模上蓬勃发展。原标题：Themonorepoapproach到代码管理，作者：BenjyWeinberger
