Monorepo是个坏主意

业界有这样一个概念，所有成功的公司都使用Monorepos，所以要想像他们一样成功，你的公司也应该如此。

然而，事实是，没有一家大公司选择使用Monorepo。他们就这样结束了，现在无法摆脱这场纠葛。那么，除了把Monorepo的想法作为一个成功的故事卖给你，让你喝下Kool Aid之外，他们还有什么选择呢？

不可否认，像Facebook、Google和Twitter这样的公司是成功的。但这并不是因为它们，而是因为它们。事实上，他们都拥有一整套才华横溢、一流的工程师团队，仅仅是为了处理Monorepo遗产带来的复杂问题。而Monorepo只是一件美化的遗产文物。

在接下来的文章中，我想分析一下拥有单一回购的一些所谓的“优势”。

“对于多个存储库，您必须定义什么是项目。Monorepo只是持有您公司的整个代码库。“。

为了清楚起见，您希望强迫自己定义项目是什么，如果它们是相关的，为什么它们是相关的。如果您不确定您的项目在做什么，那么可能出了问题。

“因为VCS太大或有太多历史记录而不得不拆分项目并不是最佳方案。”

拆分大型项目是绝对必要的。大项目只意味着大混乱。如果你的项目的历史对于VCS来说太大了，那么你的麻烦就更大了。

使用Monorepo，您可以用任何逻辑上最一致的方式将项目组织和分组在一起，而不仅仅是因为您的版本控制系统迫使您以特定方式进行组织。

我的VCS，过去5年的GitHub，从来没有“强迫”我做过什么(尽管有一次它差点说服我收养一只小猫)。

但是，组织项目最符合逻辑的方式是…。每个项目的存储库。而不是把所有东西都混在一起的储存库。

只有当你所有的东西都是用单一语言写的时候，这才是真的。你真的认为有一种语言可以满足你所有的需求吗？

如果您的项目中有一种以上的语言(大多数公司都会这样做)，这种优势是站不住脚的。

如果您使用的是GitHub/GitLab之类的工具，那么这个论点是无效的。在GitHub/GitLab中，您可以将项目组织到组织中，给项目贴上标签，并能够搜索您的代码。

如果您使用的是Git或其他…。回到2005年，那里的情况如何？

不过，说真的，我已经养成了在每个GitHub存储库上至少放两个标签的习惯，告诉他们它属于哪个团队和部门(如果你是一家真正的大公司，就属于哪个部门)。

如果您的微服务很难设置或测试，这并不是因为您没有使用monorepo。这是因为您没有投资于使其易于运行和测试。

花几天时间完成一份好的自述文件，一份Dockerfile和一份Docker。将维护它们作为优先事项。

“对于多个存储库，您必须在它们之间建立版本依赖关系。大多数解决方案都很麻烦，而且涉及大量管理费用。“。

依赖是很难的。莫诺雷波解决不了这个问题。然而，monorepo所允许的是破解您不拥有的代码，并且不知道它是如何工作的。

使用语义版本控制。引入更改时，请花几分钟时间考虑它们是否向后兼容。没有什么“灵丹妙药”可以解决这个问题。

这与前一点有关。这实际上意味着，monorepo允许您同时中断多个项目，而不是中断一个项目。耶！

构建工具--在某种程度上，传统的构建工具，无论是Maven、NPM、Gradle还是Go Build，要么变得太慢，要么干脆停止工作。您将不得不改用特殊的构建工具，如Bazel或Lerna，与传统工具相比，它们的使用率要低得多，因此文档也少得多。

风投支持--大多数大公司都在使用自己的风投分叉，仅仅是为了维护大量的文件。我采访过的一家公司甚至非常自豪，他们雇佣Git贡献者就是为了这个目的。

CI/CD-最常用的CI工具，如CircleCI/TravisCI，围绕每个Repo单个项目的概念构建。一定要和他们说再见，准备好要么回到Jenkins怪兽世界，要么甚至“更好”地建立自己的CI。别忘了把CD放在上面。

如果你改用monorepo，你不会成为下一个谷歌。但是你肯定会给你的项目带来很多挑战，除非你有一些来自大公司的工程师有如何处理这些挑战的经验(顺便说一句，这就是一些小公司以单一订单告终的方式)。