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