现状
初到公司熟悉代码的过程中，我看到了一个主控制器里有多达5000行的代码，当时我的内心是凌乱的。这样的代码耦合度如此的高，日后需要如何展开迭代和维护工作了。本着求稳的原则，在完全不熟悉公司的业务流程的前提下，我和另外一个开发同事进行了几个版本的迭代工作，这几个版本的迭代工作让我感受良多。最后得出了一个结论：项目代码框架需要优化一下，但是为了不影响现在线上的版本和日常的正常开发工作，我们新开了一个分支进行框架的整理和代码的优化工作。
项目分析
公司主体业务是，项目里采用原生和网页混合式开发的，网页的比例偏重。目前的项目采用的MVC的模式，VC的臃肿问题展现的淋漓尽致呀！
VC臃肿的原因有如下
- 分层不明确
-
view层的创建，样式处理，或者一些其1.1.jpg
他的处理都是写在了VC里
为了同时兼顾稳定性和后序的维护成本等因素，我们还是决定沿用MVC模式，但是需要分层明确，将代码完全抽离出来。
框架结构
- Controller层
- View层
- model层
- 网络抽象层
- 数据持久层
接下来我们会逐步来讲我们的优化"路径"
第一步 工程目录的整理
先对项目需要的模块进行文件管理，这样就有的大概的"路线"了
- Catergore 分类目录
- Base 封装的基础VC
- Controller 项目中所有模块的控制器
- Model 项目中所有的model
- View 项目中所有的视图
- Component 封装的公共控件
- Global 存放项目中所有的全局的文件
第二步 封装网络请求抽象层
抽象网络请求层为了减少开源AFN的代码侵入性，同时增加复用性，其他项目也可以直接拿过来使用。
请求层处理网络加载框的状态，请求的返回状态等逻辑。
封装完成以后进行一个网络请求测试一下是否有问题
第三步 封装基类的controller
OCJBaseViewController基类控制器里添加一些公共的逻辑，子类去继承，但是我们项目里的考虑是不能把所有的东西都放进去，目前我们把自定义导航栏和接受的网络请求成功的通知放在里面！
OCJBaseTableViewController 下拉刷新的页面都是通过tableview实现的，所以封装一个基类的tableVC控制下拉刷新的控制器，自定义下拉刷新的动画等
当然，实践是检验真理的唯一标准。我们也挑选了一个页面来进行替换，检查时候有什么问题。
第四步 组合使用
前面的都是单个的进行测试，现在组合使用。
本着"柿子捡软的捏"的原则，又能完整的反应问题的界面，我们挑选了个人中心里的积分列表页面来进行测试。
在积分VC里发起一个请求，请求回调以后在处理业务逻辑，那么这样VC会有一些数据处理的代码，思考以后觉得这样不是很好，为了进一步给VC进行瘦身，我们VC和网络请求层之间在增加了一层，这一层只需要漏出一个接口就好了，具体的数据处理，失败处理都在在这一层里面进行处理的，有图有真相
我们只需要调用这个漏出来的接口
请求成功以后,去处理响应的数据
然后发送一个通知给对应的控制器
接收到通知以后就可以处理对应的业务逻辑了
那么问题来了，可能有的童鞋就在想，通知是广播形式的，怎么能保证接受者的正确接受了。哈哈，我们可以这样子解决，请看下图
在基类的控制器里的init方法里我们给每个控制器实例都绑定了一个随机数，我们把这个随机数当做每个控制器的"指纹",在发送请求的时候我们把自己的"指纹"发送出去，请求完成以后的通知把"指纹"在发回来，我们对比一下这个通知里的"指纹"我们就能得到正确的通知了。即使去韩国走了一趟，外貌再怎么变化，你的指纹还是没有改变的！
第五步 体力活部分
测试成功没有问题以后，那现在体力活的部分就来到了，我们就得一个模块一个模块的进行更改了，这个部分是最恶心的阶段。耗时间很长
第六步 换完衣服，该减肥了
在我们的项目里，主控制器里的代码量"巨大"的原因非常多，我们这只是完成了第一个阶段的工作，第二个阶段的工作正式开始。
项目中复用的视图控件都封装起来，只是暴露必要的接口，在vc里我们只会看见控件的调用，这也是和前端的控件化思想有一些相似之处吧！所以我们把项目里所有可以封装的视图模块都封装起来了
浩浩荡荡的框架整理代码优化的阶段暂时先告一个段落，为了不对业务造成影响，这个过程是一个漫长的过程，而且每次测试都是闲的至关重要的了！
代码优化是一个长期的工作，只要还在维护的项目，代码就不可能不需要优化，项目不止，优化不停！
这是我目前的代码优化工作，以后的优化工作在记录下来！
Loading....
