修改代碼的藝術（簡體書）

理解修改軟件的機制：添加特性、修正缺陷、改進設計、優化性能把遺留代碼放到測試用具之中編寫測試，防止引入新的問題包含Java、C++、C和C#的示例，其中介紹的大多數技術適用于其他任何語言或平臺，精確地確定要在哪些地方修改代碼處理非面向對象的遺留代碼處理看起來沒有任何結構的應用程序。

Michael C. Feathers，世界級軟件開發大師，就職于Object Mentor公司（這是一家世界領先的提供軟件領域的指導、技能開發、知識傳播和領導力服務的公司）。他是ACM和IEEE成員，也是CppUnit（從JUnit移植到C++上的單元測試框架）和FitCpp（FIT集成測試框架在C++上的實現）的最初作者，曾3次擔任OOPSLA會議的CodeFest主席。目前他在世界范圍內提供測試驅動開發、重構、面向對象設計、Java、C#、C++以及極限編程方面的培訓和指導。

侯伯薇，中荷人壽保險有限公司高級系統分析師，InfoQ中文站翻譯團隊主編，擁有十多年開發經驗，目前致力于技術與業務的融合，讓開發出來的程序能夠真正提高業務人員的工作效率。熱衷于通過翻譯和演講的方式與廣大程序員分享和交流，曾翻譯過多本技術書籍和幾百篇技術短文，并在Scrumgathering、QClub、敏捷之旅等活動上做過技術演講。

世界級計算機專家Michael C. Feathers的經典之作，軟件開發大師Robert C. Martin作序傾情推薦，修改遺留代碼的權威指南。
深入剖析修改遺留代碼的各種方法和策略，從理解遺留代碼、為其編碼測試、重構及增加特性等方面給出大量實用建議，是所有程序開發人員必讀之作。

譯者序
序
前言
第一部分　修改機制
第1章　修改軟件 2
1.1　修改軟件的四大原因 2
1.1.1　增加特性和修正缺陷 2
1.1.2　改善設計 4
1.1.3　優化 4
1.2　組合在一起 4
第2章　利用反饋 7
2.1　什么是單元測試 9
2.2　高層次測試 11
2.3　測試覆蓋 11
2.4　遺留代碼修改方法 14
2.4.1　確定變更點 14
2.4.2　找到測試點 14
2.4.3　打破依賴關系 14
2.4.4　編寫測試 15
2.4.5　做出修改并重構 15
2.5　本書其他部分 15
第3章　感知和分離 16
3.1　偽協作程序 17
3.1.1　偽對象 17
3.1.2　偽對象的兩面 20
3.1.3　偽對象總結 20
3.1.4　模擬對象 21
第4章　接縫模型 22
4.1　大片的文本 22
4.2　接縫 23
4.3　接縫類型 25
4.3.1　預處理接縫 26
4.3.2　鏈接接縫 28
4.3.3　對象接縫 31
第5章　工具 36
5.1　自動化重構工具 36
5.2　模擬對象 38
5.3　單元測試用具 38
5.3.1　JUnit 39
5.3.2　CppUnitLite 40
5.3.3　NUnit 41
5.3.4　其他xUnit框架 42
5.4　一般測試用具 42
5.4.1　集成測試框架（Framework for Integrated Test，FIT） 42
5.4.2　Fitnesse 43

第二部分　修改軟件
第6章　時間很緊張，但還需要修改 46
6.1　新生方法（Sprout Method） 48
6.2　新生類（Sprout Class） 50
6.3　包裝方法 54
6.4　包裝類 57
6.5　小結 61
第7章　永遠都無法完成的修改 62
7.1　理解 62
7.2　延遲時間 63
7.3　打破依賴關系 63
7.4　構建依賴關系 64
7.5　小結 67
第8章　如何添加新特性 68
8.1　測試驅動開發 68
8.1.1　編寫失敗的測試案例 69
8.1.2　對其進行編譯 69
8.1.3　使其通過 69
8.1.4　去除重復的內容 70
8.1.5　編寫失敗的測試案例 70
8.1.6　對其進行編譯 70
8.1.7　使其通過 71
8.1.8　去除重復的內容 71
8.1.9　編寫失敗的測試案例 71
8.1.10　對其進行編譯 71
8.1.11　使其通過 72
8.1.12　去除重復的內容 73
8.2　根據差異編程 74
8.3　小結 81
第9章　無法把類放到測試用具中 82
9.1　惱人的參數 82
9.2　具有隱藏依賴的情況 88
9.3　構造Blob的情況 90
9.4　惱人的全局依賴 92
9.5　可怕的Include依賴 99
9.6　洋蔥皮參數 102
9.7　別名參數 104
第10章　無法在測試用具中運行方法 107
10.1　隱藏方法的情況 107
10.2　“有幫助的”語言特性 110
10.3　檢測不到的副作用 112
第11章　我需要修改代碼，應該測試哪些方法 119
11.1　推斷影響 119
11.2　正向推理 124
11.3　影響傳播 128
11.4　推理影響的工具 129
11.5　從影響分析中學習 131
11.6　簡化影響草圖 132
第12章　我需要在一個地方做多處變更，需要為所有涉及的類打破依賴關系嗎 134
12.1　攔截點 135
12.1.1　簡單的情況 135
12.1.2　更高層次的攔截點 137
12.2　使用夾點來判斷設計 140
12.3　夾點陷阱 141
第13章　我需要修改代碼，但不知道要編寫哪些測試 142
13.1　鑒定測試 142
13.2　鑒定類 145
13.3　定向測試（Targeted Testing） 146
13.4　編寫鑒定測試的啟示 150
第14章　對庫的依賴讓我快要崩潰了 151
第15章　應用全是API調用 153
第16章　對代碼理解不夠，所以無法修改 160
16.1　做筆記，畫草圖 160
16.2　列表標記 161
16.2.1　分離職責 162
16.2.2　理解方法結構 162
16.2.3　提取方法 162
16.2.4　理解變更的影響 162
16.3　臨時重構 162
16.4　刪除沒有用的代碼 163
第17章　應用沒有結構 164
17.1　講述系統的故事 165
17.2　裸CRC 167
17.3　對話審查（Conversation Scrutiny） 170
第18章　測試代碼擋路了 171
18.1　類命名規范 171
18.2　測試位置 172
第19章　項目并非面向對象，如何才能夠安全地修改 174
19.1　簡單的案例 174
19.2　困難的案例 175
19.3　增加新行為 178
19.4　充分利用面向對象 180
19.5　完全面向對象 183
第20章　類太大了，我不想讓它繼續膨脹 186
20.1　查看職責 188
20.2　其他技術 199
20.3　繼續前進 199
20.3.1　策略 199
20.3.2　戰術 200
20.4　提取類之后 201
第21章　在各個地方修改的都是同樣的代碼 202
第22章　我需要修改一個巨獸方法，但無法為其編寫測試 218
22.1　巨獸的種類 218
22.1.1　無序方法 218
22.1.2　纏結的方法 219
22.2　使用自動重構支持來對付巨獸 221
22.3　手動重構挑戰 224
22.3.1　引入檢測變量 224
22.3.2　提取你所知道的內容 227
22.3.3　收集依賴 228
22.3.4　打破方法對象 229
22.4　策略 229
22.4.1　記下方法的概要 230
22.4.2　找到序列 230
22.4.3　首先提取到當前類 231
22.4.4　提取小段代碼 231
22.4.5　準備好重做提取 231
第23章　如何知道沒有造成任何破壞 232
23.1　超感編輯（Hyperaware Editing） 232
23.2　單一目標編輯 233
23.3　保留簽名 234
23.4　依賴于編譯器 236
23.5　結對編程 238
第24章　我要崩潰了，它不會再有任何改進 239

第三部分　打破依賴的技術
第25章　打破依賴的技術 242
25.1　調整參數 242
25.2　分解方法對象 245
25.3　完善定義 251
25.4　封裝全局引用 252
25.5　暴露靜態方法 257
25.6　提取并重寫調用 259
25.7　提取并重寫工廠方法 261
25.8　提取并重寫getter方法 262
25.9　提取實現器 265
25.10　提取接口 269
25.11　引入實例委托器 274
25.12　引入靜態設置器 275
25.13　鏈接替換 280
25.14　參數化構造函數 280
25.15　參數化方法 284
25.16　原始化參數（Primitivize Parameter） 285
25.17　上推特性 287
25.18　下推依賴 290
25.19　使用函數指針替換函數 293
25.20　使用getter方法替換全局引用 295
25.21　創建子類并重寫方法 297
25.22　替代實例變量 299
25.23　模板重定義 302
25.24　文本重定義 305
附錄　重構 307
術語表 311

第一部分
修 改 機 制
第1章
修 改 軟 件
修改代碼是件很不錯的事情。那可是我們賴以養家糊口的工作。但是，有些修改代碼的方式會讓我們的生活更悲催，而有些方式則會讓我們的生活輕松寫意。業界并沒有針對這個問題的太多討論，我們手頭最便于參考的是重構方面的文獻。我覺得可以將這個討論再拓寬一些，談一下如何處理最棘手的代碼。在此之前，我們需要深入理解一下修改的機制。
1.1　修改軟件的四大原因
為簡單起見，讓我們看一下修改軟件的四種主要原因。
1. 增加特性
2. 修正缺陷
3. 改善設計
4. 優化對資源的利用
1.1.1　增加特性和修正缺陷
增加特性看起來是最簡單的修改類型。軟件表現為一種情況，而用戶說系統還需要能夠完成更多工作，所以要增加特性，就這么簡單。
假設我們正在使用一種基于Web的應用程序，經理告訴我們，她想要把公司的標識從頁面的左端移動到右端。我們和她討論了一下，發現那并非易事。她不但想要移動標識，還想要做出其他修改。她希望下次發布的時候能夠完成。這是修正缺陷還是增加新特性呢？這取決于你看問題的角度。從客戶的角度來看，她肯定是在讓我們修正問題。她可能就是瀏覽了網站，然后和部門的同事一起開了個會，就決定要改變標識的位置，并要求再加一點兒功能。從開發者的角度來看，這個變更完全可以看做是增加新特性。“如果他們不總是改變主意，我們現在早就完成了。”但是，在某些組織中，移動標識被看做是修正缺陷，盡管團隊需要做大量嶄新的工作。
你可能會說這太主觀。你認為是修正缺陷，我認為是增加特性，就是那樣。但是，很悲催的是，在很多組織中，由于合同和對質量的發言權所限，缺陷的修正和特性的增加需要分別跟蹤，區別對待。在人的層面上，我們可以爭論到底是增加特性還是修正缺陷，但兩者都只是修改代碼和其他制品。不幸的是，關于修正缺陷和新增特性的討論掩蓋了在技術上對我們更重要的一些內容：行為的變更。增加新行為和改變舊行為之間有非常大的區別。
行為對軟件來說至關重要。它是用戶所依賴的內容。當我們增加行為的時候，用戶會很喜歡（前提是他們真的需要），但是如果我們改變或者刪除他們所依賴的特性（引入缺陷），他們就會對我們失去信任。
在上面公司標識的例子中，我們增加行為了嗎？是的。在變更之后，系統會在頁面的右側顯示標識。我們去掉什么行為了嗎？是的，在左側不再會有標識。
讓我們來看一種更復雜的情況。假設一位客戶想要在頁面的右側添加標識，但之前左邊也不存在標識。那么我們肯定要增加行為，但是我們會刪除某種行為嗎？在將要顯示標識的位置已經有什么內容了嗎？
我們是在改變行為，增加行為，還是二者兼而有之呢？
作為程序員，我們可以從實用的角度對二者進行區分。如果我們需要修改代碼（HTML之類的也算作代碼），我們就是在改變行為；如果我們只是增加代碼并調用它，那么我們通常就是在增加行為。讓我們看下另一個例子。以下是Java類中的一個方法：
這個類有一個方法，可以讓我們增加音軌列表項。讓我們增加另一個方法，用來替換音軌列表項。
當我們增加這個方法的時候，我們是為應用程序增加了新的行為，還是改變了它的行為呢？答案是：都不是。增加一個方法并不會改變行為，除非在某處調用了這個方法。
讓我們再來做一次代碼變更。讓我們為CD播放器在用戶界面上放置一個新的按鈕，并將它與replaceTrackListing方法綁定。在這個動作中，我們添加了在replaceTrackListing方法中指定的行為，而且還巧妙地改變了行為。用戶界面上有了新的按鈕，顯示會有所不同。用戶界面的顯示還可能要比之前慢一微秒。看起來，增加行為而不改變它，幾乎是不可能的。
……