對於剛入門的程式設計者來說，《重構》是一本不錯的讀物。它能給你帶來一些重構思想上的改變，告訴你為什麼要重構，應該怎麼做重構。本文基於《重構》一書，整理重構所需的「思想」與「技巧」上的準備。

思想篇指的是對於重構的認識，理解這些思想能夠讓你更好地做好重構。而技巧篇指的是具體重構時的一些技巧，能夠讓你知道怎麼寫出更好的程式碼。

思想篇重構之前先建立測試用例

重構的第一步，是為即將修改的程式碼建立一組可靠的測試用例。預見建立好的測試用例，是你的安全繩，它能告訴你工作是否完成了，是否存在可能的缺陷。

重構的價值

重構可以改進軟體的設計。就像在不斷整理程式碼一樣，經常性的重構可以幫助程式碼維持自己該有的形態。重構使得軟體更容易理解，不要讓幾個月之後其他人（甚至自己）也讀不懂你的程式碼，清晰易懂的程式碼能讓你更快理解程式碼的意圖。重構能幫助找到bug，因為重構是小步快跑的，每一步都有一個獵手（測試用例）幫你抓到獵物（bug）。

好的重構，最終能幫你提高程式設計速度，提高程式設計帶來的愉悅感。

專門撥出時間重構是不可能的，我們需要在日常工作中不斷地重構。但是還沒開始有重複的功能，就想著重構，那太可笑了。但是重複的程式碼或者程式碼有問題，超過三次之後還不動手，那麼就有點偷懶了。

什麼時候不重構？

當現有程式碼根本不能正常運作的時候，你應該重寫，而不是重構。

重構應該是一個習慣

重構應該是一種工作習慣，在日常工作中一點點重構，而不是妄想有專門的時間重構。我們曾經進行的一些大型重構，需要數月甚至數年的時間。如果需要給一個執行中的系統新增功能，你不可能讓系統停止2個月去重構。你只能一點點地做你的工作，今天一點點，明天一點點。

如何測試？

我們的時間總是有限的，測試你最擔心出錯的部分，這樣你能得到最大的收益。測試的時候，尋找邊界條件，集中火力測試那裡！

什麼時候取消重構？

如果你感覺到重構失控了，那麼最好的辦法是取消重構，回到你的安全區去。等你重新能掌控的時候，再來做重構。

重構的團隊意識

進行大規模重構時，有必要為整個開發團隊建立共識。整個團隊都必須意識到：有一個大型重構正在進行，每個人都應該相應地安排自己的行動。

設計模式幫助你重構

學習設計模式可以很好地幫助你重構，它能在適當的場合幫助你承載複雜的業務。但你不應該簡單地瞭解，而是要多對比各個設計模式之間的區別，它們解決了什麼問題，適用於什麼場合。

技巧篇不要出現重複程式碼

當出現重複程式碼時，你應該提取出公共方法。我想這個說得已經足夠清楚了，當出現重複程式碼的時候就需要想想：我是否需要抽離出重複的程式碼？

不要出現過長、過短的函式

當函式過長，你應該根據業務邏輯提煉出多個函式。那一個函式多少行算是長呢？按我個人理解，一個函式在 20-50 行是比較合適的。但這也只是一個經驗值，最根本的判斷標準是：別人閱讀你的程式碼的時候，是否能很清晰、很方便地讀懂。 如果你寫得很長，但是別人讀的時候很舒服，那麼也可以。

要注意函式過短也會帶來閱讀的困難，他會讓你多次跳轉，打斷你的閱讀思路。所以如果一個函式內容過短，你需要考慮是否去掉這個函式。簡單地說，你還是應該根據業務邏輯結構化，將每塊業務邏輯放到合適的函式中。

不要出現過大的類

當類過大，你應該考慮是否能拆分出多個類。或者你應該考慮，你的類抽象體系是否出現了問題。一個過大的類與過長的函式一樣，會讓人感覺到壓抑、難於讀懂。

不要讓引數過長

當引數列過長，你應該使用物件引數。

提煉發散式變化

因為一個變化，而需要修改多個地方，這說明出現了發散式變化，你需要考慮將變動的程式碼合併在一起。

提煉物件

總是綁在一起出現的資料，需要把他們提煉到一個獨立物件中。

引入解釋性變數

不要讓你的變數或表示式沒有語義，必要時引入解釋性變數。很多人會習慣性地用 flag 去承載一個表示式的值，但這並不是一個好的習慣。變數命名還是應該更加語義化，這樣我們能更加清晰地明白這個變數的作用。

搬移函式

一個函式被另一個類呼叫得很頻繁，那你可能得考慮把這個函式搬移到另一個類中。

搬移欄位

一個欄位被另一個類用得很頻繁，或許你該考慮把這個欄位搬移到另一個類中。

提煉類、簡化類

某個類做了應該由兩個類做的事情，此時應該提煉出一個新類，然後用組合關係組合起來。這其實與 SOLID 原則想契合，一個類應該是單一職責的，如果某個類做了兩個類的事情，那說明其承擔的職責就複雜了，因此需要抽離出一個新類出來。

而如果一個類並沒有太多內容，這時候就應該考慮是否去掉這個類，最佳化整個類結構。