第一章：与Monorepo的邂逅

今天和大家介绍一下Monorepo，其实之前工作的很多很多年都没有接触过“Monorepo”这个词，因为之前的多家公司本身就是Monorepo，直到我入职了一家公司采用了multi-repo方式来维护代码，痛苦的使我不得不寻求解决方案（谁让我是开发底层框架的呢，就我最痛苦），因缘际会认识了Monorepo。

• Multirepo：每个项目使用一个git仓库来管理，或者一个项目中的每个模块用一个仓库来管理
• Monorepo：多个项目是使用一个git仓库来管理
  

第二章：Multirepo的困境

以下是我根据网上的资料和我遇到的实际问题整理的脑图：

对于开发维护底层框架的我来说，Multirepo简直是噩梦，最痛苦的三个点：

• 框架更新困难，没有原子的更新方法，只能每个团队通知，由于更新不及时，好多次导致使用的框架版本不统一，导致有的模块可以启动、有的模块启动不了
• API维护的战战兢兢，根本不敢丢弃老的接口，要一直背着包袱，因为你不知道哪个仓库就用了
• 依赖混乱导致架构根本无法统一，当想引入Mediapipe、Taskflow等任务流的执行框架时，发现单进程根本不可能，因为每个模块用的依赖随时都有可能发生变化，一旦导致冲突就会出现无法启动的问题

第三章：Monorepo的魔力 - 不可思议的解决问题能力

当我更新框架版本花了2周后，我终于下定决心要改变这种状态，因为这种状态下框架迭代根本无法实现敏捷开发、Bug无法被快速修复、新功能无法被测试充分，所以我开始学习Monorepo的知识，发现Monorepo真的可以完美解决Multi-repo遇到的问题，并且国外的Google、国内的腾讯等大厂都在使用这种代码管理方式，Monorepo的优势我整理成了简单的脑图来总结一下：

第四章：Monorepo的挑战与应对策略

当然Monorepo也不是银弹，它也有很多需要解决的问题，比如下图中的挑战：

在我的工程实践中，对于上面问题的应对措施：

• 权限控制，直接放弃了，公司非常Open，直接所有人可见、可修改，但是合入主线需要Owner的Approve
• 性能问题，公司只是某个部门采用Monorepo，代码量还没有巨大到非常恐怖的地步，所以日常浏览、编辑都没有问题，编译性能是通过bazel的remote cache来解决，从全量编译从1小时逐渐优化到10~20分钟
• 破坏主线，这个需要公约+CICD来约束MR，把控准入标准

第五章：总结

由于不是转门搞CI/CD或DevOps的同学，所以对于Monorepo的认识不是太深刻，总结一下我的认识：
对于代码量没有恐怖到一定程度，不考虑权限问题，那么Monorepo一定适合你的团队，基本没有什么副作用，也有助于建设公司的共享、互助的工程师文化；但是如果你的团队对权限问题要求很高，那就只能做一些妥协，将关键代码单独管理，通过repo或git submodule来和Monorepo大仓一起管理。

第六章：参考

https://new.qq.com/rain/a/20210726A0AD3W00
https://www.cnblogs.com/guxingzhe/p/17587786.html
https://www.163.com/dy/article/E71EEJTA0511K58A.html