重构图如下：
目标：在不改变软件可观察行为前提下，提高其可理解性，降低其修改成本。
在不熟悉原理，但是知道该代码块功能的情况下修改。
使代码尽量高内聚，低耦合。
重构原因？
1.解决大量的模板代码。
- 网络层API必须遵循和实现一些无用的协议，每次新建API基本必须复制。
- 存在同样的数据结构多个模型，网络层必须建立和后台对应的APIResponse，在根据这个数据去映射新的模型，存入数据库又是另一个模型。
2.解决新功能扩展困难的问题。
1.多套重复的代码，修改相同功能需要多处修改。 2.多重继承，swift继承oc，oc在继承swift，甚至有的存在四五重继承。
- 多套重复的代码，修改相同功能需要多处修改。
- 多重继承，swift继承oc，oc在继承swift，甚至有的存在四五重继承。
- swift和OC桥接比较混乱，存在oc与swift相同模型维护等。
3.解决逻辑混乱,可读性差。
- 类与类之间耦合性非常重，通信过大。
- 代码不收敛，职责不单一，一个简单的小功能点会涉及很多模块。
- swift和oc混编，存在很多转换的类，接口，尽量减少和移除一些oc的方法，类。
4.解决偶发性闪退，问题难以定位。
- 通知零散，使用某个接口自动发出通知，使用相同API多个页面都在刷新数据，且必须监听，否则正常页面API接口无法接收数据。
- 部分数据库的存储和读取会存在崩溃
重构风险
1..重构需要时间和人力成本。
2.重构缺乏熟悉项目的人，流程不清晰，容易造成功能缺失和异常。
3.需要大量的测试覆盖，能够验证重构的模块，一个功能改动可能会影响到整个app。
1.网络层
为什么要重构网络层？
- 现在网络底层复杂，与个人信息以及登录等逻辑耦合在一起，可维护性低。
- 使用现有的网络存，必须复制大量的模板代码。
现有的网络层结构功能
- 功能：网络请求+数据库+缓存+数据解析+部分登录和个人逻辑
- 使用：必须复制模板代码构建API + 与后台json一致的ResponseAPI + 存入数据的模型 + 展示到View层的模型 + 实现不管是否需要的写入数据等协议
重构后的网络层
- 功能：网络请求+缓存json数据+提示框
- 使用：简单网络请求不超过十行代码，但是需要自己解析json数据
2.消除相同功能的多套代码。
OC和swift类似功能：如居民详情页多个，标签的实现方式等。
不同位置相同功能的合并
3.整理文件目录。
现有结构： MVC+API+DB+DataModel+Modules
重新分类的原因： 找不到对应的模型，view在哪里？
重构后结构目录： 根据tabbar先分为主要的模块，然后在内部分MVC+API
缺陷：如果存在多个模块公用会存在混乱。 着重点：注意目录下职责的单一性。
原因：找不到具体功能模块的MVC对应的类
现有架构
- 新的swift MVC架构
- OC Modules里面得MVC
- API+DB+DataModel
重构后目录，根据功能模块划分目录结构的MVC
- Model
- View
- VC
- ViewModel
- API
- DB
- Helper
