Monorepo是个坏主意

2020-10-24 08:10:38

业界有这样一个概念,所有成功的公司都使用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,你不会成为下一个谷歌。但是你肯定会给你的项目带来很多挑战,除非你有一些来自大公司的工程师有如何处理这些挑战的经验(顺便说一句,这就是一些小公司以单一订单告终的方式)。