修改軟件的藝術 構建易維護代碼的9條最佳實踐 pdf epub mobi txt 電子書 下載 2025

簡體網頁||繁體網頁

☆☆☆☆☆

[美] 戴維，斯科特，伯恩斯坦（David，Scott，Bernstein） 著，李滿慶 譯

圖書標籤:

• 軟件工程
• 代碼質量
• 可維護性
• 重構
• 最佳實踐
• 軟件設計
• 編程技巧
• 代碼規範
• 軟件開發
• 技術書籍

齣版社： 人民郵電齣版社

ISBN：9787115467768

版次：1

商品編碼：12251466

包裝：平裝

叢書名： 圖靈程序設計叢書

開本：16開

齣版時間：2017-10-01

用紙：膠版紙

頁數：175

正文語種：中文

編輯推薦

遺留代碼是指因為種種原因格外難以修正、改進以及使用的代碼，這樣的代碼有很多，每天我們都會因為遺留代碼而損失時間、金錢和機遇，軟件産業通常輕視可維護性，所以到最後企業花在維護代碼上的成本比一開始編寫代碼的成本還高。本書針對這一現狀，總結瞭9條構建易維護代碼、解決遺留代碼的zui佳原則，是敏捷開發的具體實戰指南。
本書不僅僅是關於如何構建更好的軟件，更是關於如何構建更好的軟件産業。書中囊括瞭作者身為專業開發者三十年所學的精華。如果你想要優化軟件交付流程，但是感覺到裹足不前、無能為力，那麼這本書正適閤你。

內容簡介

《修改軟件的藝術 構建易維護代碼的9條*佳實踐》會幫你降低構建與維護軟件的成本。如果你是軟件開發者，將學到一套實踐方法以構建易修改的代碼，因為在應用當中代碼經常需要修改。對於和軟件開發者閤作的管理者來說，本書會嚮你展示為何引入這9個基本的實踐方法，會使你的團隊更加有效地交付軟件而不至於讓軟件演變成遺留代碼。

作者簡介

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

《精煉代碼：擁抱可維護性的軟件之道》 在數字洪流奔湧不息的今天，軟件的生命力不再僅僅取決於其最初的強大功能，更在於它能否隨著時間的推移，靈活地適應變化，高效地被理解、修改和擴展。這並非一個抽象的概念，而是關乎每一個項目生死存亡的關鍵。本書《精煉代碼：擁抱可維護性的軟件之道》正是應運而生，它深入探討瞭構建和維護高質量、長生命周期軟件的本質，旨在為開發者提供一套切實可行、經過實踐檢驗的智慧與技藝，讓代碼從“冰冷的指令”蛻變為“活力的資産”。 我們深知，軟件開發並非一蹴而就的靜態過程，而是一個持續演進的動態生命體。一個設計精良、易於維護的軟件係統，能夠極大地降低開發成本，縮短産品迭代周期，提升團隊協作效率，最終在激烈的市場競爭中占據優勢。反之，那些如同“迷宮”般難以理解、修改時如同“拆彈”般充滿風險的代碼，不僅會消耗寶貴的開發資源，更可能扼殺項目的生命力，甚至導緻整個係統的崩潰。 本書並非空中樓閣的理論堆砌，而是基於對大量成功與失敗案例的深刻洞察，提煉齣的九條核心最佳實踐。這九條實踐環環相扣，共同構建瞭一個堅實的框架，幫助開發者在軟件開發的每一個環節，都將“可維護性”置於核心地位。我們不會簡單地羅列一些“應該這樣做”的建議，而是深入剖析每一條實踐背後的邏輯、原理以及在實際開發中遇到的挑戰和解決方案。 第一條：清晰至上的原則——代碼的易讀性是第一生産力 我們始終堅信，代碼首先是寫給人看的，其次纔是給機器執行的。當代碼變得清晰可讀，它便擁有瞭生命力。這意味著，開發者需要投入時間去撰寫富有錶現力的命名，保持一緻的代碼風格，運用恰當的注釋來闡明意圖而非實現細節。我們將在這一章中，深入探討如何通過精煉的命名、閤理的代碼結構、有效的代碼分塊等方式，將復雜的邏輯轉化為易於理解的語言。我們將分析那些“糟糕的命名”如何像一道道迷霧，阻礙開發者理解代碼，以及“清晰的命名”如何像一盞明燈，指引方嚮。同時，我們也會探討如何避免過度冗長的函數和類，如何通過提取、組閤等技巧，讓代碼的結構如同清晰的流程圖，一目瞭然。 第二條：模塊化的智慧——拆解復雜，擁抱獨立 一個龐大而雜亂的係統，往往是導緻維護睏難的根源。本書將重點闡述模塊化設計的強大力量。通過將大型係統拆解成功能內聚、接口清晰的獨立模塊，我們可以顯著降低係統的復雜度。每一模塊的修改，都將盡可能地局限於其內部，避免對其他模塊産生“漣漪效應”。我們將深入探討如何識彆閤適的模塊邊界，如何設計簡潔且定義明確的接口，以及如何利用依賴注入、服務定位等模式，實現模塊間的鬆耦閤。你將學習到如何讓代碼如同樂高積木一般，可以輕鬆地被替換、升級或重新組閤，從而構建齣具有強大適應性的係統。 第三條：單一職責的守護——專注的類，高效的維護 “每個類或函數隻做一件事，並且把它做好。”這條看似樸素的原則，卻是構建可維護代碼的基石。當一個類承擔瞭過多的職責，它就變得脆弱且難以理解。修改其中一個功能，很可能就會影響到其他功能。本章將深入剖析單一職責原則（SRP）的重要性，教你如何識彆那些“多麵手”的類，如何將其職責進行閤理的拆分，並賦予每個新類一個清晰、明確的職責。我們將通過具體的案例，展示SRP如何提升代碼的可測試性，降低耦閤度，以及讓代碼的修改變得更加局部化和可控。 第四條：高內聚與低耦閤的平衡——構建穩定而靈活的係統 內聚與耦閤，是衡量軟件設計質量的兩個核心指標。高內聚意味著模塊內部的元素高度相關，協同工作完成一個整體功能；低耦閤則意味著模塊之間的依賴關係盡可能弱。本書將詳細解析如何在這兩者之間找到最佳的平衡點。我們將探討如何通過封裝、抽象等手段，提升模塊的內聚性；同時，也會深入講解如何運用設計模式、接口編程等技術，降低模塊間的耦閤度。你將理解，高內聚低耦閤的係統，如同一個精密的機械裝置，各部件各司其職，又協同運轉，即使某個部件需要調整，也不會影響到整個機器的正常運行。 第五條：麵嚮接口編程——抽象的力量，解耦的藝術 “麵嚮接口編程”是實現低耦閤的關鍵策略之一。本章將帶你領略抽象的強大力量。通過定義接口，我們將關注“做什麼”，而非“如何做”。這使得具體的實現可以被隨意替換，而調用者卻無需關心底層的實現細節。我們將深入講解接口的定義、實現，以及如何利用接口實現多態，構建更加靈活和可擴展的係統。你將學會如何通過抽象，將變化隔離在接口的實現層，從而保護係統的核心邏輯不受影響。 第六條：優雅的錯誤處理——讓異常成為可控的敘事 錯誤處理是軟件開發中常常被忽視但至關重要的一環。粗暴的錯誤處理不僅會讓用戶體驗大打摺扣，更會給維護者帶來巨大的睏擾。本書將闡述如何構建一種優雅、清晰的錯誤處理機製。我們將探討不同類型的錯誤（如運行時錯誤、邏輯錯誤），以及如何選擇恰當的錯誤處理方式（如返迴錯誤碼、拋齣異常）。我們還會深入講解異常的捕獲、處理和傳遞，以及如何通過設計良好的錯誤信息，幫助開發者快速定位問題，避免“捕獲一切”的萬能陷阱。 第七條：自動化測試的利劍——保障代碼質量的堅實後盾 測試是保障代碼質量，提升維護信心的最有力武器。本章將深入講解自動化測試的重要性，以及如何將其融入開發流程。我們將涵蓋單元測試、集成測試、端到端測試等不同層級的測試策略，並詳細介紹如何編寫高質量的測試用例，如何利用測試驅動開發（TDD）等方法，讓測試成為設計過程的一部分。你將明白，自動化測試並非開發過程的負擔，而是提升開發效率、降低Bug率、增強代碼重構信心的關鍵。 第八條：版本控製的紀律——時間綫上的協作與追溯 版本控製係統是現代軟件開發的基石。然而，僅僅使用版本控製是不夠的，更需要建立一套清晰、規範的版本控製流程。本書將深入探討如何有效地利用版本控製係統，如Git，來管理代碼變更。我們將講解分支策略（如Git Flow）、代碼閤並的原則、提交信息的規範化，以及如何利用版本控製的曆史記錄來追溯問題、理解代碼演變。你將學會如何讓版本控製成為團隊協作的潤滑劑，而非衝突的導火索。 第九條：代碼審查的智慧——共同打磨，持續改進 代碼審查是軟件開發中最具實踐價值的協作活動之一。它不僅能幫助發現潛在的Bug和設計缺陷，更能促進團隊成員間的知識共享和技能提升。本章將聚焦於如何開展有效且富有成效的代碼審查。我們將探討代碼審查的目標、流程，以及如何給齣建設性的反饋。你將學習到如何從審查者的角度發現問題，如何從被審查者的角度虛心接受意見，以及如何將代碼審查轉化為一種持續學習和共同成長的機製。 《精煉代碼：擁抱可維護性的軟件之道》並非一本速成秘籍，它是一次深入的探索，一次關於軟件生命力的思考。我們希望通過本書，能夠啓發開發者從更宏觀的視角審視代碼，將“可維護性”內化為一種思維模式，一種行為習慣。無論是初齣茅廬的新手，還是身經百戰的老將，都能從中汲取養分，不斷精進自己的技藝，編寫齣真正能夠經受住時間考驗、承載無限可能性的軟件。讓我們一起踏上這場精煉代碼、擁抱可維護性的旅程，共同構建更美好、更持久的軟件世界。

評分☆☆☆☆☆

我是一名剛剛踏入軟件開發行業不久的新手，對於“代碼可維護性”這個概念，雖然有所耳聞，但總覺得有些虛無縹緲，不知道從何下手。在學校裏，我們學到的更多是算法、數據結構和如何讓程序跑起來，至於寫齣“好”的代碼，好像是個需要時間慢慢摸索的境界。我經常在寫完代碼後，過一段時間自己都看不懂，更彆提讓其他同學或者老師來指點瞭，那種挫敗感真的挺強的。 這本書的齣現，恰恰填補瞭我在這方麵的知識空白。我期待它能用一種非常直觀、易懂的方式，將“可維護性”這個概念拆解開來，讓我明白為什麼它如此重要，以及如何在實際編碼過程中一步步地實現它。書中提到的“9條最佳實踐”，對我來說就像是九盞指路明燈，希望能幫助我少走彎路，在職業生涯的早期就建立起良好的編碼習慣。我特彆想知道，這本書會不會講解一些具體的代碼重構技巧，或者如何通過設計模式來提升代碼的可讀性，以及在遇到復雜問題時，如何分解並保持代碼的清晰。

評分☆☆☆☆☆

作為一個有幾年開發經驗的程序員，我一直在努力提升自己的技術棧，不僅僅是掌握新的語言和框架，更重要的是提升代碼的質量和項目的可維護性。我曾參與過一些大型項目，項目啓動時大傢熱情飽滿，代碼寫得也算是清晰，但隨著時間的推移，新功能的不斷加入，老代碼的不斷修改，項目就像一個逐漸失控的怪獸，維護起來越來越睏難，bug也越來越多。 這本書的題目《修改軟件的藝術：構建易維護代碼的9條最佳實踐》直接點齣瞭我一直以來關心的問題。我特彆好奇書中提到的“9條最佳實踐”到底是什麼，它們是否能提供一套係統性的方法論，幫助我們應對日益增長的代碼復雜性。我期望這本書能夠深入淺齣地講解如何通過良好的設計原則、清晰的命名規範、有效的代碼組織方式以及恰當的測試策略來提高代碼的可維護性。我還希望它能提供一些關於如何處理遺留代碼、如何進行代碼評審、以及如何在團隊中推廣和實踐這些最佳實踐的經驗。

評分☆☆☆☆☆

我是一個在軟件行業摸爬滾打多年的開發者，見證瞭無數項目的興衰。從最初的對編程的熱情，到後來對代碼質量的深刻反思，我一直在尋找能夠提升代碼可維護性的有效方法。我見過太多優秀的創意因為糟糕的代碼實現而步履維艱，也見過太多團隊因為無法有效維護現有代碼而錯失良機。 《修改軟件的藝術：構建易維護代碼的9條最佳實踐》這個書名，簡直就是直擊我心中最痛的點。我非常好奇書中的“9條最佳實踐”到底包含哪些內容，它們是否能涵蓋代碼設計的各個方麵，從宏觀的架構到微觀的函數實現。我期待這本書能夠提供一套係統性的指導，幫助我理解為什麼某些代碼寫起來容易齣問題，以及如何從源頭上避免這些問題。我希望書中能有大量的實際案例，讓我能夠看到如何在不同的場景下應用這些最佳實踐，並且能夠感受到這些實踐所帶來的實際好處，比如縮短開發周期，降低維護成本，提升團隊協作效率。

評分☆☆☆☆☆

這本書簡直是為我量身定做的！我是一名在軟件開發領域摸爬滾打瞭近十年的老兵，也算是見過不少“屎山”代碼，親手挖過也親手填過。每次看到那些維護起來像拆炸彈一樣的項目，我就開始懷念起那些清晰、優雅、易於理解的代碼。這本書的齣現，簡直就像久旱逢甘霖。書名就直擊痛點，“修改軟件的藝術”，這本身就是一句詩，道齣瞭多少開發者的心聲。而“構建易維護代碼的9條最佳實踐”，更是讓人眼前一亮，仿佛找到瞭通往光明彼岸的九級颱階。 我尤其期待書中的“最佳實踐”部分。在我看來，寫齣能運行的代碼隻是第一步，能被其他人（或者幾個月後的自己）輕鬆理解和修改，纔是真正衡量代碼質量的標準。很多時候，我們花費在理解和修改他人代碼上的時間，遠遠超過瞭從零開始編寫新代碼的時間。這本書是否能提供切實可行的方法，比如如何進行更好的代碼組織、如何避免過度設計、如何編寫更有意義的注釋，甚至是如何在團隊協作中保持代碼的一緻性和可維護性，這些都是我非常好奇和期待的。我希望這本書不僅僅停留在理論層麵，而是能提供大量的實際案例和代碼示例，讓我們能夠舉一反三，真正地將這些實踐應用到日常開發中。

評分☆☆☆☆☆

我對軟件開發的熱情一直很高，但隨著接觸的項目越來越多，我逐漸意識到，寫齣能跑的代碼隻是基礎，寫齣易於理解、易於修改、易於擴展的代碼，纔是真正考驗一個程序員功力的所在。我經曆過太多項目，初期還算清晰，但隨著迭代次數的增加，代碼變得越來越難以捉摸，修改一個bug可能引發一係列新的問題，整個團隊都陷入瞭維護的泥沼。 這本書的齣現，讓我眼前一亮。“修改軟件的藝術”這個標題本身就充滿瞭吸引力，它暗示瞭這不僅僅是一本技術手冊，更是一門關於如何優雅地處理軟件生命周期中挑戰的學問。而“構建易維護代碼的9條最佳實踐”，更是直接指嚮瞭核心問題。我非常期待書中能深入探討如何通過結構化的方法來提升代碼的可維護性，比如如何進行模塊化設計，如何實現低耦閤高內聚，以及如何在代碼中清晰地錶達意圖。我希望這本書能夠提供一些切實可行的技巧和原則，幫助我寫齣更具生命力的代碼，讓團隊的協作更加順暢，讓項目的維護成本大大降低。

評分☆☆☆☆☆

物流超級快 搞活動價格閤適

評分☆☆☆☆☆

值得每位想寫好代碼的程序員看

評分☆☆☆☆☆

比較慘，京東的圖片總是顯得很厚

評分☆☆☆☆☆

這是好書，有時候就需要這種概念性的書，而且沒有什麼廢話

評分☆☆☆☆☆

好書，支持！什麼時候齣電子版就好瞭。

評分☆☆☆☆☆

不錯不錯不錯

評分☆☆☆☆☆

紙質還可以，比較薄的一本

評分☆☆☆☆☆

包裝不錯，內容還可以

評分☆☆☆☆☆

沒有看到下麵的小字“以Python為例”，不過正好入門一下Python瞭，書的質量好，有封膜，又可以學習一個，Excited！