第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.3.1 情況發生瞭改變 18
2.3.2 bug泛濫成災 19
2.3.3 復雜性危機 20
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
· · · · · · (收起)
具體描述
本書會幫你降低構建與維護軟件的成本。如果你是軟件開發者，將學到一套實踐方法以構建易修改的代碼，因為在應用當中代碼經常需要修改。對於和軟件開發者閤作的管理者來說，本書會嚮你展示為何引入這九個基本的實踐方法，會使你的團隊更加有效地交付軟件而不至於讓軟件演變成遺留代碼。
用戶評價
##這本書整體質量並不好。 開篇試圖模仿《人件》的行文方式提齣〖有些事情不對勁〗，但是內容不過是老生常談；核心部分的九種實踐方法雖然是正確的，但是內容組織上順序和層次不好，導緻既沒有循序漸進的感覺，每一小節的論述也沒有眼前一亮的內容。 然而，它的最終章是作者的真知灼見。果然如《如何閱讀一本書》所言，沒有作者能夠拒絕在結尾寫齣自己最想說的話。《提升整個軟件行業》是作者對整個新興的軟件開發行業的遠景，我很願意接受他對知識共享的看法並為其持續發展而努力；《超越敏捷》體現瞭開發者創造軟件而不是軟件駕馭開發者的觀點；《把理解具象化》講齣瞭軟件是對現實世界的投影這個核心的思考角度；《成長的勇氣》類似於《程序員修煉之道》告訴我們必須關注你的技藝。如果有機會我也想就此展開討論，但簡而言之，本書終章值得一讀。
評分##後麵確實很一般。。。道理誰不懂，你倒是寫兩行代碼啊
評分##這本書整體質量並不好。 開篇試圖模仿《人件》的行文方式提齣〖有些事情不對勁〗，但是內容不過是老生常談；核心部分的九種實踐方法雖然是正確的，但是內容組織上順序和層次不好，導緻既沒有循序漸進的感覺，每一小節的論述也沒有眼前一亮的內容。 然而，它的最終章是作者的真知灼見。果然如《如何閱讀一本書》所言，沒有作者能夠拒絕在結尾寫齣自己最想說的話。《提升整個軟件行業》是作者對整個新興的軟件開發行業的遠景，我很願意接受他對知識共享的看法並為其持續發展而努力；《超越敏捷》體現瞭開發者創造軟件而不是軟件駕馭開發者的觀點；《把理解具象化》講齣瞭軟件是對現實世界的投影這個核心的思考角度；《成長的勇氣》類似於《程序員修煉之道》告訴我們必須關注你的技藝。如果有機會我也想就此展開討論，但簡而言之，本書終章值得一讀。
評分##本書偏嚮於介紹敏捷開發、項目管理。本書也比較薄，不到兩百頁。
評分##更偏嚮於scrum開發的項目管理吧，職場新人可以看看。
評分##乾巴巴的話太多，看起來道理都對，就是講的讓人讀不下去。這還頗像某些團隊裏的人，能力其實是有，就是不能好好錶達。
評分##名字比較誤導，其實講的就是編程的一些最佳實踐，內容比較淺，但是其實比較能夠抓住要點
評分##名字比較誤導，其實講的就是編程的一些最佳實踐，內容比較淺，但是其實比較能夠抓住要點
評分##絮絮叨叨的。
相關圖書
本站所有內容均為互聯網搜尋引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 book.teaonline.club All Rights Reserved. 圖書大百科 版權所有