重構改善既有的代碼設計（重構原則）

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

---

兩頂帽子

添加新功能 添加新功能時不該該修改既有代碼，只管添加新功能，經過測試
重構 重構時你就不能再添加功能，只管改進程序結構，此時你不該該添加任何測試，只在絕對必要（用以處理接口變化）時才修改測試

爲什麼重構

• 重構改進軟件設計
• 重構使軟件更容易理解¹
• 重構幫助找到bug
• 重構提升編程速度²

什麼時候重構

• 三次法則：

  • 第一次作某件事時只管去作;第二次作相似的事會產生反感第三次再作相似的事，你就應該重構。（事不過三，三則重構）
• 添加功能時重構
• 修補錯誤時重構

重構的難題

• 數據庫重構

• 修改接口

  • 讓舊接口調用新接口，當你要修改某個函數的名稱時請留下舊函數，讓它調用新函數。千萬不要複製函數實現，那會讓你陷入重複代碼的泥淖中難以自拔。你還應該使用java中depreciation註解，將舊接口標記爲@deprecated。

• 難以經過重構手法完成設計的改動

  • 先想像重構的狀況。考慮選設計方案時，我會問本身：將某個設計重構爲另外一個設計的難度又多大？看上去很簡單，我就沒必要太擔憂選擇是否得當，因而我就會選擇最簡單的設計，哪怕他不能覆蓋全部潛在的需求也不要緊，但若是預先看不到簡單的重構辦法，我就會在設計上投入更多的力氣。
• 什麼時候不應重構
  現有代碼根本不能正常運做。重構以前，代碼必須起碼可以在大部分狀況下正常運做 若是項目已近最後的期限，你也應該避免重構，若是項目已經很是接近最後期限，你不該該再分心於重構，由於已經沒有時間了。重構可以提升生產力若是最後你沒有足夠時間，一般就表示你其實早該進行重構。

重構與設計

• 若是選擇重構，問題的重點就改變了，你仍然作預先設計，可是沒必要必定找出正確的解決方案，此刻的你只須要獲得一個足夠合理的解決方案就夠了。
• 有了重構，你就能夠經過一條不一樣的途徑來應付變化帶來的風險。你仍舊須要思考潛在的變化，仍舊須要考慮靈活的解決方案。可是你沒必要再主意實現這些解決方案而是應該問問本身："把一個簡單的解決方案重構成這個靈活的方案又多大難度？"若是答案是「至關容易」，那麼就只須要實現目前的簡單方案就好了。

間接層和重構（間接層的價值）

• 容許邏輯共享

  • 好比說一個子函數再兩個不一樣的地點被調用，或超類中的某個函數被全部子類共享

• 分開解釋意圖和實現

  • 你能夠選擇每一個類和函數的名字，這給你一個解釋本身意圖的機會。類或函數內部則解釋實現了這個意圖的作法。若是類和函數內部又以更小單元的意圖來編寫，你所寫的代碼就能夠描述其結構中的大部分重要信息

• 隔離變化

  • 極可能我在兩個不一樣的地點使用同一對象，其中一個地點我想改變對象行爲，但若是修改了它，我就要冒同時影響兩處的風險。爲此我作出一個子類，並在須要修改出引用這個子類。如今，我能夠修改這個子類而沒必要承擔午一中影響另外一處的風險。

• 封裝條件邏輯

  • 對象有一種奇妙的消息機制：多態消息，能夠靈活而清晰地表達條件邏輯。將條件邏輯轉化爲消息形式，每每能下降代碼的重複，增長清晰度並提升彈性。

---

1. 什麼是難以理解的程序：難以閱讀的程序，難以修改；邏輯重複的程序，難以修改；添加新行爲時須要修改已有的代碼的程序難以修改帶；複雜條件邏輯的程序，難以修改。 ↩
2. 咱們但願程序：容易閱讀；全部邏輯都旨在惟一地點指定；新的改動不會危機現有行爲；儘量簡單表達條件邏輯。 ↩