Monorepo架构: 项目管理模式对比与考量
关于 monorepo 相关概念及项目管理模式
- 在软件开发中，尤其是前端项目，我们会涉及到不同的项目管理模式，这里先介绍几个重要的概念
- “monorepo”是当前较为热门的一种项目管理方式，虽然很多人可能听说过，但可能在实际项目中以不同的形式接触过它
单体应用架构（monolithic）
- 单体应用架构是在一个项目中使用 git init 来初始化项目的所有代码。
- 这种模式的优点是代码管理成本低、代码能见度高，无需额外的学习成本，发布简单，链路便捷
- 然而，其缺点也很明显，代码量大会导致调试和构建效率显著下降。例如模板组件库项目，如果要分离出基础组件，就需要添加多个 tsconfig.ts 配置文件，而且无法跨项目使用，代码耦合度高
多仓库管理模式（multirepo）
- “multi”在英文里有“多”的意思，多仓库管理模式就是采用多个仓库来管理项目。
- 前端项目用一个 git 仓库，后端项目用另一个 git 仓库，可以使用 git subtree 或者 git submodule 进行操作
- 不过，这种模式不太流行，原因主要有两点：
- 一方面，git subtree 和 git submodule 命令相对复杂，而前端开发者可能更关注业务本身而非复杂的命令操作
- 另一方面，使用 git submodule 时，如果其他伙伴更新了代码，自己有时可能会忘记更新，从而导致代码冲突或出现问题
1 ) 多仓库管理模式也有其优点：
- 便于代码复用，模块和组件相对独立，开发调试效率高
- 人员编排分工更加明确
- 能提高研发人员抽取公共代码的思维能力
- 源代码访问权限设置更加灵活，可以根据仓库设置其他人员的读写权限
2 ) 但它也存在一些缺点：
- 模块划分力度不容易把握，有些仓库代码量少，管理起来不方便
- 存在共同引用的版本问题，管理方式与常规开发方式有出入，会导致重复安装项目依赖的多个版本，构建配置无法复用，模块体量大时发布成本急剧上升
monorepo 管理模式
- monorepo 是在一个仓库里管理项目的多个模块，这些模块还可进一步细分
- 例如在一个项目中创建一个 git 仓库，然后安装 packageA、packageB、packageC 并使用它们的不同功能模块。这种模式具有以下特点：
- 利用 bit 管理所有仓库中的代码，bit 命令相对通用，适用于前端和服务端项目。
- 不像 git submodule 那样有多个 submodule 库需要管理，对于较大的项目，只需在一个仓库里拉取所有代码并调整部分模块即可。
- 不过，monorepo 也有不足之处：
- 如果没有对应权限，可能影响其他开发者的功能或模块
- 需要针对不同的 package 单独发布，需要学习 monorepo 的管理方式。而且它更多地存在于前端项目中
项目拆分考量
- 当考虑是否将项目拆分为多仓库时，有几个关键因素：
- 如果项目中有核心代码不希望所有开发人员看到，需要进行代码隔离，就适合使用多仓库管理。
- 当项目出现扩展功能或与现有功能完全不相干时，也需要用另一个仓库来管理。
示例项目分析及代码统计操作
- 以 Vue 项目为例，它被拆分成了多个 package，如 core、dom、SFC（Single File Component）、SSR（Server-Side Rendering）等
- 我们可以参考这样的公共开源项目，来判断自己的项目在多大规模和复杂度时需要进行拆分
- 为了统计项目的代码量，可以借助 GitHub Actions 来完成。具体操作步骤如下：
- 将项目 fork 到自己的仓库。
- 在仓库中创建一个新的 workflow 文件。
- 在搜索框中搜索 CLOC（Count Lines of Code），选择相应的代码复制粘贴到 workflow 文件中。
- 将触发方式改为手动触发，属性项设置为 workflow_dispatch。
- 保存文件并设置一个合适的名称，如 count-lines。
- 根据需要修改代码中的输出配置，例如将结果输出到一个 CLOC.md 文件中。
- 提交更改并手动触发 workflow 来计算代码量。
- 通过以上操作，我们可以根据代码量来判断项目是否需要拆分
- 一般来说，如果项目代码量还未超过 11 万行，可能无需拆分；即使有 24 万行代码，也有可能使用 monorepo 架构进行管理
- 后续看下如何创建 monorepo 项目以及使用哪些工具来助力管理