Jin's blog

Monorepo 的价值

前端Monorepo

最近又开始研究起 monorepo 了,背景是组内的虽然已经从 multi-repo 转到 monorepo 两年多,但是因为长期没有人治理,所以还是有很多问题。最近我们方向把这摊子事情整个接过来了,所以需要再深入思考一下这件事。

  • 本文所描述的只是前端场景下的 monorepo,其他场景下的 monorepo 本文不做讨论。
  • 本文是我在研究 monorepo 的过程中的一些思考/总结,所以可能会有一些错误的地方,欢迎指正。
  • 后续有任何新的想法,我会在本文中更新,✏️ Last update: 2024/01/20

multi-repo(poly-repo) 的问题

简单说说 multi-repo 的问题,因为重点还是要聊 monorepo 的价值。

先整理这些痛点问题吧,别的问题可以没这些问题这么直观。

monorepo 能解决什么

我们可以从两个角度来看待 monorepo 的价值。

1. 团队角度

统一基础设施

对团队来说,monorepo 最大的价值是基础设施的统一,通过统一所有的基础工具链,来降低所有工程师的研发成本,这里的基础设施包括但不限于:

在这些基础设施统一之后,团队的研发效率会显著提升,因为大部分的工程师都不需要再去关心这些基础设施的事情,避免大家重复造一些 infra 的轮子,可以专注于业务的开发。

而在 multi-repo 的情况下,每个 repo 都有自己的基础设施,这就导致了每个 repo 都需要维护自己的基础设施,这样就会导致团队的研发效率降低。从我个人的工作经验来开,这部分的开销是不小的,因为每个人都会觉得自己的方案会更好(都有造轮子的心,但是造出来不一定比别人的好🤣)。

项目依赖全局唯一

在 monorepo 的情况下,项目之间的相互依赖不再依靠 npm 包,而是直接依赖于项目本身,这样就可以保证项目之间的依赖是全局唯一的。

全局唯一后,内部依赖的升级就可以有更全面的覆盖,而不是像 multi-repo 的情况下,每个项目都需要自己去升级依赖,这样就会导致依赖升级的工作量成倍增加。

同时因为 monorepo 的架构,依赖在做升级的时候也可以很方便的分析出依赖的影响范围,这样就可以更好的控制风险。

当然,这又侧面的要求了内部依赖的代码质量,因为统一的内部依赖版本会导致风险会暴露更快,所以代码质量也必须更高。不过在 multi-repo 的情况下,不是说这个风险就不存在了,只是因为依赖升级需要每个项目都去做,所以会暴露得更慢一些而已。

理论上做到更极致的点是做到底层依赖的全局统一,如 lodash, react 等等,这样可以更好的解决依赖升级、代码重否构建以及技术债务的问题(当然成本也相对较高,尤其是在第一次统一时)

公共依赖的代码质量重视程度被加强

在 multi-repo 的情况下,公共依赖项目的单测往往会被忽略,在 multi-repo 下,因为是以 npm 包的形式发布,所以一些问题不会立即暴露出来,且公共依赖常常会让业务自己升级的时候去做人工测试,这样就导致公共依赖项目的单测往往会被忽略。而且更恶劣的情况是,在很长时间不升级后,业务方宁愿自己去 fork 一个老的版本做一些修改,也不愿意去升级公共依赖项目,因为风险实在太大了。

但是在 monorepo 的情况下公共依赖项目的单测就会被重视起来,因为公共依赖项目的问题会影响到所有的项目,而且是会立即暴露出来,这就侧面要求公共库的代码质量。

也就是说,如果你在 monorepo 场景下,不重视公共依赖的单测,那么公共代码将变的无法维护,所以这就迫使你必须重视公共依赖的单测。

团队角度的其他价值

这里再补充一些小的点(不会展开解释太多具体原因)。

2. 个人角度

monorepo 对于整个团队的收益很大,但是对个人的收益可能没那么明显,而且一些同学还会认为,monorepo 统一的方式限制了一些个人的发挥,这里我简单整理几个对于个人的价值。

项目切换成本低

基建的统一让切换项目的成本降低,monorepo 内部的项目切换不需要每次切换项目都学习&习惯新的基建。

更专注业务的开发

由于基建的统一,个人可以更专注于业务的开发,而不需要去关心基建的事情,这样就可以更专注于业务的开发。

如果想做技术上的建设时,也需要更多的考虑点,过更多的技术 review,以保证基础建设的质量。

代码共享方便学习优秀实践

因为所有的业务+基建代码都在一个仓库,所以可以很方便学习团队内部的优秀代码实践,以及团队内部避免重复造一些轮子。

同时也因为代码共享,一定程度上避免了糊屎的情况,因为自己的代码会被更多的人看见(其实也未必,如果不能做好代码质量管理的话,就算 monorepo 可能也解不了这个问题),但是我从我个人角度上看是成立的。

做工具/公共业务代码变更时,方便梳理出影响范围

因为清晰地知道自己变更代码在哪些地方被使用,所以可以更好的控制自己对代码变更的风险。

monorepo 产生新的问题

因为代码管理模式的变化,所以必然会产生不少问题。

这个其实也是一个非常大的点,我会开一个新的文章总结(其实因为懒,想早点把 monorepo 价值的文章结了...),这里暂时不补充。

总结

文章不长,就不总结啥了,补一下自己后续可能会更新的点: