1

通常在开始一个新项目时，我会从我认为在如何构建代码库方面最好的意图开始。我喜欢许多小模块的想法，这些模块可以很好地完成一件事，与代码库的其他部分解耦，并且我自己可能会在其他（类似）项目中重用或开源以供其他人利用。

然而，当我真正尝试将某些东西投入生产时，在紧要关头的那一周，管理所有这些不同模块的复杂性已被证明是一种过多的开销（尽管有良好的文档和部署方法）。在那些时候，我只是简单地改变了策略并将所有模块捆绑到一个存储库中，并将它们作为一个代码库进行管理，这意味着我可以通过不同的分支一起跟踪所有内容，部署到登台和测试环境等......

这些不同方法的优点和缺点是什么，您如何管理以一种或另一种方式工作？

一个单一代码库的优点：

  • 易于部署
  • 易于回滚
  • 易于分支/管理所有更改
  • 没有（或更少）需要记录和管理的潜在复杂依赖项

模块化依赖的优点：

  • 可重用性
  • 干净的架构（一个模块做好一件事）
4

2 回答 2

2

我没有像你那样看到对立面。以 .NET 体验为例，我可以确保我的部分代码面向明确定义的职责，我可以将我的代码库构建为命名空间，确保命名空间的接触点定义明确，并且同一命名空间中的类真的是在一起的。

但是，所有这些都可能发生在单个部署单元、单个项目、分支中，你有什么。如果你坚持这一点，那么在你所做的项目的上下文中可能变得可重用的代码单元将会具体化，这将是你决定引入一个新的代码单元的点，它有自己的部署工件，源代码控制分支， ETC。

于 2009-02-01T13:14:11.600 回答
0

这是来自Google 的演讲，解释了（一点点）他们如何处理庞大的单体代码存储库。以及为什么他们有一个。

顺便说一句，我认为它不必与定义明确的依赖关系集相对。我什至会说，要处理一个单一的代码库，你必须非常小心依赖图和职责。因为有了这种组织，很容易添加很多或多或少有用的部门……</p>

于 2015-09-28T13:00:46.337 回答