共计 1371 个字符，预计需要花费 4 分钟才能阅读完成。
一、原起
基本上每一个项目都会经历这样的一个过程，前期的快速迭代，去做市场的试探，这个时候的要求是怎么快怎么来，经过市场试探，找到对应的盈利模式，与及摸准了用户的使用习惯，这个时候产品会进入一个稳步发展的阶段，这个时候很多公司就会开始考虑怎么样更好的去维护这个产品，这个时候重构就来了。
项目重构一方面是对之前开发不合理的地方进行整理重写，另一方面是为后续的扩展和维护打基础。
二、代码重构建议一览图
三、代码重构的具体细节
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 数据模型
项目开发中数据尽量做成 数据模型，重构的过程中如果遇到这种情况，还是尽量做成模型，方便理解和维护。
- 不要直接使用字典进行传值，这样对于后期的维护不利；
- 网络请求封装的时候，请求参数尽量单独写成一个参数，这样虽然多写了代码，但是见名知意，方便后续的维护，不要一个字典把所有的参数都扔进去，这样对于后期的维护很不利；
- 网络请求的结果也尽量做成数据模型，不要直接使用字典进行传值。
3.7 变量定义
变量定义的时候尽量明确类型，除非万不得已，不然不要使用id 类型。
3.8 尽量使用大众化的书写方式
有的时候一段代码逻辑的编写可能有很多种方式，对于这种情况，我们尽量使用大众化的编写方式，不要为了偷懒，使用一些晦涩难懂的书写方式。导致过段时间自己都看不懂了。
3.9 组件化
代码重构一方面是对之前代码的整理，另一方面是对后续扩展和维护打基础。所以重构的工程中，我们应该深入思考，对于一些使用场景比较多的代码，哪怕是多花点时间，也要把它做成通用组件，这样后续的开发能够事半功倍。
3.10 集合初始化
对于集合的初始化，比如 NSDictionary 和NSArray，尽量使用简介的 语法糖 初始化方式，那种老旧的初始化方式就放弃吧。
3.11 枚举的使用
对于一些多类型判断的场景，尽量使用枚举来定义场景类型。这样后续维护方便，代码看上去也更有逼格。
