設計和架構：業務開發指導原則

計劃寫一個系列文章，總結本身在四年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過去進行修改。

第三次出現再抽象，基本魔板已經肯定，全部細節哪些須要抽象哪些不須要的也能肯定。哪怕第四次出現的誤差也能快速肯定是否須要抽象，快速調整。

上面介紹的三個原則相互補充，儘量完善的指導咱們什麼時候才須要對代碼進行抽象。幫助咱們快速開發，節約時間。

什麼時候重構？

什麼是重構？有兩種解釋：

重構（名詞）：對軟件內部結構的一種調整，目的是在不改變軟件可觀察行爲的前提下，提升其可理解性，下降其修改爲本。

重構（動詞）：使用一系列重構手法，在不改變軟件可觀察行爲的前提下，調整其結構。

什麼時候重構？

1. 添加功能時重構

我沒法理解以前的代碼。

代碼的設計沒法幫助咱們輕鬆添加我嗦須要的特性。

2. 修復Bug時重構

代碼結構複雜不容易看出bug，這時重構能幫助咱們理清邏輯。快速看出Bug。

3. review代碼時重構

review是頗有價值的事，在review過程當中能夠閱讀其餘人的代碼提出更多恰當的建議。同時重構能幫助咱們更好的理解代碼，提出更有意義的代碼。但要記住一個團隊中保留多個意見也是頗有必要的。

以上重構時間排列是有前後順序，同時重構前須要有足夠的測試用例或單元測試支撐。重構遍及在每一個版本開發過程當中。

以上引用內容摘自《重構 改善既有代碼的設計》，很是推薦。

總結

過分設計很是浪費時間，想半天可能再最後全盤推翻。絞盡腦汁，封裝極好的模塊可能就一個地方在使用。

重構是軟件開發過程當中不可缺乏的一環，重構應該伴隨在整個版本開發過程。

但願上面兩點總結，能對你們有用。:)

參考

《程序員修煉之道》

Abstraction: The Rule Of Three

《重構 改善既有代碼的設計》