极光日报
首发于极光日报
REPO 风格之争:MONO VS MULTI

REPO 风格之争:MONO VS MULTI

简评:两种管理代码库的方式甚至是两种哲学的碰撞。

首先,我们解释一下什么是 monorepo 和 multirepo。这两者都是管理组织代码的方式,顾名思义 monorepo 就是把所有的相关项目都放在一个仓库中(比如 React, Angular, Babel, Google...),multirepo 则是按模块分为多个仓库。

这两者的核心区别可以归结为你相信怎样的哲学能让团队在一起工作的效率最高(多元化 vs 集中管理)。

multirepo 的角度来看,这样让每个子团队拥有自己的 repo,可以用他们自己擅长的工具、workflow 等等。多元化能促使各个团队尽可能的提升自己的效率。

但代价也在于会增加很多沟通成本,如果你在你们项目用到的库中发现了一个 bug,就必须到目标库里修复它、打包、发版本,然后再回到你的库继续工作。在不同的仓库间,你不仅需要处理不同的代码、工具,甚至是不同的工作流程。甚至你只能去问维护这个仓库的人,能不能为你做出改变,然后等着他们去解决。

而从 monorepo 来看,让不同的团队走自己的路,并不见得能提高生产力。虽然有些团队可能会找到自己最佳的工作方式,但他们的收益也会被其他团队不那么好的工作方式所抵消。相反,严格统一的管理更能提升效率,团队中的任何人都可以(并且应该也被鼓励)修改任何东西(因为修改造成的结果马上就能展现出来,)。虽然把所有的鸡蛋都放进了一个篮子里,但我们也可以更小心的照顾这个篮子。

如果你们团队选择 monorepo,那主要的挑战自然是随着项目的发展,其会变得非常庞大(因为没有根据模块或功能拆分成不同 repo)。因此会需要很多的工具来应对这样的挑战。

  • 你会需要强大的构建工具,比如 Google 的 Bazel, Facebook 的 Buck 和 Twitter 的 Pants
  • 仓库变得太大,对你们的版本控制技术会有很大的挑战。因为 Git 社区建议的是使用更多更小的代码库,Git 本身并不适合单个巨大的代码库。
  • 因为所有的代码都放在一起,你需要时刻保持警惕,以保持良好的项目结构和提交测试。
  • 在这么大的 workspace 中工作或使用了非标准化的构建工具,你常用的 IDE 可能会遇到麻烦。Facebook 就选择了构建自己的 IDE。

那有没有什么两全其美的办法呢?可能并没有。你可以像 Android 使用 repo 一样,在多个仓库间进行工作,但整体的行为看起来却像是 monorepo。但这样又不清楚你到底想从 multirepo 中获得什么好处?

或者在 monorepo 中用分支来管理其中的不同项目,每个项目都存在于一个单独的长期分支中,只在需要时才合并来自其他项目的修改。但这样你就又没办法完全避免菱形依赖等问题。

因此建议还是根据团队的情况选定一种方式,然后尽可能的扬长避短。

原文:REPO STYLE WARS: MONO VS MULTI

扩展阅读:

发布于 2017-11-23

文章被以下专栏收录

    简介:每日导读(或翻译)三篇优质英文文章,内容 80% 涉及硅谷/编程/科技/,期待共同成长。