前情提要
第一次项目重构要追溯到2022年5月份，之前因为历史原因公司项目在开发马甲包的时候成本极高，时间极长和难度极大，连用了三个“极”，可见对此真是深恶痛绝，于是在确定好方案后，2022年5月开启了第一次的重构之旅。
第一次重构
原因
公司项目本来是一个项目（母包），后续因为要开发马甲包上一任的开发就在这个项目上复制了多个项目（2个左右）（子包）（不是一个Git进行管理的），这时候马甲包不多，所以弊端还没有显现，只是觉得开发需求时，总是要复制多个；但是在某一个时刻，母包开始了疯狂迭代需求，导致子包项目一直没有更新，停留在某个阶段；然后恐怖的事情来了，突然迭代停了，要求把部分数据好的需求迁移到子包上，因为子包也有部分差异化的地方，再加上子包和母包的版本相差过大，代码相差过大，导致同步一个需求周期达到了单人单个需求需要一周可能更多的时间，在加上后续一直以开发马甲包为主，领导出面了（虽然我前面提过很多次）进行了首次重构。
方案
- 首先需要将所有的马甲包归纳到一个项目中，不能再以多个项目进行开发，合并成一个后就便于管理和开发。
- 以母包为依托，将功能进行拆分，利用路由（阿里的Arounte）进行功能的链接，用一个壳工程进行模块依赖，就形成了一个完整的项目。
- 因为马甲包出了UI不一致，逻辑基本时一致的，所以我们将模块进行了逻辑层和UI模块的分离，也就是一套逻辑会对应多套UI的方式；逻辑层只负责数据请求和业务处理，中间用接口（interface）进行和UI的交互，多个UI只需要实现接口（interface），去处理对应的UI。
- 每一个壳工程只有一个Application，通过在buidl.gradle中去依赖UI模块进行功能组装；UI模块依赖逻辑模块，实现数据对UI的填充；在开发一些Base模块，比如网路请求，数据库等等左右基础或公共模块提供给其他所有模块进行使用。
结果
从目前来看结果是好的，速度已经提升到单人产出单个新马甲包只需要一周的时间，因为每个马甲包的UI都不一样，只是去更改一些使用逻辑和UI逻辑；在开发需求层面，需求同步到其他马甲包看难易程度大概是1-3天左右。
方案的优点:逻辑层只需要开发一次，UI层只针对接口负责。
缺点：接口改动，所有实现该接口的马甲包UI都需要改动；每开发一个马甲包都会有大量的UI层出现，维护成本上升。
第二次重构
原因
因为后续主要是以马甲包开发为主，所以开发效率显得尤为重要，目前单人单周开发一个新马甲包暂不能满足开发进度，所以二次重构方案正在讨论中，目标是单人每周开发2-3个新马甲包
方案
方案讨论中，后续继续补充。。。
