第一章 重構：第一個案例

重構之前，首先檢查自己是否有一套可靠的測試機制。這些測試必須有自我檢驗能力。

重構技術就是以微小的步伐修改程序。如果你犯下錯誤，很容易便可發現它。

任何一個傻瓜都能寫出計算機可以理解的代碼，唯有寫出人類容易理解的代碼，才是優秀的程序員。
代碼應該表現自己的目的，這一點非常重要。

重構的節奏：測試、小修改、測試、小修改…正是這種節奏讓重構得以快速而安全地前進。

第二章 重構原則

重構（名詞）：對軟件內部結構的一種調整，目的是在不改變軟件可觀察行為的前提下，提高其可理解性，降低其修改成本。
重構（動詞），使用一系列重構首發，在不改變軟件可觀察行為的前提下，調整其結構。

添加新功能時，你不應該修改既有代碼，只管添加新功能。通過測試，你可以衡量自己的工作進度。
重構時你就不能再添加新功能，只管改進程序結構。此時你不應該添加任何測試（除非發現先前遺漏的東西），只在絕對必要（用于處理接口變化）時才修改測試。

重構本來就不是一件應該特別撥出時間做的事情，重構應該隨時隨地進行。你不應該為重構而重構，你之所以重構，是因為你想做別的什么事，而重構可以幫助你把那些事做好。

添加功能時重構；修補錯誤時重構；復審代碼時重構

是什么讓程序難以修改？

• 難以閱讀的程序，難以修改
• 邏輯重復的程序，難以修改
• 添加新行為時需要修改已有代碼的程序，難以修改
• 帶復雜條件邏輯的程序，難以修改

何時不該重構？

有時候你根本不應該重構，例如當你應該重新編寫所有代碼的時候。有時候既有代碼寫的太混亂，重構它還不如重新寫一個來得簡單。重寫的一個清楚訊號就是：現有代碼根本不能正常運作。而‘重構’之前，代碼必須起碼在大部分情況下正常運作。

重構的確能夠提高生產力。如果你最后沒有足夠時間，通常就表示你其實早該進行重構。

重構與設計

初學編程時，渾渾噩噩地進行開發。然而很快我便發現，事先做好設計可以讓我節省返工的高昂成本

第三章 代碼的壞味道

• 重復代碼
• 過長函數
• 過大的類
• 過長參數列（有了對象，你就不必把函數需要的所有東西以參數傳遞給它了。太長的參數列難以理解。）
• 發散式變化（我們希望一旦需要修改，就只在某一點處修改）
• 依戀情結（某個函數為了計算某個值，從另一個對象那兒調用了大部分函數）
• 過度耦合的消息鏈
• 異曲同工的類（兩個函數做同一件事，卻有著不同的函數名）
• 過多的注釋（長長的注釋之所以存在是因為代碼很糟糕。當代碼已經清楚的說明一切時，注釋就多余了。當你感覺需要撰寫注釋時，請先嘗試重構，試著讓所有注釋都變得多余。）

每當感覺需要以注釋來說明點什么的時候，我們就把需要說明的東西寫進一個獨立函數中，并以其用途（而非實現手法）命名。哪怕替換后的函數調用動作比函數自身還長，只要函數名稱能夠解釋其用途，我們也該毫不猶豫地那么做。關鍵不在于函數的長度，而在于函數“做什么”和“如何做”之間的語義距離。

條件表達式和循環常常也是提煉的信號。你應該將循環和其內的代碼提煉到一個獨立的函數中。

測試
編寫測試代碼時，我往往一開始先讓他們失敗。之所以這么做，是為了向自己證明：測試機制的確可以運行，并且的確測試了它該測試的東西。

總結

以上是生活随笔為你收集整理的《重构：改善既有代码的设计》阅读笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。