前言
开发了很久的代码，从开发安卓到现在用c++开发客户端，虽然技术上得到了很大提升，但实际在开发中，还是有很多痛点。
痛点
无论是客户端开发，还是安卓开发，现流行的都是组件化的思路，在几年前，我在开发游戏安卓打包工具的时候，就已经把整个架构参考阿里的arouter，重写了一套适配游戏的路由架构，并且配合这套路由架构，在apk打包上也做了完美的适配，沿用到现在。
虽然组件化的好处有很多，但是带来的问题就是各个组件的管理：当前游戏打包应该使用哪些组件，选了某一个组件是否会关联别的组件，并且如果关联了别的组件，对应别的组件的版本号应该选择什么。
组件代码提交流程
组件管理流程
组件是通过gitlab ci来构建，内部开发了一个系统，当构建成功后，会将gitlab的tag信息提交到系统中，通过系统来保存这些版本信息。
组件与组件之间的管理，都是通过这个系统来驱动。
内部系统管理组件的痛点
时间久了还是会发现，即便是通过系统来管理各个组件之间的关联，还是会出现混乱的情况，主要还是因为组件过多，导致管理成本变大，而且很容易出现人为疏忽的情况。在之前，也强行整理了一次所有组件，将组件精简，保留必要组件，合并不必要组件，尽可能减少组件过多的情况。但随着时间的推移，就目前而言，在没有强制合并组件的情况下，组件还是会随着需求的变多而变多，并且关联变的更加复杂。
目前的状态，还是处于口口相传，并且在打包的时候，默认都会选择最新版本的组件。当出现打包失败或者功能错误的时候，才回头去改组件版本或者修改代码兼容组件。从流程上来看，个人觉得这个并不合理。
思考
最近也看了不少相关的大厂代码管理方面的文章，我觉得在这里，可以考虑使用monorepo的方式来进行管理。当然，每个方式都有每个方式的优点，同样也有对应的缺点，主要还是得看是否适合自己当前的项目。
monorepo
monorepo是一种将多个项目代码存储在一个仓库里的软件开发策略。
monorepo的优缺点
优点
易于代码复用，易于依赖管理，易于代码重构
缺点
额外的学习成本：monorepo 使得增加理清各个代码仓库之间的相互逻辑的成本；
需要工具链和自动构建工具的支持：项目若很庞大且没有工具链的支持，那么 git 管理、安装依赖、构建、部署会很麻烦和耗时。
以后的想法
现在已经有对应系统来处理版本与版本之间的关联，但是比较分散，使用monorepo的方式，虽然看上去可以解决相关的痛点，但还是有很多问题，例如打包的时候，实际不会使用所有组件来进行打包，如果使用monorepo，这个需要怎么进行管理等等，所以实际还是得需要实践验证才能得出最佳的方案。
