重構：對軟件內部結構的一種調整，目的是再不改變軟件的可觀察行為的前提下，提高其可理解性，降低其修改成本。
兩頂帽子
添加新功能 添加新功能時不應該修改既有代碼，只管添加新功能，通過測試
重構 重構時你就不能再添加功能，只管改進程序結構，此時你不應該添加任何測試，只在絕對必要（用以處理接口變化）時才修改測試
為何重構
何時重構
- 三次法則：
- 第一次做某件事時只管去做;第二次做類似的事會產生反感第三次再做類似的事，你就應該重構。（事不過三，三則重構）
- 添加功能時重構
- 修補錯誤時重構
重構的難題
- 數據庫重構
- 修改接口
- 讓舊接口調用新接口，當你要修改某個函數的名稱時請留下舊函數，讓它調用新函數 。千萬不要復制函數實現，那會讓你陷入重復代碼的泥淖中難以自拔。你還應該使用java中depreciation注解，將舊接口標記為
@deprecated。
- 讓舊接口調用新接口，當你要修改某個函數的名稱時請留下舊函數，讓它調用新函數 。千萬不要復制函數實現，那會讓你陷入重復代碼的泥淖中難以自拔。你還應該使用java中depreciation注解，將舊接口標記為
- 難以通過重構手法完成設計的改動
- 先想像重構的情況。考慮選設計方案時，我會問自己：將某個設計重構為另一個設計的難度又多大？看上去很簡單，我就不必太擔心選擇是否得當，於是我就會選擇最簡單的設計，哪怕他不能覆蓋所有潛在的需求也沒關系，但如果預先看不到簡單的重構辦法，我就會在設計上投入更多的力氣。
- 何時不該重構
現有代碼根本不能正常運作。重構之前，代碼必須起碼能夠在大部分情況下正常運作 如果項目已近最后的期限，你也應該避免重構，如果項目已經非常接近最后期限，你不應該再分心於重構，因為已經沒有時間了。重構能夠提高生產力如果最后你沒有足夠時間，通常就表示你其實早該進行重構。
重構與設計
- 如果選擇重構，問題的重點就改變了，你仍然做預先設計，但是不必一定找出正確的解決方案，此刻的你只需要得到一個足夠合理的解決方案就夠了。
- 有了重構，你就可以通過一條不同的途徑來應付變化帶來的風險。你仍舊需要思考潛在的變化，仍舊需要考慮靈活的解決方案。但是你不必再主意實現這些解決方案而是應該問問自己："把一個簡單的解決方案重構成這個靈活的方案又多大難度？"如果答案是“相當容易”，那么就只需要實現目前的簡單方案就行了。
間接層和重構（間接層的價值）
- 允許邏輯共享
- 比如說一個子函數再兩個不同的地點被調用，或超類中的某個函數被所有子類共享
- 分開解釋意圖和實現
- 你可以選擇每個類和函數的名字，這給你一個解釋自己意圖的機會。類或函數內部則解釋實現了這個意圖的做法。如果類和函數內部又以更小單元的意圖來編寫，你所寫的代碼就可以描述其結構中的大部分重要信息
- 隔離變化
- 很可能我在兩個不同的地點使用同一對象，其中一個地點我想改變對象行為，但如果修改了它，我就要冒同時影響兩處的風險。為此我做出一個子類，並在需要修改出引用這個子類。現在，我可以修改這個子類而不必承擔午一中影響另一處的風險。
- 封裝條件邏輯
- 對象有一種奇妙的消息機制：多態消息，可以靈活而清晰地表達條件邏輯。將條件邏輯轉化為消息形式，往往能降低代碼的重復，增加清晰度並提高彈性。