项目重构实践之iOS客户端

l-0495682-CLln79.jpg

一、项目熟悉

在重构项目之前首先是要对项目的业务和项目架构有一定的熟悉程度才能更好的进行对项目重构的一个实施过程。因此我花了将近一个多月到两个月的时间在熟悉项目代码和业务上，在领到和同事的帮助下对整个项目也有了一个更深度的了解和熟悉。也意思到重构这件事情更是迫在眉睫。

其中做开发这块重构项目这件事情是常有的事情也是必须要去做的事情，只不过可能考虑到成本和效益的原因不一定肯投入时间和精力去做，其实不然，这件事做好了对项目的一个以后应对业务的不断扩展和发展都是利大于弊的，当然肯定是要在有个好的重构基础之上才行。

二、优化基础代码

在熟悉代码的过程中，你可能就是会发现代码的优缺点，优点的话我们就继续保持，缺点这块就是我们可以优化的地方。

例如设备状态这块，可以使用枚举一目了然是什么状态，而不是一大堆的数字对应不上。又比如基类，有时候为了方便我们很容易就把不应该出现在基类里的方法给添加进去，久而久之基类就变大臃肿无比。所以把方法放到适合的地方去，减轻基类压力。还有就是如果代码重复超过三次我们就应该考虑抽出来处理，代码复用这块可以不断优化中。我们在定义一个方法中尽量不要让他的行数超过一个面板，并且最好让他处理单一的事情，能拆分出来的尽量拆分出来。最后就是AppDelegate类的优化处理，之前在didFinishLaunchingWithOptions方法中实现代码太长而且很杂乱，现在将每个要加载的功能都抽出来，简洁清爽很多，修改的时候也不容易出问题。

目前这些是我在熟悉代码过程中自己发现的一些问题，其实后面陆陆续续在重构过程中也发现了不少问题，也就不一一列举，总的来说就是对代码可以反复的去阅读去推敲看看是否合理有没有优化的地方。

三、选择合适的架构

目前项目上使用的是mvc，不过也没有那么严格，导致c层慢慢开始变的臃肿起来，而且和视图层耦合度相对比较高，通过小组的讨论和分析，决定使用mvp架构处理，mvp架构的优势一个上手快，团队上手没有什么学习成本，第二个就是对于业务逻辑和UI视图的解耦能力效果显著，通过泛型和协议可以将View层和业务P层进行完全的解耦处理，这其实就是我们目前很希望的样子，所以最终是选择MVP这个架构，在架构处理的过程中也对业务逻辑和UI逻辑有了更深的了解。

四、对项目进行分层处理

项目分层分好了可以更好的应对上层需求的变化，大致我们分层了基础层，SDK层，业务层、UI层。

基础层：这里提供一些基础的功能，分类，宏定义，配置列表，和一些工具类。

SDK层：这里主要是封装了阿里云端sdk，通过二次封装进行隔离，便于替换其他库和库的更新等等。

业务层：根据不同业务线进行拆分出多条业务，都属于同一层。

UI层：这里就是视图层，变化比较多，一般就在主工程里的UIView 和 UIViewcontroller。

五、通过私有cocoapods管理

在分好层的基础上我们引入cocoapods管理工具进行管理，创建私有库，并将基础层、sdk层、业务层、封装成pod库，提供给各个项目使用，这样比如有业务逻辑问题就不要每个项目都去改一遍，只要将库更新，其他项目拉去最新库即可完成修复，UI层这边是多变的一般就不用打包成库，直接在主工程里修改即可。

六、通过中间件CTMediator 进行模块化通信实践

当一个项目越来越大以后，不可避免的要去实现模块化解耦通信工作。目前主要模块通信有两种方式，url注册和TargetActions，通过调研使用TargetActions更合适，通过CTMediator可以再本地模块间通信和远程app间进行通信处理。并且他是通过runtime机制进行完全解耦隔离，唯一不足就是在分类和Target上有些硬编码，不过还是在可控制范围。目前在首页跳转配网模块和首页跳转面板模块进行了实践。

七、 总结

重构项目目前已经接近尾声，后续还有很多待改进和完善的地方。对应mvp的缺陷带来的p层的臃肿这个是以后要面对和去优化的点，还有就是在现有mvp基础上看看能不能引入双向绑定，这样状态的一个同步能有更好的实现效果。还有就是基础层的库的一个沉淀，业务库的一个完善等等。

通过几个月的一个重构处理，基本上是达到之前的预期，从中也有不少的收货。