程式設計師重構入門指南
文章首發於公眾號「架構師指南」及個人部落格 shuyi.tech，歡迎關注訪問。
文章首發於公眾號「架構師指南」及個人部落格 shuyi.tech，歡迎關注訪問。
對於剛入門的編程者來說，《重構》是一本不錯的讀物。它能給你帶來一些重構思想上的改變，告訴你為什麼要重構，應該怎麼做重構。本文基於《重構》一書，整理重構所需的「思想」與「技巧」上的準備。
思想篇指的是對於重構的認識，理解這些思想能夠讓你更好地做好重構。而技巧篇指的是具體重構時的一些技巧，能夠讓你知道怎麼寫出更好的程式碼。
思想篇
重構之前先建立測試用例
重構的第一步，是為即將修改的程式碼建立一組可靠的測試用例。預見建立好的測試用例，是你的安全繩，它能告訴你工作是否完成了，是否存在可能的缺陷。
重構的價值
重構可以改進軟體的設計。就像在不斷整理程式碼一樣，經常性的重構可以幫助程式碼維持自己該有的形態。重構使得軟體更容易理解，不要讓幾個月之後其他人（甚至自己）也讀不懂你的程式碼，清晰易懂的程式碼能讓你更快理解程式碼的意圖。重構能幫助找到bug，因為重構是小步快跑的，每一步都有一個獵手（測試用例）幫你抓到獵物（bug）。
好的重構，最終能幫你提高編程速度，提高編程帶來的愉悅感。
文章首發於公眾號「架構師指南」及個人部落格 shuyi.tech，歡迎關注訪問。
什麼時候重構？
什麼時候重構？第一次只管去做，第二次會反感，第三次應該重構。事不過三，三則重構。
專門撥出時間重構是不可能的，我們需要在日常工作中不斷地重構。但是還沒開始有重複的功能，就想著重構，那太可笑了。但是重複的程式碼或者程式碼有問題，超過三次之後還不動手，那麼就有點偷懶了。
什麼時候不重構？
當現有程式碼根本不能正常運作的時候，你應該重寫，而不是重構。
重構應該是一個習慣
重構應該是一種工作習慣，在日常工作中一點點重構，而不是妄想有專門的時間重構。我們曾經進行的一些大型重構，需要數月甚至數年的時間。如果需要給一個運行中的系統添加功能，你不可能讓系統停止2個月去重構。你只能一點點地做你的工作，今天一點點，明天一點點。
如何測試？
我們的時間總是有限的，測試你最擔心出錯的部分，這樣你能得到最大的收益。測試的時候，尋找邊界條件，集中火力測試那裡！
什麼時候取消重構？
如果你感覺到重構失控了，那麼最好的辦法是取消重構，回到你的安全區去。等你重新能掌控的時候，再來做重構。
重構的團隊意識
進行大規模重構時，有必要為整個開發團隊建立共識。整個團隊都必須意識到：有一個大型重構正在進行，每個人都應該相應地安排自己的行動。
設計模式幫助你重構
學習設計模式可以很好地幫助你重構，它能在適當的場合幫助你承載複雜的業務。但你不應該簡單地了解，而是要多對比各個設計模式之間的區別，它們解決了什麼問題，適用於什麼場合。
技巧篇
不要出現重複程式碼
當出現重複程式碼時，你應該提取出公共方法。我想這個說得已經足夠清楚了，當出現重複程式碼的時候就需要想想：我是否需要抽離出重複的程式碼？
不要出現過長、過短的函數
當函數過長，你應該根據業務邏輯提煉出多個函數。那一個函數多少行算是長呢？按我個人理解，一個函數在 20-50 行是比較合適的。但這也只是一個經驗值，最根本的判斷標準是：別人閱讀你的程式碼的時候，是否能很清晰、很方便地讀懂。 如果你寫得很長，但是別人讀得時候很舒服，那麼也可以。
要注意函數過短也會帶來閱讀的困難，他會讓你多次跳轉，打斷你的閱讀思路。所以如果一個函數內容過短，你需要考慮是否去掉這個函數。簡單地說，你還是應該根據業務邏輯結構化，將每塊業務邏輯放到合適的函數中。
不要出現過大的類
當類過大，你應該考慮是否能拆分出多個類。或者你應該考慮，你的類抽象體系是否出現了問題。一個過大的類與過長的函數一樣，會讓人感覺到壓抑、難於讀懂。
不要讓參數過長
當參數列過長，你應該使用對象參數。
提煉發散式變化
因為一個變化，而需要修改多個地方，這說明出現了發散式變化，你需要考慮將變動的程式碼合併在一起。
提煉對象
總是綁在一起出現的數據，需要把他們提煉到一個獨立對象中。
引入解釋性變數
不要讓你的變數或表達式沒有語義，必要時引入解釋性變數。很多人會習慣性地用 flag 去承載一個表達式的值，但這並不是一個好的習慣。變數命名還是應該更加語義化，這樣我們能更加清晰地明白這個變數的作用。
搬移函數
一個函數被另一個類調用得很頻繁，那你可能得考慮把這個函數搬移到另一個類中。
搬移欄位
一個欄位被另一個類用得很頻繁，或許你改考慮把這個欄位搬移到另一個類中。
提煉類、簡化類
某個類做了應該由兩個類做的事情，此時應該提煉出一個新類，然後用組合關係組合起來。這其實與 SOLID 原則想契合，一個類應該是單一職責的，如果某個類做了兩個類的事情，那說明其承擔的職責就複雜了，因此需要抽離出一個新類出來。
而如果一個類並沒有太多內容，這時候就應該考慮是否去掉這個類，優化整個類結構。
文章首發於公眾號「架構師指南」及個人部落格 shuyi.tech，歡迎關注訪問。
參考資料
- 除舊迎新，試試《系統重構與遷移指南》 – 知乎
- 五個簡單的原則，帶你寫出整潔程式碼 – 知乎
- GitHub – phodal/migration: 《系統重構與遷移指南》手把手教你分析、評估現有系統、制定重構策略、探索可行重構方案、搭建測試防護網、進行系統架構重構、服務架構重構、模組重構、程式碼重構、資料庫重構、重構後的架構守護
- 技術債治理的四條原則 – ThoughtWorks 洞見
- 31 天重構指南 – InfoQ
- VIP！！！！Refactoring Day 1 : Encapsulate Collection · Los Techies
- 不要讓 「Clean Code」 更難維護，請使用 「Rule of Three」-InfoQ
