總覽 第1章 重構，第一個案例

• 1.1 (P1)起點
• 1.2 (P7)重構的第一步

第2章 重構原則

• 2.1 (P53)何謂重構
• 2.2 (P55)為何重構
• 2.3 (P57)何時重構
• 2.4 (P60)怎么對經理說
  • 間接訪問
• 2.5 (P62)重構的難題
• 2.6 (P66)重構與設計
• 2.7 (P69)重構與性能

第3章 代碼的壞味道

• 3.1 (P76)Duplicated Code（重復代碼）
• 3.2 (P76)Long Method（過長函數）
• 3.3 (P78)Large Class（過大的類）
• 3.4 (P78)Long Parameter List（過長參數列）
• 3.5 (P79)Divergent Change（發散式變化）
• 3.6 (P80)Shotgun Surgery（霰彈式修改）
• 3.7 (P80)Feature Envy（依戀情結）
• 3.8 (P81)Data Clumps（數據泥團）
• 3.9 (P81)Primitive Obsession（基本類型偏執）
• 3.10 (P82)Switch Statements（switch驚悚現身）
• 3.11 (P83)Parallel Inheritance Hierarchies（平行繼承體系）
• 3.12 (P83)Lazy Class（冗贅類）
• 3.13 (P83)Speculative Generality（夸夸其談未來性）
• 3.14 (P84)Temporary Field（令人迷惑的暫時字段）
• 3.15 (P84)Message Chains（過度耦合的消息鏈）
• 3.16 (P85)Middle Man（中間人）
• 3.17 (P85)Inappropriate Intimacy（狎昵關系）
• 3.18 (P85)Alternative Classes with Different Interfaces（異曲同工的類）
• 3.19 (P86)Incomplete Library Class（不完美的庫類）
• 3.20 (P86)Data Class（幼稚的數據類）
• 3.21 (P87)Refused Bequest（被拒絕的遺贈）
• 3.22 Comments（過多的注釋）87

第4章 構筑測試體系

• 4.1 自測試代碼的價值89
• 4.2 JUnit測試框架91
• 4.3 添加更多測試97

第12章 大型重構359 第13章 重構，復用與現實379

• 安全重構（391）
• 重構工具

第14章 重構工具401

《重構》的讀書筆記

學習基礎：

熟悉《設計模式》的基本概念，熟悉基本的Java語法，熟悉Eclipse和JUnit的使用，有相對較好的英語基礎。

學習過程：

• 先看第1章，手工輸入實例程序，了解重構的方法和過程。重點是理解重構的思路，最好的理解方式就是通過實踐的方式理解。
• 再看第2~4章，內容為選擇性閱讀，沒興趣或者看不懂的都可以跳過，因為后面還可以回頭再讀。
• 接著第5~12章，最好按順序把代碼一個個輸入，再按照作者的步驟重構操作一次，并結合自己以往工作中的實踐來理解。

學習目的：

使自己編寫的代碼更容易被人讀懂。

學習感悟：

• 代碼的重構應該是一步步完成的，每次重構的部分不要超過自己的理解能力的5%。雖然這樣操作略顯繁瑣，但是可以減輕頭腦重構過程中的記憶強度，減少代碼出錯的機會。
• 代碼的重構一定要配合JUnit（TDD，測試驅動開發）完成，再加上Git（版本管理）和Eclipse（IDE的重構工具）那就事半功倍了。

學習代碼：

Refactored-MartinFowler

總覽

• 第1章（必讀），從實例程序出發，了解重構的方法和過程。
• 第2章，討論重構的一般性原則、定義和進行重構的原因。
• 第3章，介紹如何判斷問題代碼，以及如何用重構改善它們。
• 第4章，在代碼中構建java的測試環境
• 第5~12章，具體面對的問題和重構的方法。
• 第13章，Bill Opdyke在商業開發中應用重構
• 第14章，自動化重構工具（今天看來，已經不是太大問題，Eclipse的Refactor已經非常好用）
• 第15章，重構的哲學思想

第1章 重構，第一個案例

1.1 (P1)起點

因為代碼的結構無法滿足添加新功能的需要，因此先進行重構，使代碼方便添加新功能，然后再添加新功能。

1.2 (P7)重構的第一步

首先確認自己擁有一套可靠的測試機制，因為重構有可能引入問題，通過測試保證重構沒有改變程序功能。

第2章 重構原則

2.1 (P53)何謂重構

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

• 重構讓軟件更容易理解和修改
• 重構不會改變軟件的可觀察行為，即使改變也只能是微小的影響，軟件功能一如既往。

重構的目標：只改變程序內部結構，不添加新的功能

不要一心二用：

• 添加新功能的時候，不重構已有代碼。
• 重構代碼時，不增加新功能。

2.2 (P55)為何重構

• 重構改進軟件設計：
  • 程序的設計質量在沒有持續重構的情況下逐漸變差，功能的增加或者修改都可能使代碼越來越難以理解和維護，就越難保證最初的設計目標
  • 消除重復的代碼一方面是程序運行更快，一方面是方便未來的修改，例如：重構減少代碼重復，避免功能的改變需要修改多處代碼。
• 重構使軟件更容易理解：
  • 及時填補“想要它做什么”和“告訴它做什么”之間的縫隙。重構的核心就是要“準確說出我所要的”
  • 重新閱讀代碼的人有可能是自己，也可能是他人。
  • 通過重構可以把自己不熟悉的代碼的用途梳理一遍，加深對代碼的理解
• 重構幫助找出bug：
  • 這個是建立在代碼容易理解之上的
• 重構提高編程速度：
  • 重構達到良好的設計，而良好的設計更容易修改代碼、增加功能、問題調試。

2.3 (P57)何時重構

重構的三次法則：

• 第一次開發某個功能的時候以實現為目標。
• 第二次開發相同功能的時候，克制自己的反感，繼續重復實現。
• 第三次開發相同功能的時候，應該重構。

重構的時間點：

• 添加功能時重構：
  • 一方面可以幫助理解需要修改的代碼
  • 一方面是使現在以及未來增加新功能更加容易。
• 修補錯誤時重構：
  • 出現bug的時候，難以找出問題所在的時候，很有可能是代碼不清晰導致查找bug的困難。
• 復審代碼時重構：
  • 復審代碼有助于知識的傳播，有利于代碼被編寫者之外的人理解。
  • 重構加深了對代碼的理解，有利于提升復審代碼的能力

復審團隊：只要代碼作者和一個審查者者。較大的項目可以通過UML圖去展示代碼的邏輯。

程序難以修改的原因：

• 難以閱讀的程序
• 邏輯重復的程序
• 添加新特性需要修改已有代碼的程序
• 帶復雜邏輯判斷的程序

重構的目標：

• 代碼容易閱讀
• 所有邏輯都只有唯一地點指定
• 新的改動不會危及現有行為
• 盡可能簡單表達邏輯

2.4 (P60)怎么對經理說

• 懂技術的經理，很容易溝通；
• 追求質量的經理，介紹重構對質量的幫助；
• 追求進度的經理，則自己安靜地重構。因為重構可以最快的完成任務，就是對經理最大的幫助。

間接訪問

很多時候重構都為程序引入間接訪問：

• 把大型對象拆分成小對象
• 把大型函數拆分為小型函數。

間接訪問的價值：

• 允許邏輯共享：一個函數在不同地點被調用。子類共享超類的方法。
• 分開解釋意圖和實現：通過類名和函數名解釋自己的意圖
• 隔離變化：在不同地方使用同一個對象，需要修改一處邏輯，那么可以做出子類，并在需要的時候修改這個子類。
• 封裝條件邏輯：運用多態。將條件邏輯轉化為消息模式。

減少間接層的條件:當間接層只在一處使用，那么需要將其消除。

2.5 (P62)重構的難題

數據庫重構：

• 存在問題：
  • 程序與數據庫耦合在一起。
  • 數據遷移。
• 解決方案：
  • 在非關系型數據庫，可以在數據庫和對象模型中插入一個分離層，隔離兩者之間的變化

接口重構

• 對于已經發布的接口需要可能需要維護舊接口和新接口，用deprecated修飾舊接口。
• 不發布新接口，在舊接口中調用新接口。
• 假如新接口拋出編譯時異常，那么可以在舊接口中調用新接口并將編譯時異常轉化為運行時異常。

不重構的條件：

• 重構之前，代碼在大部分情況下都能夠正常運行，就可以重構，否則應該是重寫。
• 到了Deadline，應該避免重構。

2.6 (P66)重構與設計

重構與設計是彼此互補的：

• 設計應該在編碼之前，但是設計總有缺陷，隨著對問題認識的逐漸深入，通過重構可以改善設計的質量。
• 重構減輕了設計的難度和壓力，在程序不斷修改的過程中逐步完善程序的設計。

2.7 (P69)重構與性能

重構是有可能導致程序運行變慢的，但是不需要在設計和編碼時就考慮性能問題。例如：實時程序的編寫：

• 首先寫出可調的程序
• 然后調整它以達到性能的要求。
  • 經過分析大部分程序的主要時間是消耗在小部分代碼上，所以不用對所有代碼進行優化。
  • 性能優化放在開發的后期，利用分析工具找出消耗大量時間的代碼，然后集中優化。

第3章 代碼的壞味道

3.1 (P76)Duplicated Code（重復代碼）

• 同個類兩個函數存在相同表達式：Extract Method（提煉函數）
• 互為兄弟類內存在相同表達式：
  • Extract Method→PullUp Method（函數上移）
  • 如果代碼只是相似：先運用Extract Method（提煉函數）分開再Form TemPlate Method（塑造模板函數）
• 兩個毫不相干的類存在重復代碼：Extract Class（提煉類）

3.2 (P76)Long Method（過長函數）

原則：盡量利用函數名稱來解釋用途，而不是注釋。
關鍵：代碼主要用來描述“做什么”，而不是描述“怎么做”。例如：getAge()表達獲取年齡，而today-birthday就增加了理解的間接性，雖然看代碼的人也能明白含義，但是就需要多想一下，并且birthday有可能表達的不是某個人的出生日期呢，而是某個買回來的產品的呢？那可能表達的就是使用時長了。
具體情況：

• 函數有大量參數和臨時變量：Extract Method（提煉函數）
• 用Replace Temp with Query（以查詢取代臨時變量）消除臨時變量
• 用Introduce Parameter Object（引入參數對象）或者Preserve Whole Object（保持對象完整）來將多長的參數列表變得簡潔一點。
• 如果按照上述步驟還存在太多變量和參數就需要用到Replace Method with Method Object（以函數對象取代函數）
• 條件表達式可以用Decompose Conditional（分解條件表達式）解決
• 可以將循環內的代碼提煉為函數。

3.3 (P78)Large Class（過大的類）

有時候類并非在所有時刻都使用實例變量：使用Extract Method和Extract Subclass（提煉子類）

類中有太多代碼：

• Extract Class（提煉類）
• Extract Subclass（提煉子類）
• Extract Interface（提供接口）分解類的行為。存在GUI的時候，可以Duplicate Observed Data（復制“被監視數據”），分離數據和行為到業務模型中去。

3.4 (P78)Long Parameter List（過長參數列）

• 如果可以調用已有對象獲取的話可以使用Replace Parameter with Methods（以函數取代參數）
• 將來自同一對象的數據收集起來，以該對象替代：Preserve Whole Object（保持對象完整）
• 如果幾個參數總是同時出現，那么可以考慮Introduce Parameter Object（引入參數對象）

3.5 (P79)Divergent Change（發散式變化）

不同的變化影響著相同的類發生改變，即變化的認知有分歧（Divergent）。通過Extract Class把不同的功能封裝到不同的類中，使每個類只因一種變化而需要修改

3.6 (P80)Shotgun Surgery（霰彈式修改）

相同的變化會涉及到多個類發生修改，類似霰彈槍射擊的效果。
可以通過Extract Method，Move Method，Inline Class把一種變化產生的多個修改移到同一個類中。

對比：

• Divergent Change（發散式變化）是一個類受到的多個變化影響；
• Shotgun Surgery（霰彈式修改）是一個變化引起多個類需要修改。

3.7 (P80)Feature Envy（依戀情結）

類中的某個函數對其他類的依賴度過高，則應該通過Move Method（移動函數）將它搬移到合適的類中。

3.8 (P81)Data Clumps（數據泥團）

數據項總是成群結隊出現，通過Extract Class將它們提煉到一個獨立對象中，從而縮短參數列表，簡化函數調用。

判斷數據項是否相關的方法：如果這些數據項不在一起時就失去了明確的含義，那么就可以把它們提煉成一個新的對象。

3.9 (P81)Primitive Obsession（基本類型偏執）

• 有些字段可以用對象表示更準確Replace Data Value with Object（以對象取代數據值）
• 對于不影響行為的類型碼可以Replace Type Code with Class（以類取代類型碼）
• 影響行為的類型碼可以Replace Type Code with Subclasses（以子類取代類型碼），類型碼在運行時會變化就用Replace Type Code with State/Strategy（以State/Strategy取代類型碼）

3.10 (P82)Switch Statements（switch驚悚現身）

• 使用Replace Type Code with Subclasses（以子類取代類型碼）或者Replace Type Code with State/Strategy（以State/Strategy取代類型碼）
• 輕量級的解決方法：Replace Parameter with Explicit Methods（以明確函數取代參數）

3.11 (P83)Parallel Inheritance Hierarchies（平行繼承體系）

每當為一個類增加子類必須也為另外一個類增加一個子類，那么就讓一個繼承體系的實例引用另一個繼承體系的實例。

3.12 (P83)Lazy Class（冗贅類）

沒用的類，使用Inline Class（內聯類）或者Collapse Hierarchy（折疊繼承體系）來解決

3.13 (P83)Speculative Generality（夸夸其談未來性）

• 為未來設計的類，使用Inline Class（內聯類）或者Collapse Hierarchy（折疊繼承體系）來解決
• 為未來設計的函數參數，使用Remove Parameter（移除參數）
• 函數名稱啰嗦，使用Rename Method（函數改名）

3.14 (P84)Temporary Field（令人迷惑的暫時字段）

對象中某個字段僅為特定情況而設。使用Extract Class（提煉類）將這個字段提取出來

3.15 (P84)Message Chains（過度耦合的消息鏈）

消息鏈：用戶通過一個對象獲取另一個對象，再通過獲取的對象請求另一個對象，如此操作就是消息鏈。采取這種方式意味著客戶代碼將與查找過程中的導航結構緊密耦合，可以使用Hide Delegate（隱藏“委托關系”）進行重構。但是謹慎處理！

3.16 (P85)Middle Man（中間人）

過度委托形成中間人:Remove Middle Man（移除中間人）

如果中間人還有其他行為,Replace Delegation with Inherited（以繼承取代委托）

3.17 (P85)Inappropriate Intimacy（狎昵關系）

• 兩個類相互依賴過多，花費大量時間去獲取對方的private成員內容，使用Move Field（移動字段）和Move Method（移動方法）減少耦合性，或用Change Bidirectional Association to Unidirectional（將雙向關聯改為單向關聯）
• 如果兩個類無法移動相同數據和函數，可以使用Extract Class（提煉類）,讓他們使用新類進行交互。

3.18 (P85)Alternative Classes with Different Interfaces（異曲同工的類）

兩個函數做了相同的事情卻有不同的函數名稱

3.19 (P86)Incomplete Library Class（不完美的庫類）

庫函數功能不足，需要增加一些自定義的功能：

• 需要加入少量操作，使用Introduce Foreign Method（引入外加函數）
• 需要加入大量操作，使用Introduce Local Extension（引入本地擴展）

3.20 (P86)Data Class（幼稚的數據類）

幼稚的數據類：只有數據沒有行為的類，其他類需要對該類的數據進行取值設值操作

• 使用Encapsulate Field（封裝字段）和Encapsulate Collection（封裝集合）對字段進行合理地封裝
• 對于不該被其他類修改的字段:Remove Setting Method（移除設值函數）

3.21 (P87)Refused Bequest（被拒絕的遺贈）

如果子類不愿意接受超類的所有定義，應該使用Replace inherited with Delegation（以委托取代繼承）來處理子類

3.22 Comments（過多的注釋）87

使用Extract Method（提煉方法）來解決注釋過多問題，注釋更多應該說明的是“怎么做”，而不是“做什么”，例如：對一個排序函數說明其采用二分法排序，而不是說明它是個排序函數，因為這個說明在函數名稱中已經具備。

第4章 構筑測試體系

4.1 自測試代碼的價值89

• 確保所有測試都完全自動化，讓它們檢查自己的測試結果；
• 一套測試就是一個強大的bug探測器，能夠大大縮減查找bug所需要花費的時間。
  • 因為代碼剛剛寫完，測試出現問題后，心里很清楚自己修改或者添加了哪些東西，可能會在哪里出現了問題。

    4.2 JUnit測試框架91

• 頻繁地運行測試；
• 每次編譯前都進行一次測試；
• 每天至少執行一次所有的測試。

  4.3 添加更多測試97

• 編寫一個測試并運行起來，好過將所有的測試編好了一起運行。
• 測試特別需要注意可能出錯的邊界條件；
• 對于可能出錯的地方，還需要檢查是否拋出了預期的異常；
• 測試不能解決所有bug，但是可以大大減少bug的數量。

第12章 大型重構359

大型重構是程序開發必將遇到的，只是不知道在什么時間，用什么樣的方式經歷。例如：隨著時間的推移，河道必定會被水草和垃圾所堵塞，你可以固定時間清淤，也可以放任自流直到崩潰。崩潰后依然會面臨總結經驗教訓，再次重構系統。
大型重構很難給出具體的操作案例，因為每個大型案例相對于自身來說都是惟一的，是無法復制和重現的。可以復制與重現的都是這些大型重構中蘊含的具體的細節，因此這章主要講的是思想和理念上的內容。
四個大型重構：

• Tease Apart Inheritance（362）用于處理混亂的繼承體系
  • 某個繼承體系同時承擔兩項責任
  • 建立兩個繼承體系，其中一個通過委托調用另一個
• Convert Procedural Design to Objects（368）如何重構過時的編碼技術遺留下來的程序
  • 傳統過程化風格的代碼
  • 將數據記錄變成對象，將大塊的行為分成小塊，再將它們移入到相關對象中
• Separate Domain from Presentation（370）將業務邏輯與用戶界面分隔開來
  • 用戶界面類中包含了業務邏輯
  • 將業務邏輯剝離到業務類中，參考：MVC模式
• Extract Hierarchy（375）將復雜的類轉化為一群簡單的子類，從而簡化系統。
  • 某個類做了太多工作
  • 某個類的部分工作是由大量的條件表達式完成的
  • 建立繼承體系，使用子類表示每一種特殊情況

第13章 重構，復用與現實379

作為一個博士寫的內容，仍然具有學術性較強的風格，可以當作歷史資料了解一下重構的發展過程，也可以對重構的思想有更多理論上的認識。

安全重構（391）

安全重構的四條籬笆：

• 相信你自己的編碼能力；
• 相信你的編譯器能捕捉你遺漏的錯誤；
• 相信你的測試套件能捕捉你和編譯器都遺漏的錯誤；
• 相信代碼復審能捕捉你、編譯器和測試套件都遺漏的錯誤。注：沒有100%安全的重構，但是可以通過以上的條件滿足你對安全性的最低要求。

重構工具

• Eclipse（或其他IDE）自帶的重構工具：Refactor；
• Java（或其他編譯器）自帶的分析工具：lint；
• JUnit等自動化的測試工具。

第14章 重構工具401

相對于10多年前寫的內容，現在許多IDE都已經提供了對大部分重構功能的支持。但是了解重構的基本理念，對于正確地使用重構工具會有很大的幫助。因為成功的重構不依賴于工具，而決定于人，當人做出了正確的決定，合理地使用重構工具輔助自己，才能保證重構的完成。

轉載于:https://www.cnblogs.com/zhuyx/p/10278392.html

總結

以上是生活随笔為你收集整理的《重构》的读书笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

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