一、重构原因
(1) 技术选型 - 拓展性差：
• 技术选型陈旧小众化,导致无法维护和更新,只能满足于目前开发.
• 网络层、route层没有按照业务模块细分.
• 部分SDK太老，导致没有支持最新的系统.
• 目前状态还能满足目前的产品需求,但是很难满足产品业务拓展的需求.
(2) 技术架构 - 高耦合：
• 基本上就是在传统的MVC的架构基础上封装了一个数据服务层即代理数据层,不利于页面维护和迭代，页面难以复用,代码堆积,所以只适用于App的startup开发 .
• 结构不统一，逻辑存在于view层或者controller层.
• 拓展灵活性可变更性弱，牵一发动全身。添加需求时需要修改大量代码.
(3) 代码维护 - 可读性差：
• 文件冗余，同一类型文件放置在两个文件夹下.
• 代码冗余，无用代码、重复代码多.
• 代码层次不清晰，无法分清业务线.
(4) 用户体验 - 使用性差：
• 数据无缓存，消耗用户流量.
• 页面排版陈旧，不适应主流APP风格.
• 模块性突出不强，占用主档位置，浪费资源.
二、如何重构
(1) 架构
• 根据App的业务场景(展示型, 交互型, 后台工具型...)选择合适的架构.
• 根据选用的架构以及业务模块分包，例如组件化,MVP设计模式...
标注：
• 并不是说一定要选用一个架构, 比如说后台工具型的App, 可能界面不多, 也服务器的交互也少, 基本是由Service组成, 可能直接用Android/iOS原生的结构就可以.
• 界面较多, 且与服务器交互较多的建议选用MVP架构. 可以通过P来做数据处理, 将数据源M与展示层V解耦, 便于替换数据源或是改变UI.
(2) 技术/开源库
• 根据业务特点和选择的架构, 选用相关技术/开源库支持或对当前使用的进行整理.
• 例如HTTP请求库, 缓存库, 图片加载库等等.
(3)代码质量
• 制定编码规范.
• 制定代码提交规范,gogs/gitlable管理流程规范等.
• 代码检视、单元测试.
(4)自底而上，由小至大
• 从底部开始, 也就是常说的Model层,数据层开始, 因为这部分相对独立,可以通过提供接口与UI层隔离.
• 不要一下就大面积重构, 需要逐个小的case进行重构验证, 保证当前运行.
(5) 持续重构，减缓工作压力
• 持续进行小的重构, 每次重构需要伴随测试, 保证重构结果.
• 提取方法, 去除重复代码.
• 结构调整.
• 融入面向对象/接口编程思想, 注意SOLID原则.
• 多用组合, 少用继承.
(6) 重构而非重写
• 不到万不得已不要想重写.
• 重写会产生各种意想不到的问题, 诸如设计过度,对于当前代码把握不够(例如现在看起来很不友好的代码可能就是为了解决一个架构无法解决的问题等).
三、重构架构设计模式
采用MVC+P+VM模式对controller进行减压，P（Server）用于对业务逻辑的组装和自定义，VM层固定对页面进行组装和自定义。大家可根据项目的复杂程度自行选择。下面有对MVC、MVVM、MVP三种架构的简要说明：
• MVC这个架构的最大的优点在于其概念简单，易于理解，大家都好上手。由于 MVC 的概念过于简单朴素，导致业务都堆积在 Controller 里，成为了Massive View Controller，同时不利写单元测试.
• MVVM通常会把大量原来放在 ViewController 里的视图逻辑和数据逻辑移到ViewModel 里，从而有效的减轻了 ViewController 的负担。MVVM首要的缺点是，MVVM的学习成本和开发成本都很高。在传统的 MVVM 架构中，ViewModel 依然承载的大量的逻辑，包括业务逻辑，界面逻辑，数据存储和网络相关，使得ViewModel 仍然有可能变得和 MVC 中 ViewController一样臃肿。
• MVP采用Present减小Controller的负担.
四、重构架构数据流式
详见如下图示分布：
五、重构工作量评估
工作量权重比，根据人员及时间合理调整，这里仅做参考。
六、总结
以上仅是个人对项目重构的一些肤浅的看法，感谢大家指正，共同进步！
相信经过多轮的技术预言及正确的架构设计一定能重构出更加适用的重构版本出来！
