《重構 改善既有代碼的設計 1》重構原則

前言

重構 既有代碼的設計，一本經典神書，兩年前入手，一年前看了一半，感覺一般般，今天起，再次拜讀，希望會有不一樣的識訓！

/**
* @startTime 2020-12-16 23:22
* @endTime 2020-12-16 23:59
* @startPage 1 
* @endPage 55
* @efficiency 56/1 = 56頁/天
* @needDays 412/56 = 7天
* @overDay 2020-12-16 + 7天 = 2020-12-22 
*/

第1章 重構，第一個案例

所謂重構，是在不改變代碼外在行為的前提下，對代碼做出修改，以改行程式的內部結構，重構是一種千錘百煉形成的有條不紊的程式整理方法，可以最大限度地減少整理程序中引入錯誤的幾率，本質上說，重構就是在代碼寫好之后改進它的設計，

任何一個傻瓜都能寫出計算機可以理解的代碼，唯有寫出人類容易理解的代碼，才是優秀的程式員，

第2章 重構原則

1、何謂重構

對軟體內部結構的一種調整，目的是在不改變軟體可觀察行為的前提下，提高其可理解性，降低其修改成本，

重構的目的是使軟體更容易被理解和修改，

越難看出代碼所代表的設計意圖，就越難保護其中的設計，經常性的重構可以幫助代碼保持自己該有的形態，完成同一件事，設計不良的程式往往需要更多的代碼，這常常是因為代碼在不同的地方使用完全相同的陳述句做同樣的事情，因此改進設計的一個重要方向就是消除重復代碼，這個動作的重要性在于方便未來的修改，代碼量減少并不會使系統運行更快，因為這對程式運行軌跡幾乎沒有任何明顯影響，然而代碼量減少將使未來可能的程式修改動作容易得多，

/**
* @startTime 2020-12-17 22:00
* @endTime 2020-12-17 22:50
* @startPage 56 
* @endPage 64
* @efficiency 64/2 = 32頁/天
* @needDays 412/32 = 13天
* @overDay 2020-12-16 + 13天 = 2020-12-29 
*/

2、重構使軟體更容易理解

讓review的人更容易理解，讓下一個接手你代碼的人，更容易理解，也許下一個接手你代碼的人就是你自己，有的時候，一段代碼拿過來，是不是你自己寫的，你都確定不了，對吧？

• 重構的好處
• 重構幫助找到bug
• 重構提高編程速度

3、重構的時機

• 事不過三，三則重構
• 添加功能時重構
• 修改錯誤時重構
• 復審代碼時重構

4、為什么重構有用

1. 難以閱讀的程式，難以修改；
2. 邏輯重復的程式，難以修改；
3. 添加新行為時需要修改已有代碼的程式，難以修改；
4. 帶復雜條件邏輯的程式，難以修改；

因此，我們希望程式：

1. 容易閱讀；
2. 所有邏輯都只在唯一地點指定；
3. 新的改動不會危及現有行為；
4. 盡可能簡單表達條件邏輯；

間接層和重構

間接層的價值：

1. 允許邏輯共享；
2. 分開解釋意圖和實作；
3. 隔離變化；
4. 封裝條件邏輯；

5、重構的難題

（1）資料庫

資料遷移

（2）修改介面

不要過早發布介面，請修改你的代碼所有權政策，使重構更順暢，

（3）難以通過重構手法完成的設計改動

（4）何時不該重構

/**
* @startTime 2020-12-20 11:50
* @endTime 2020-12-20 15:30
* @startPage 65 
* @endPage 102
* @efficiency 102/5 = 20.4頁/天
* @needDays 412/20.4 = 20天
* @overDay 2020-12-16 + 20天 =  2020-01-04
*/

6、重構和設計

很多人都把設計看做軟體開發的關鍵環節，而把編程看做只是機械式的低級勞動，他們認為設計就像畫工程圖而編碼就像施工，

哪怕你完全了解系統，也請實際度量它的性能，不要臆測，臆測會讓你學到一些東西，但十有八九你是錯的，

7、重構和性能

首先寫出可調的軟體，然后調整它以獲得足夠的速度，

三種撰寫快速軟體的方法：

（1）時間預演算法

通常用于性能要求極高的實時系統，

分解設計時要做好預算，給每個組件預先分配一定的資源，包括時間和執行軌跡，每個組件決不能超出自己的預算，就算擁有組件之間的調度預配時間的機制也不行，

這種方法高度重視性能，對于心率調節器一類的系統是必須的，因為這樣的系統中遲來資料就是錯誤的，但對一些管理系統來說，如此追求性能就有點過分了，

（2）持續關注法

這種方法要求任何程式員在任何時間做任何事情時，都要設法保證系統的高性能，

這種方法看起來很常見，感覺上很有吸引力，但通常不會起太大作用，

（3）性能優化階段

撰寫程式時，不用將過多的精力關注在性能上，在代碼開發完畢之后，會有一個性能優化階段，一旦進入該階段，就按照某個特定程式來調整程式性能，

在性能優化階段，首先應該用一個度量工具來監控程式的運行，讓它告訴你程式中哪些地方大量消耗時間和空間，這樣就可以找出性能熱點所在的一小段代碼，然后應該集中關注這些熱點代碼，并使用持續關注法中的優化手段來優化它們，每走一步都需要編譯、測驗、再次度量，

8、重構起源何處

第三章 代碼的壞味道

1、重復代碼

同一個類中兩個函式含有相同的運算式時，就要提煉出重復的代碼，然后讓這兩個地點都呼叫被提煉出來的那一段代碼，

2、過長函式

間接層所帶來的全部利益，解釋能力、共享能力、選擇能力，

應該更積極的分解函式，每當感覺需要注釋來說明點什么的時候，我們就把需要說明的東西寫進一個獨立函式中，并以其用途（而非實作手法）命名，我們甚至可以對一組甚至一行代碼做這件事，哪怕替換后的函式呼叫動作比函式自身還長，只要函式名稱能夠解釋其用途，我們也該毫不猶豫的這么做，關鍵不在于函式的長度，而在于函式“做什么”和“如何做”之間的語意距離，

（1）提煉函式

（2）以查詢取代臨時變數

（3）引入引數物件或保持物件完整

（4）以函式物件取代函式

將這個特函式放進一個單獨物件中，如此一來區域變數就變成了了物件內的欄位，然后你可以在同一個物件中將這個大型函式分解成多個小型函式，

本書在不斷強調小型函式的優美動人，

（5）條件運算式和回圈常常也是提煉的信號，

分解條件運算式；

將回圈和其內的代碼提煉到一根獨立函式中，

3、過大的類

如果想利用單個類做太多事情，其內就會出現太多實體變數，一旦如此，重復代碼也就接踵而至了，

可以利用提煉類將幾個變數一起提煉至新類中，

4、過長引數列

5、發散式變化

6、散彈式修改

如果遇到某種變化，都必須在很多不同的類中做一些小修改的時候，你就可以將這些一起變化的代碼提煉到一個新的類中，

7、依戀情節

函式對某個類的興趣高多對自己所處類的興趣，這時就需要轉移函式的位置了，

8、資料泥團

一個好的評判方法是：洗掉眾多資料中的一項時，其它資料有沒有因而失去意義？如果它們不再有意義，這就是一個明確的信號，你就應該產生一個新物件，

減少欄位和引數的個數，當然可以去除一些壞味道，但更重要的是：一旦擁有新物件，就有機會讓程式散發出一種芳香，得到新物件后，你就可以著手尋找依戀情節，這可以幫你指出能夠移至新類中的種種程式行為，不必太久，所有的類都將在它們小小社會中充分發揮價值，

9、基本型別偏執

物件技術的新手通常不愿意在小任務上運用小物件，像結合數值和幣種的money類、電話號碼、郵政編碼等的特殊字串，看似簡單，此時可以運用以物件取代資料值，將原本單獨存在的資料值替換為物件，從而走出傳統的洞窟，進入炙手可熱的物件世界，

10、switch驚悚現身

面向物件程式的一個最明顯特征就是：少用switch陳述句，

從本質上說，switch陳述句的問題在于重復，你常會發現同樣的switch陳述句散布于不同地點，如果要為它添加一個新的case子句，就必須找到所有switch陳述句并修改它們， 面向物件中的多型就可以帶來優雅的解決方法，

11、平行繼承體系

如果你發現一個類增加一個子類，必須也為另一個類相應的增加一個子類，如果你發現某個繼承體系的類名稱前綴和另一個繼承體系名稱前綴完全相同，便是聞到了這種壞味道，

消除這種重復性的一般策略是：讓一個繼承體系的實體參考另一個繼承體系的實體，如果再接再厲運用轉移方法和轉移欄位，就可以將參考端的繼承體系消匿于無形，

12、冗余類

折疊繼承體系；

將類行內化；

13、夸夸其談未來性

14、令人迷惑的暫時欄位

15、多度耦合的訊息鏈

16、中間人

17、曖昧關系

18、異曲同工的類

19、不完美的類別庫

引入外加函式，即對復雜引數的封裝；

引入本地擴展，即繼承類別庫并添加你需要的方法；

20、純稚的資料類

21、被拒絕的饋贈

以委托替代繼承，

22、過多的注釋

當你看到一堆注釋的時候，往往是因為你的代碼很糟糕，需要用注釋去解釋它，所以過多的注釋就預示著你該對代碼進行重構了，

當你感覺需要撰寫注釋時，請先嘗試重構，試著讓所有注釋都變得多余，

第四章 構筑測驗體系

1、自測驗代碼的價值

實際上撰寫測驗代碼的最有用時機是在開始編程之前，當你需要添加特性的時候，先寫相應測驗代碼，

撰寫測驗代碼其實就是在問自己，添加這個功能需要做些什么，撰寫測驗代碼還能使你把注意力集中于介面而非實作，

2、JUnit測驗框架

3、添加更多測驗

• 撰寫未臻完善的測驗并實際運行，好過對完美測驗的無盡等待；
• 考慮可能出錯的邊界條件，把測驗火力集中在那兒；
• 當事情被認為應該會出錯時，別忘了檢查是否拋出了預期的例外；
• 不要因為測驗無法捕捉所有bug就不寫測驗，因為測驗的確可以捕捉到大多數bug；

上一篇：【撰寫高質量代碼：改善Java程式的151個建議】

下一篇：深入理解Java虛擬機