第14章 重構(gòu)工具401 《重構(gòu)》的讀書筆記
學(xué)習(xí)基礎(chǔ)：
熟悉《設(shè)計(jì)模式》的基本概念，熟悉基本的Java語法，熟悉Eclipse和JUnit的使用，有相對較好的英語基礎(chǔ)。
學(xué)習(xí)過程：
- 先看第1章，手工輸入實(shí)例程序，了解重構(gòu)的方法和過程。重點(diǎn)是理解重構(gòu)的思路，最好的理解方式就是通過實(shí)踐的方式理解。
- 再看第2~4章，內(nèi)容為選擇性閱讀，沒興趣或者看不懂的都可以跳過，因?yàn)楹竺孢€可以回頭再讀。
- 接著第5~12章，最好按順序把代碼一個(gè)個(gè)輸入，再按照作者的步驟重構(gòu)操作一次，并結(jié)合自己以往工作中的實(shí)踐來理解。
學(xué)習(xí)目的：
使自己編寫的代碼更容易被人讀懂。
學(xué)習(xí)感悟：
- 代碼的重構(gòu)應(yīng)該是一步步完成的，每次重構(gòu)的部分不要超過自己的理解能力的5%。雖然這樣操作略顯繁瑣，但是可以減輕頭腦重構(gòu)過程中的記憶強(qiáng)度，減少代碼出錯(cuò)的機(jī)會(huì)。
- 代碼的重構(gòu)一定要配合JUnit（TDD，測試驅(qū)動(dòng)開發(fā)）完成，再加上Git（版本管理）和Eclipse（IDE的重構(gòu)工具）那就事半功倍了。
學(xué)習(xí)代碼：
Refactored-MartinFowler
總覽
- 第1章（必讀），從實(shí)例程序出發(fā)，了解重構(gòu)的方法和過程。
- 第2章，討論重構(gòu)的一般性原則、定義和進(jìn)行重構(gòu)的原因。
- 第3章，介紹如何判斷問題代碼，以及如何用重構(gòu)改善它們。
- 第4章，在代碼中構(gòu)建java的測試環(huán)境
- 第5~12章，具體面對的問題和重構(gòu)的方法。
- 第13章，Bill Opdyke在商業(yè)開發(fā)中應(yīng)用重構(gòu)
- 第14章，自動(dòng)化重構(gòu)工具（今天看來，已經(jīng)不是太大問題，Eclipse的Refactor已經(jīng)非常好用）
- 第15章，重構(gòu)的哲學(xué)思想
第1章 重構(gòu)，第一個(gè)案例
1.1 (P1)起點(diǎn)
因?yàn)榇a的結(jié)構(gòu)無法滿足添加新功能的需要，因此先進(jìn)行重構(gòu)，使代碼方便添加新功能，然后再添加新功能。
1.2 (P7)重構(gòu)的第一步
首先確認(rèn)自己擁有一套可靠的測試機(jī)制，因?yàn)橹貥?gòu)有可能引入問題，通過測試保證重構(gòu)沒有改變程序功能。
第2章 重構(gòu)原則
2.1 (P53)何謂重構(gòu)
重構(gòu)（名詞）：對軟件內(nèi)部結(jié)構(gòu)的一種調(diào)整，目的是在不改變軟件可觀察行為的前提下，提高理解性和降低修改成本。
重構(gòu)（動(dòng)詞）：使用一系列重構(gòu)手法，在不改變軟件可觀察行為的前提下，調(diào)整其結(jié)構(gòu)。
定義的擴(kuò)展：
- 重構(gòu)讓軟件更容易理解和修改
- 重構(gòu)不會(huì)改變軟件的可觀察行為，即使改變也只能是微小的影響，軟件功能一如既往。
重構(gòu)的目標(biāo)：只改變程序內(nèi)部結(jié)構(gòu)，不添加新的功能
不要一心二用：
- 添加新功能的時(shí)候，不重構(gòu)已有代碼。
- 重構(gòu)代碼時(shí)，不增加新功能。
2.2 (P55)為何重構(gòu)
- 重構(gòu)改進(jìn)軟件設(shè)計(jì)：
- 程序的設(shè)計(jì)質(zhì)量在沒有持續(xù)重構(gòu)的情況下逐漸變差，功能的增加或者修改都可能使代碼越來越難以理解和維護(hù)，就越難保證最初的設(shè)計(jì)目標(biāo)
- 消除重復(fù)的代碼一方面是程序運(yùn)行更快，一方面是方便未來的修改，例如：重構(gòu)減少代碼重復(fù)，避免功能的改變需要修改多處代碼。
- 重構(gòu)使軟件更容易理解：
- 及時(shí)填補(bǔ)“想要它做什么”和“告訴它做什么”之間的縫隙。重構(gòu)的核心就是要“準(zhǔn)確說出我所要的”
- 重新閱讀代碼的人有可能是自己，也可能是他人。
- 通過重構(gòu)可以把自己不熟悉的代碼的用途梳理一遍，加深對代碼的理解
- 重構(gòu)幫助找出bug：
- 重構(gòu)提高編程速度：
- 重構(gòu)達(dá)到良好的設(shè)計(jì)，而良好的設(shè)計(jì)更容易修改代碼、增加功能、問題調(diào)試。
2.3 (P57)何時(shí)重構(gòu)
重構(gòu)的三次法則：
- 第一次開發(fā)某個(gè)功能的時(shí)候以實(shí)現(xiàn)為目標(biāo)。
- 第二次開發(fā)相同功能的時(shí)候，克制自己的反感，繼續(xù)重復(fù)實(shí)現(xiàn)。
- 第三次開發(fā)相同功能的時(shí)候，應(yīng)該重構(gòu)。
重構(gòu)的時(shí)間點(diǎn)：
- 添加功能時(shí)重構(gòu)：
- 一方面可以幫助理解需要修改的代碼
- 一方面是使現(xiàn)在以及未來增加新功能更加容易。
- 修補(bǔ)錯(cuò)誤時(shí)重構(gòu)：
- 出現(xiàn)bug的時(shí)候，難以找出問題所在的時(shí)候，很有可能是代碼不清晰導(dǎo)致查找bug的困難。
- 復(fù)審代碼時(shí)重構(gòu)：
- 復(fù)審代碼有助于知識的傳播，有利于代碼被編寫者之外的人理解。
- 重構(gòu)加深了對代碼的理解，有利于提升復(fù)審代碼的能力
復(fù)審團(tuán)隊(duì)：只要代碼作者和一個(gè)審查者者。較大的項(xiàng)目可以通過UML圖去展示代碼的邏輯。
程序難以修改的原因：
- 難以閱讀的程序
- 邏輯重復(fù)的程序
- 添加新特性需要修改已有代碼的程序
- 帶復(fù)雜邏輯判斷的程序
重構(gòu)的目標(biāo)：
- 代碼容易閱讀
- 所有邏輯都只有唯一地點(diǎn)指定
- 新的改動(dòng)不會(huì)危及現(xiàn)有行為
- 盡可能簡單表達(dá)邏輯
2.4 (P60)怎么對經(jīng)理說
- 懂技術(shù)的經(jīng)理，很容易溝通；
- 追求質(zhì)量的經(jīng)理，介紹重構(gòu)對質(zhì)量的幫助；
- 追求進(jìn)度的經(jīng)理，則自己安靜地重構(gòu)。因?yàn)橹貥?gòu)可以最快的完成任務(wù)，就是對經(jīng)理最大的幫助。
間接訪問
很多時(shí)候重構(gòu)都為程序引入間接訪問：
- 把大型對象拆分成小對象
- 把大型函數(shù)拆分為小型函數(shù)。
間接訪問的價(jià)值：
- 允許邏輯共享：一個(gè)函數(shù)在不同地點(diǎn)被調(diào)用。子類共享超類的方法。
- 分開解釋意圖和實(shí)現(xiàn)：通過類名和函數(shù)名解釋自己的意圖
- 隔離變化：在不同地方使用同一個(gè)對象，需要修改一處邏輯，那么可以做出子類，并在需要的時(shí)候修改這個(gè)子類。
- 封裝條件邏輯：運(yùn)用多態(tài)。將條件邏輯轉(zhuǎn)化為消息模式。
減少間接層的條件:當(dāng)間接層只在一處使用，那么需要將其消除。
2.5 (P62)重構(gòu)的難題
數(shù)據(jù)庫重構(gòu)：
- 存在問題：
- 程序與數(shù)據(jù)庫耦合在一起。
- 數(shù)據(jù)遷移。
- 解決方案：
- 在非關(guān)系型數(shù)據(jù)庫，可以在數(shù)據(jù)庫和對象模型中插入一個(gè)分離層，隔離兩者之間的變化
接口重構(gòu)
- 對于已經(jīng)發(fā)布的接口需要可能需要維護(hù)舊接口和新接口，用deprecated修飾舊接口。
- 不發(fā)布新接口，在舊接口中調(diào)用新接口。
- 假如新接口拋出編譯時(shí)異常，那么可以在舊接口中調(diào)用新接口并將編譯時(shí)異常轉(zhuǎn)化為運(yùn)行時(shí)異常。
不重構(gòu)的條件：
- 重構(gòu)之前，代碼在大部分情況下都能夠正常運(yùn)行，就可以重構(gòu)，否則應(yīng)該是重寫。
- 到了Deadline，應(yīng)該避免重構(gòu)。
2.6 (P66)重構(gòu)與設(shè)計(jì)
重構(gòu)與設(shè)計(jì)是彼此互補(bǔ)的：
- 設(shè)計(jì)應(yīng)該在編碼之前，但是設(shè)計(jì)總有缺陷，隨著對問題認(rèn)識的逐漸深入，通過重構(gòu)可以改善設(shè)計(jì)的質(zhì)量。
- 重構(gòu)減輕了設(shè)計(jì)的難度和壓力，在程序不斷修改的過程中逐步完善程序的設(shè)計(jì)。
2.7 (P69)重構(gòu)與性能
重構(gòu)是有可能導(dǎo)致程序運(yùn)行變慢的，但是不需要在設(shè)計(jì)和編碼時(shí)就考慮性能問題。例如：實(shí)時(shí)程序的編寫：
- 首先寫出可調(diào)的程序
- 然后調(diào)整它以達(dá)到性能的要求。
- 經(jīng)過分析大部分程序的主要時(shí)間是消耗在小部分代碼上，所以不用對所有代碼進(jìn)行優(yōu)化。
- 性能優(yōu)化放在開發(fā)的后期，利用分析工具找出消耗大量時(shí)間的代碼，然后集中優(yōu)化。
第3章 代碼的壞味道
3.1 (P76)Duplicated Code（重復(fù)代碼）
- 同個(gè)類兩個(gè)函數(shù)存在相同表達(dá)式：Extract Method（提煉函數(shù)）
- 互為兄弟類內(nèi)存在相同表達(dá)式：
- Extract Method→PullUp Method（函數(shù)上移）
- 如果代碼只是相似：先運(yùn)用Extract Method（提煉函數(shù)）分開再Form TemPlate Method（塑造模板函數(shù)）
- 兩個(gè)毫不相干的類存在重復(fù)代碼：Extract Class（提煉類）
3.2 (P76)Long Method（過長函數(shù)）
原則：盡量利用函數(shù)名稱來解釋用途，而不是注釋。
關(guān)鍵：代碼主要用來描述“做什么”，而不是描述“怎么做”。例如：getAge()表達(dá)獲取年齡，而today-birthday就增加了理解的間接性，雖然看代碼的人也能明白含義，但是就需要多想一下，并且birthday有可能表達(dá)的不是某個(gè)人的出生日期呢，而是某個(gè)買回來的產(chǎn)品的呢？那可能表達(dá)的就是使用時(shí)長了。
具體情況：
- 函數(shù)有大量參數(shù)和臨時(shí)變量：Extract Method（提煉函數(shù)）
- 用Replace Temp with Query（以查詢?nèi)〈R時(shí)變量）消除臨時(shí)變量
- 用Introduce Parameter Object（引入?yún)?shù)對象）或者Preserve Whole Object（保持對象完整）來將多長的參數(shù)列表變得簡潔一點(diǎn)。
- 如果按照上述步驟還存在太多變量和參數(shù)就需要用到Replace Method with Method Object（以函數(shù)對象取代函數(shù)）
- 條件表達(dá)式可以用Decompose Conditional（分解條件表達(dá)式）解決
- 可以將循環(huán)內(nèi)的代碼提煉為函數(shù)。
3.3 (P78)Large Class（過大的類）
有時(shí)候類并非在所有時(shí)刻都使用實(shí)例變量：使用Extract Method和Extract Subclass（提煉子類）
類中有太多代碼：
- Extract Class（提煉類）
- Extract Subclass（提煉子類）
- Extract Interface（提供接口）分解類的行為。存在GUI的時(shí)候，可以Duplicate Observed Data（復(fù)制“被監(jiān)視數(shù)據(jù)”），分離數(shù)據(jù)和行為到業(yè)務(wù)模型中去。
3.4 (P78)Long Parameter List（過長參數(shù)列）
- 如果可以調(diào)用已有對象獲取的話可以使用Replace Parameter with Methods（以函數(shù)取代參數(shù)）
- 將來自同一對象的數(shù)據(jù)收集起來，以該對象替代：Preserve Whole Object（保持對象完整）
- 如果幾個(gè)參數(shù)總是同時(shí)出現(xiàn)，那么可以考慮Introduce Parameter Object（引入?yún)?shù)對象）
3.5 (P79)Divergent Change（發(fā)散式變化）
不同的變化影響著相同的類發(fā)生改變，即變化的認(rèn)知有分歧（Divergent）。通過Extract Class把不同的功能封裝到不同的類中，使每個(gè)類只因一種變化而需要修改
3.6 (P80)Shotgun Surgery（霰彈式修改）
相同的變化會(huì)涉及到多個(gè)類發(fā)生修改，類似霰彈槍射擊的效果。
可以通過Extract Method，Move Method，Inline Class把一種變化產(chǎn)生的多個(gè)修改移到同一個(gè)類中。
對比：
- Divergent Change（發(fā)散式變化）是一個(gè)類受到的多個(gè)變化影響；
- Shotgun Surgery（霰彈式修改）是一個(gè)變化引起多個(gè)類需要修改。
3.7 (P80)Feature Envy（依戀情結(jié)）
類中的某個(gè)函數(shù)對其他類的依賴度過高，則應(yīng)該通過Move Method（移動(dòng)函數(shù)）將它搬移到合適的類中。
3.8 (P81)Data Clumps（數(shù)據(jù)泥團(tuán)）
數(shù)據(jù)項(xiàng)總是成群結(jié)隊(duì)出現(xiàn)，通過Extract Class將它們提煉到一個(gè)獨(dú)立對象中，從而縮短參數(shù)列表，簡化函數(shù)調(diào)用。
判斷數(shù)據(jù)項(xiàng)是否相關(guān)的方法：如果這些數(shù)據(jù)項(xiàng)不在一起時(shí)就失去了明確的含義，那么就可以把它們提煉成一個(gè)新的對象。
3.9 (P81)Primitive Obsession（基本類型偏執(zhí)）
- 有些字段可以用對象表示更準(zhǔn)確Replace Data Value with Object（以對象取代數(shù)據(jù)值）
- 對于不影響行為的類型碼可以Replace Type Code with Class（以類取代類型碼）
- 影響行為的類型碼可以Replace Type Code with Subclasses（以子類取代類型碼），類型碼在運(yùn)行時(shí)會(huì)變化就用Replace Type Code with State/Strategy（以State/Strategy取代類型碼）
3.10 (P82)Switch Statements（switch驚悚現(xiàn)身）
- 使用Replace Type Code with Subclasses（以子類取代類型碼）或者Replace Type Code with State/Strategy（以State/Strategy取代類型碼）
- 輕量級的解決方法：Replace Parameter with Explicit Methods（以明確函數(shù)取代參數(shù)）
3.11 (P83)Parallel Inheritance Hierarchies（平行繼承體系）
每當(dāng)為一個(gè)類增加子類必須也為另外一個(gè)類增加一個(gè)子類，那么就讓一個(gè)繼承體系的實(shí)例引用另一個(gè)繼承體系的實(shí)例。
3.12 (P83)Lazy Class（冗贅類）
沒用的類，使用Inline Class（內(nèi)聯(lián)類）或者Collapse Hierarchy（折疊繼承體系）來解決
3.13 (P83)Speculative Generality（夸夸其談未來性）
- 為未來設(shè)計(jì)的類，使用Inline Class（內(nèi)聯(lián)類）或者Collapse Hierarchy（折疊繼承體系）來解決
- 為未來設(shè)計(jì)的函數(shù)參數(shù)，使用Remove Parameter（移除參數(shù)）
- 函數(shù)名稱啰嗦，使用Rename Method（函數(shù)改名）
3.14 (P84)Temporary Field（令人迷惑的暫時(shí)字段）
對象中某個(gè)字段僅為特定情況而設(shè)。使用Extract Class（提煉類）將這個(gè)字段提取出來
3.15 (P84)Message Chains（過度耦合的消息鏈）
消息鏈：用戶通過一個(gè)對象獲取另一個(gè)對象，再通過獲取的對象請求另一個(gè)對象，如此操作就是消息鏈。采取這種方式意味著客戶代碼將與查找過程中的導(dǎo)航結(jié)構(gòu)緊密耦合，可以使用Hide Delegate（隱藏“委托關(guān)系”）進(jìn)行重構(gòu)。但是謹(jǐn)慎處理！
3.16 (P85)Middle Man（中間人）
過度委托形成中間人:Remove Middle Man（移除中間人）
如果中間人還有其他行為,Replace Delegation with Inherited（以繼承取代委托）
3.17 (P85)Inappropriate Intimacy（狎昵關(guān)系）
- 兩個(gè)類相互依賴過多，花費(fèi)大量時(shí)間去獲取對方的private成員內(nèi)容，使用Move Field（移動(dòng)字段）和Move Method（移動(dòng)方法）減少耦合性，或用Change Bidirectional Association to Unidirectional（將雙向關(guān)聯(lián)改為單向關(guān)聯(lián)）
- 如果兩個(gè)類無法移動(dòng)相同數(shù)據(jù)和函數(shù)，可以使用Extract Class（提煉類）,讓他們使用新類進(jìn)行交互。
3.18 (P85)Alternative Classes with Different Interfaces（異曲同工的類）
兩個(gè)函數(shù)做了相同的事情卻有不同的函數(shù)名稱
3.19 (P86)Incomplete Library Class（不完美的庫類）
庫函數(shù)功能不足，需要增加一些自定義的功能：
- 需要加入少量操作，使用Introduce Foreign Method（引入外加函數(shù)）
- 需要加入大量操作，使用Introduce Local Extension（引入本地?cái)U(kuò)展）
3.20 (P86)Data Class（幼稚的數(shù)據(jù)類）
幼稚的數(shù)據(jù)類：只有數(shù)據(jù)沒有行為的類，其他類需要對該類的數(shù)據(jù)進(jìn)行取值設(shè)值操作
- 使用Encapsulate Field（封裝字段）和Encapsulate Collection（封裝集合）對字段進(jìn)行合理地封裝
- 對于不該被其他類修改的字段:Remove Setting Method（移除設(shè)值函數(shù)）
3.21 (P87)Refused Bequest（被拒絕的遺贈(zèng)）
如果子類不愿意接受超類的所有定義，應(yīng)該使用Replace inherited with Delegation（以委托取代繼承）來處理子類
使用Extract Method（提煉方法）來解決注釋過多問題，注釋更多應(yīng)該說明的是“怎么做”，而不是“做什么”，例如：對一個(gè)排序函數(shù)說明其采用二分法排序，而不是說明它是個(gè)排序函數(shù)，因?yàn)檫@個(gè)說明在函數(shù)名稱中已經(jīng)具備。
第4章 構(gòu)筑測試體系
4.1 自測試代碼的價(jià)值89
- 確保所有測試都完全自動(dòng)化，讓它們檢查自己的測試結(jié)果；
- 一套測試就是一個(gè)強(qiáng)大的bug探測器，能夠大大縮減查找bug所需要花費(fèi)的時(shí)間。
- 因?yàn)榇a剛剛寫完，測試出現(xiàn)問題后，心里很清楚自己修改或者添加了哪些東西，可能會(huì)在哪里出現(xiàn)了問題。
4.2 JUnit測試框架91
- 頻繁地運(yùn)行測試；
- 每次編譯前都進(jìn)行一次測試；
- 每天至少執(zhí)行一次所有的測試。
4.3 添加更多測試97
- 編寫一個(gè)測試并運(yùn)行起來，好過將所有的測試編好了一起運(yùn)行。
- 測試特別需要注意可能出錯(cuò)的邊界條件；
- 對于可能出錯(cuò)的地方，還需要檢查是否拋出了預(yù)期的異常；
- 測試不能解決所有bug，但是可以大大減少bug的數(shù)量。
第12章 大型重構(gòu)359
大型重構(gòu)是程序開發(fā)必將遇到的，只是不知道在什么時(shí)間，用什么樣的方式經(jīng)歷。例如：隨著時(shí)間的推移，河道必定會(huì)被水草和垃圾所堵塞，你可以固定時(shí)間清淤，也可以放任自流直到崩潰。崩潰后依然會(huì)面臨總結(jié)經(jīng)驗(yàn)教訓(xùn)，再次重構(gòu)系統(tǒng)。
大型重構(gòu)很難給出具體的操作案例，因?yàn)槊總€(gè)大型案例相對于自身來說都是惟一的，是無法復(fù)制和重現(xiàn)的。可以復(fù)制與重現(xiàn)的都是這些大型重構(gòu)中蘊(yùn)含的具體的細(xì)節(jié)，因此這章主要講的是思想和理念上的內(nèi)容。
四個(gè)大型重構(gòu)：
- Tease Apart Inheritance（362）用于處理混亂的繼承體系
- 某個(gè)繼承體系同時(shí)承擔(dān)兩項(xiàng)責(zé)任
- 建立兩個(gè)繼承體系，其中一個(gè)通過委托調(diào)用另一個(gè)
- Convert Procedural Design to Objects（368）如何重構(gòu)過時(shí)的編碼技術(shù)遺留下來的程序
- 傳統(tǒng)過程化風(fēng)格的代碼
- 將數(shù)據(jù)記錄變成對象，將大塊的行為分成小塊，再將它們移入到相關(guān)對象中
- Separate Domain from Presentation（370）將業(yè)務(wù)邏輯與用戶界面分隔開來
- 用戶界面類中包含了業(yè)務(wù)邏輯
- 將業(yè)務(wù)邏輯剝離到業(yè)務(wù)類中，參考：MVC模式
- Extract Hierarchy（375）將復(fù)雜的類轉(zhuǎn)化為一群簡單的子類，從而簡化系統(tǒng)。
- 某個(gè)類做了太多工作
- 某個(gè)類的部分工作是由大量的條件表達(dá)式完成的
- 建立繼承體系，使用子類表示每一種特殊情況
第13章 重構(gòu)，復(fù)用與現(xiàn)實(shí)379
作為一個(gè)博士寫的內(nèi)容，仍然具有學(xué)術(shù)性較強(qiáng)的風(fēng)格，可以當(dāng)作歷史資料了解一下重構(gòu)的發(fā)展過程，也可以對重構(gòu)的思想有更多理論上的認(rèn)識。
安全重構(gòu)（391）
安全重構(gòu)的四條籬笆：
- 相信你自己的編碼能力；
- 相信你的編譯器能捕捉你遺漏的錯(cuò)誤；
- 相信你的測試套件能捕捉你和編譯器都遺漏的錯(cuò)誤；
- 相信代碼復(fù)審能捕捉你、編譯器和測試套件都遺漏的錯(cuò)誤。注：沒有100%安全的重構(gòu)，但是可以通過以上的條件滿足你對安全性的最低要求。
重構(gòu)工具
- Eclipse（或其他IDE）自帶的重構(gòu)工具：Refactor；
- Java（或其他編譯器）自帶的分析工具：lint；
- JUnit等自動(dòng)化的測試工具。
第14章 重構(gòu)工具401
相對于10多年前寫的內(nèi)容，現(xiàn)在許多IDE都已經(jīng)提供了對大部分重構(gòu)功能的支持。但是了解重構(gòu)的基本理念，對于正確地使用重構(gòu)工具會(huì)有很大的幫助。因?yàn)槌晒Φ闹貥?gòu)不依賴于工具，而決定于人，當(dāng)人做出了正確的決定，合理地使用重構(gòu)工具輔助自己，才能保證重構(gòu)的完成。