遗留代码重构的原因：
* 性能瓶颈、
* 高危、高频故障
* 新功能扩展困难
* 代码逻辑混乱、可读性差
* 人员能力提升
风险：
自动化测试包围情况
人员支撑情况
重构周期
重构代码度量数据
从以下几个方面谈谈重构
1. 整理资源文件
- 删除未使用的图片、资源
- 图片尽量放在Images.xcassets中
- 使用Unused查找项目中未使用的图片
- 图片压缩
- 删除不用、重复的类
2. 文件目录结构
基本推荐使用下面的主目录按照模块分类，内目录按照业务分类
原文：iOS 项目的目录结构能看出你的开发经验
3. 升级各种框架
升级项目中老的框架，可以使用Cocoapod管理
4. 代码规范
注释
代码中不要出现大量的中文注释，除了提供服务的public功能或者方法，业务代码仅在某些关键点上注释一下就行，代码自注释即可，需要注释的，可以通过喵神的Xcode插件来实现，
VVDocumentor使用@property声明属性
头文件中尽可能少暴露变量或方法
使用block将UI和action的代码整合在一起，使逻辑变得紧凑
模块化
使用”#pragma mark - XXX”进行分割不同逻辑之间的界限，让整个文件阅读起来更加结构化。-
重写getter方法和Code Block Evaluation C Extension语法
重写UI的getter方法，把UI的初始化放在getter中，减轻 -viewDidLoad的负荷，同时可以使整个页面变得清晰；同时，可以通过使用使用GCC Code Block Evaluation C Extension ({…})语法，结构化局部变量初始化和处理的逻辑。- -viewDidLoad中，做为逻辑的入口，代码会变少但是变清晰。
-
然后重写bgView的getter方法，包括View和frame这些都可以使用({...})语法使代码结构化层次化：
重写getter.png
注意空格规范
代码规范及CodeReview要点多用类型常量，少用#define
使用extern 定义URL管理公共类，
5. 统一代码实现方式
关于这个问题相信很多同学都有困惑，国内iOS界的大神唐巧和喵神对这个问题也都有自己的见解，大家可以移步到他们的博客看看：
唐巧：http://blog.devtang.com/blog/2015/03/22/ios-dev-controversy-2/
喵神：http://onevcat.com/2013/12/code-vs-xib-vs-storyboard/
借用唐巧的几句话：
- 对于复杂的、动态生成的界面，建议使用手工编写界面。
- 对于需要统一风格的按钮或UI控件，建议使用手工用代码来构造。方便之后的修改和复用。
- 对于需要有继承或组合关系的 UIView 类或 UIViewController 类，建议用代码手工编写界面。
- 对于那些简单的、静态的、非核心功能界面，可以考虑使用 xib 或 storyboard 来完成。
6. 性能优化
Auto Layout/Masonry
在一些性能要求不是那么强烈的非列表页，可以大量使用Auto Layout开发UI。
- 动画的问题
使用Auto Layout有一个比较大的问题在于动画，通过更改约束来进行动画，一直是我比较头疼的问题，所以一般遇到这类问题的时候，我都会尽量避免使用Auto Layout来解决，而是使用frame的方式来做。可以参考objc.io上面的一篇文章：http://www.objc.io/issues/3-views/advanced-auto-layout-toolbox/。 - tableView性能优化
iOS App 稳定性指标及监测(转载)
7. 安全防护
数据安全
8. UI开发
复杂的UI开发可以使用组合式UI/custom view/ child view controller来解决。
- 组合式view
合理的按照从上到下或者从左到右，把各个UI元素层次化放到不同的container view里。
好处： 层次清晰，方便阅读，设置约束也很方便
而且iOS中不存在Android中页面层次较深性能卡顿的问题， - custom view
对于比较复杂并且相对独立或者可以重用的UI，使用custom view子类化。
当仅仅是一个模块内使用，便写在业务模块的文件里即可。 - container view controller
对于有相对独立业务逻辑以及生命周期要求的业务，使用child view controller进行包装参考链接
