遺留代碼重構的原因：
* 性能瓶頸、
* 高危、高頻故障
* 新功能擴展困難
* 代碼邏輯混亂、可讀性差
* 人員能力提升
風險：
自動化測試包圍情況
人員支撐情況
重構周期
重構代碼度量數據
從以下幾個方面談談重構
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進行包裝參考鏈接
