对iOS代码重构的一点看法

一、原起

基本上每一个项目都会经历这样的一个过程，前期的快速迭代，去做市场的试探，这个时候的要求是怎样快怎样来，经过市场试探，找到对应的盈利模式，与及摸准了客户的使用习惯，这个时候产品会进入一个稳步发展的阶段，这个时候很多公司就会开始考虑怎样样更好的去维护这个产品，这个时候重构就来了。

项目重构一方面是对之前开发不正当的地方进行整理重写，另一方面是为后续的扩展和维护打基础。

二、代码重构建议一览图

iOS代码重构的一点看法.png

三、代码重构的具体细节

3.1 操作提醒

操作提醒是几乎所有App都会使用到的控件吧，一般都是三方开源的，现在比较流行的都是HUD相关库吧，这种库不仅有文案提醒，一般还有对应的图标，显示和消失还伴随着动画。这才更符合移动App的使用体验。对于toast这种老旧的操作提醒，直接放弃，UI太难看，不符合时代发展。

3.2 使用系统提供的新控件

随着iOS系统的逐年升级，苹果会为我们提供少量更好用的控件来代替就控件。UIAlertView和UIActionSheet这两个控件属于旧时代的产物，苹果已经为我们提供了更好用的UIAlertController，一旦遇到前两个直接使用UIAlertController替换就可。

3.3 机型兼容问题

早几年的时候，iOS还有32位操作系统，不过经过几年的发展iOS目前都是64位操作系统了。所以对于少量变量的定义直接使用64位的就可。
定义整形变量就使用NSInteger，int就不要使用了；定义浮点型变量的时候，float也不要用了，直接CGFloat。

3.4 系统版本兼容问题

对于系统版本的兼容，太老的系统版本就直接放弃吧，对于iOS来说兼容三个大版本，最多4个版本就足够了，对于那些4都不更新的客户，个人认为可以直接放弃了。

3.5 删除不再使用的代码

版本的快速迭代过程中或者所或者少有少量功能是尝试之后失败的，对于这样的功能代码，假如确定是不再使用的，就删除吧。减少工程的体量，代码的维护高质量也会少少量。

3.6 数据模型

项目开发中数据尽量做成数据模型，重构的过程中假如遇到这种情况，还是尽量做成模型，方便了解和维护。

1. 不要直接使用字典进行传值，这样对于后期的维护不利；
2. 网络请求封装的时候，请求参数尽量单独写成一个参数，这样尽管多写了代码，但是见名知意，方便后续的维护，不要一个字典把所有的参数都扔进去，这样对于后期的维护很不利；
3. 网络请求的结果也尽量做成数据模型，不要直接使用字典进行传值。

3.7 变量定义

变量定义的时候尽量明确类型，除非万不得已，不然不要使用id类型。

3.8 尽量使用大众化的书写方式

有的时候一段代码逻辑的编写可能有很多种方式，对于这种情况，我们尽量使用大众化的编写方式，不要为了偷懒，使用少量晦涩难懂的书写方式。导致过段时间自己都看不懂了。

3.9 组件化

代码重构一方面是对之前代码的整理，另一方面是对后续扩展和维护打基础。所以重构的工程中，我们应该深入思考，对于少量使用场景比较多的代码，哪怕是多花点时间，也要把它做成通用组件，这样后续的开发能够事半功倍。

3.10 集合初始化

对于集合的初始化，比方NSDictionary和NSArray，尽量使用简介的语法糖初始化方式，那种老旧的初始化方式就放弃吧。

3.11 枚举的使用

对于少量多类型判断的场景，尽量使用枚举来定义场景类型。这样后续维护方便，代码看上去也更有逼格。