修改軟件的藝術 : 構建易維護代碼的 9條最佳實踐 (Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software)

作者:[美]戴維斯科特伯恩斯坦（David Scott Bernstein）譯者:李滿慶
David Scott Bernstein敏捷教練，曾為IBM、微軟、Yahoo等企業提供敏捷實踐指導。他的公司To Be Agile （tobeagile.com）指導團隊進行測試先行、結對編程以及重構等極限編程實踐。

第一部分遺留代碼危機

第1章有些事情不對勁2 

1.1什麼是遺留代碼3 
1.2順流直下4 
1.3孤注一擲6 
1.4為什麼瀑布模型不管用7 
1.4.1食譜與配方7 
1.4.2開發和測試分離8 
1.5當“流程”變成“體力勞動” 8 
1.6堅如磐石的管理9 
1.7此處有龍10 
1.8評估未知11 
1.9一個充滿外行人的產業12 
1.10回顧13 

第2章逃出混亂14 

2.1混亂報告14 
2.1 .1成功的15 
2.1.2遇到困難的15 
2.1.3失敗的（有缺陷的） 15 
2.2駁斥斯坦迪什諮詢集團16 
2.3項目為何會失敗17 
2.4失敗的代價21 
2.4.1這裡十幾億，那裡十幾億21 
2.4.2不同的研究，同樣的危機22 
2.5總結23 

第3章聰明人，新想法25 

3.1走進敏捷25 
3.2小即是好26 
3.3實現敏捷27 
3.4藝術與技能的平衡28 
3.5敏捷跨越鴻溝29
3.6追求技術卓越30 
3.7總結31 

第二部分延續軟件生命（和價值）的9種實踐方法

第4章9個實踐34 

4.1專家知道什麼35 
4.2守-破-離36 
4.3首要原則37 
4.4關於原則38 
4.5關於實踐38 
4.6原則指導實踐39 
4.7未雨綢繆還是隨機應變40 
4.8定義軟件中的“好” 40 
4.9為什麼是9個實踐42 
4.10總結43 

第5章實踐1：在問如何做之前先問做什麼、為什麼做、給誰做44 

5.1不要說如何44 
5.2將“如何”變為“什麼” 45 
5.3要有一個產品負責人46 
5.4故事描述了做什麼、為什麼做、給誰做48 
5.5為驗收測試設立明確標準50 
5.6自動化驗收標準50 
5.7讓我們付諸實踐51 
5.7.1產品負責人的7個策略51 
5.7.2編寫出更好用戶故事的7個策略52 
5.8總結53 

第6章實踐2：小批次構建55 

6.1更小的謊言56 
6.2學會變通56 
6.3控制發布節奏58 
6.4越小越好59
6.5分而治之60 
6.6更短的反饋迴路62 
6.7提高構建速度63 
6.8對反饋做出響應64 
6.9建立待辦列表65 
6.10把用戶故事拆分為任務66 
6.11跳出時間盒子思考66 
6.12範圍控制67 
6.13讓我們付諸實踐69 
6.13.1度量軟件開發的7個策略69 
6.13.2分割用戶故事的7個策略70 
6.14總結71 

第7章實踐3：持續集成72 

7.1建立項目的心跳73 
7.2理解完成、完整完成和完美完成的區別73 
7.3實踐持續部署74 
7.4自動化構建75 
7.5儘早集成，頻繁集成76 
7.6邁出第一步76 
7.7付諸實踐77 
7.7.1構建敏捷設施的7個策略77 
7.7.2消除風險的7個策略79 
7.8總結80 

第8章實踐4：協作81 

8.1極限編程82 
8.2溝通與協作83 
8.3結對編程84 
8.3.1結對的好處85 
8.3.2如何結對編程86 
8.3.3和誰結對87 
8.4夥伴編程88
8.5穿刺，群戰，圍攻89 
8.5.1穿刺89 
8.5.2群戰89 
8.5.3圍攻89 
8.6在時間盒子中對未知進行調研90 
8.7定期代碼審查和回顧會議91 
8.8加強學習和知識分享92 
8.9誨人不倦且不恥下問92 
8.10讓我們付諸實踐93 
8.10.1結對編程的7個策略93 
8.10.2高效回顧會議的7個策略94 
8.11總結95 

第9章實踐5：編寫整潔的代碼97 

9.1高質量的代碼是內聚的98 
9.2高質量的代碼是鬆散耦合的99 
9.3高質量的代碼是封裝良好的100 
9.4高質量的代碼是自主的102 
9.5高質量的代碼是沒有冗餘的104 
9.6讓代碼特質指導我們105 
9.7今天的代碼質量提高會為將來帶來速度的提升106 
9.8讓我們付諸實踐107 
9.8.1提高代碼質量的7個策略107 
9.8.2編寫可維護代碼的7個策略108 
9.9總結109 

第10章實踐6：測試先行110 

10.1測試的種類111 
10.1.1驗收測試=客戶測試111 
10.1.2單元測試=開發者測試111
10.1.3其他測試=質量保證測試112 
10.2質量保證112 
10.2.1測試驅動開發不能取代質量保證113 
10.2.2單元測試不是萬能的113 
10.3編寫優質測試114 
10.3.1這不是測試115 
10.3.2以行為作為單元115 
10.4 TDD可以提供迅速的反饋116 
10.5 TDD可以為重構提供支持116 
10.6編寫可測試的代碼117 
10.7 TDD也會失敗118 
10.8如何將TDD引入團隊119 
10.9成為測試感染者119 
10.10讓我們付諸實踐120 
10.10.1進行優質驗收測試的7個策略120 
10.10.2進行優秀單元測試的7個策略121 
10.11總結122 

第11章實踐7：用測試描述行為123 

11.1紅條、綠條、重構124 
11.2一個用測試先行來描述行為的實例125 
11.2.1編寫測試125 
11.2.2存根代碼126 
11.2.3實現行為127 
11.3引入限制條件128 
11.3.1編寫測試和代碼存根129 
11.3.2實現行為129 
11.4我們創建了什麼130
11.5測試就是標準132 
11.6測試需要完整133 
11.7讓測試獨一無二134 
11.8用測試來覆蓋代碼134 
11.9 bug是缺失的測試135 
11.10用模擬對象來測試工作流135 
11.11建立防護網136 
11.12讓我們付諸實踐136 
11.12.1使用測試作為標準的7個策略136 
11.12.2修復bug的7個策略137 
11.13總結139 

第12章實踐8：最後實現設計140 

12.1可變性的阻礙140 
12.2可持續性開發142 
12.3編碼與清理143 
12.4軟件被閱讀的次數比編寫次數多143 
12.5意圖導向編程144 
12.6降低圈複雜度145 
12.7將創建和使用分離146 
12.8演化式設計147 
12.9讓我們付諸實踐147 
12.9.1進行演化式設計的7個策略148 
12.9.2清理代碼的7個策略149 
12.10總結150 

第13章實踐9：重構遺留代碼151 

13.1投資還是藉貸152 
13.2變成“鐵公雞” 153 
13.3當代碼需要修改時153
13.3.1對已有代碼添加測試154 
13.3.2通過重構糟糕代碼來培養良好習慣154 
13.3.3推遲那些不可避免的155 
13.4重構技巧155 
13.4.1圖釘測試155 
13.4.2依賴注入156 
13.4 .3系統扼殺156 
13.4.4抽象分支156 
13.5以支持修改為目的重構157 
13.6以開閉原則為目的重構157 
13.7以提高可修改性為目的重構158 
13.8第二次做好158 
13.9讓我們付諸實踐159 
13.9.1助你正確重構代碼的7個策略159 
13.9.2決定何時進行重構的7個策略161 
13.10總結162 

第14章從遺留代碼中學習163 

14.1更好，更快，更廉價164 
14.2不在不需要的事情上花錢166 
14.3循規蹈矩167 
14.4提升整個軟件行業168 
14.5超越敏捷169 
14.6將理解具象化170 
14.7成長的勇氣171 
參考文獻174