計劃寫一個系列文章，總結自己在四年iOS生涯中對設計模式和架構的理解。主要包括自己的總結、Apple原始碼和優秀三方開源專案中設計模式和架構的學習。
這只是自己的總結，每人理解不一樣。希望能拋磚引玉，讓大家加深理解。
業務與重構
系列中的第一篇文章主要介紹自己在碼業務時的一個指導思想，主要解決在快速開發過程中最常遇見的2個問題：
- 業務開發中如何避免過度設計？
- 何時需要重構？
為什麼會有這樣的問題？ 通常我們的版本是呈現出小步迭代、快速開發的開發規劃，主要就是功能多，開發快。所以就會要求我們在碼業務時：儘量快速的開發功能，同時又要追求高質量的程式碼。在一段時候後業務越堆越多再去新增新功能越來越麻煩，又需要我們重構程式碼。這些問題是非常矛盾的，我們如何去判斷何時該進行程式碼抽象？何時又該去重構？
God, Grant me
the serenity to accept the thing I cannot change,
the courage to change the thing I can change,
and wisdom to separate the difference.
業務開發中如何避免過度設計？
DRY原則
DRY原則是Don't repeat yourself 的縮寫，DRY原則想要表達的是：系統內的每一個知識點都應該是單一，明確，權威的標識。同樣的功能不應該重複多份實現，應該提取成一個共用的功能。
YAGNI原則
YAGNI原則是You aren't gonna need it 的縮寫，YAGNI原則主要含義是：不要新增多餘功能除非那是必需的。
Rule Of Three原則
Rule Of Three原則是指當一個功能直到第三次出現時，才進行功能提取。為什麼是三次？在數學領域如果要提取一個模型：
Complete the pattern:
1, 2, _, _, _, _
複製程式碼當這個模型只出現2次時，推導完整的模型是非常不清晰的，依靠出現2次的話可能有以下模型：
1. x2 模型
1, 2, 4, 8, 16, 32
複製程式碼2. +1 模型
1, 2, 3, 4, 5, 6
複製程式碼如果出現3次才進行模型提取：
Complete the pattern:
1, 2, 3, _, _, _
複製程式碼這個時候得到的模型將更加清晰，只會是+1模型。通過第三次重複才開始提取能更加確定這個模型，在程式碼中同樣適用這個理論，這樣能避擴音取錯誤模式情況下的浪費時間。
計算機領域其實有很多地方有3這個數字，比如HTTP需要最少3次握手才能建立信任關係下的穩定連線。並不是說大於3次不行當然是越多越好，但是3次是最少的次數。
總結
軟體開發中如果不依靠這些原則，假設有足夠的經驗和直覺下：
我們只看到一次出現的程式碼就進行抽象，這可能非常耗時因為特定場景的不同很多細節也有差異，這些差異會出現在抽象程式碼中，你的經驗和直覺可以給出更好的設計，但還是有風險。所以現在只管去做先不要抽象。
第二次出現就抽象能讓我們更好的瞭解哪些細節需要出現在抽象程式碼中，哪些不需要。但是抽象模型不夠清晰，可能在第三次出現時需要大量修改邏輯，這樣還是很費時。所以在第二次重複出現時不去抽象非常讓人反感，但是還是可以非常快的copy過去進行修改。
第三次出現再抽象，基本魔板已經確定，所有細節哪些需要抽象哪些不需要的也能確定。哪怕第四次出現的偏差也能快速確定是否需要抽象，快速調整。
上面介紹的三個原則相互補充，儘可能完善的指導我們何時才需要對程式碼進行抽象。幫助我們快速開發，節約時間。
何時重構？
什麼是重構？有兩種解釋：
重構（名詞）：對軟體內部結構的一種調整，目的是在不改變軟體可觀察行為的前提下，提高其可理解性，降低其修改成本。
重構（動詞）：使用一系列重構手法，在不改變軟體可觀察行為的前提下，調整其結構。
何時重構？
- 新增功能時重構
我無法理解之前的程式碼。
程式碼的設計無法幫助我們輕鬆新增我嗦需要的特性。
- 修復Bug時重構
程式碼結構複雜不容易看出bug，這時重構能幫助我們理清邏輯。快速看出Bug。
- review程式碼時重構
review是很有價值的事，在review過程中可以閱讀其他人的程式碼提出更多恰當的建議。同時重構能幫助我們更好的理解程式碼，提出更有意義的程式碼。但要記住一個團隊中保留多個意見也是很有必要的。
以上重構時間排列是有先後順序，同時重構前需要有足夠的測試用例或單元測試支撐。重構遍佈在每個版本開發過程中。
以上引用內容摘自《重構 改善既有程式碼的設計》，非常推薦。
總結
過度設計非常浪費時間，想半天可能再最後全盤推翻。絞盡腦汁，封裝極好的模組可能就一個地方在使用。
重構是軟體開發過程中不可缺少的一環，重構應該伴隨在整個版本開發過程。
希望上面兩點總結，能對大家有用。:)
參考
Abstraction: The Rule Of Three
