《軟體工藝》針對軟體開發，提出了一些相當棘手和敏感的問題，並給出了頗具爭議性的結論：從一個數百年來一直興旺發達的系統——工藝學中獲得啟示，尋找答案。《軟體工藝》用5個部分共19章的篇幅，系統地闡述作者的觀點，並試圖回答一直困擾著軟體行業的難題——我們應該如何重組軟體構造的過程，使其能夠如我們所願地有效運轉？第1部分共4章，對傳統的觀點提出質疑——軟體工程真的是解決軟體開發問題的靈丹妙藥嗎？第2部分共2章，這一部分提出了本書的觀點，即以軟體工藝的視角看待軟體開發。第3部分以7章的篇幅，從不同的角度全面地展現了軟體工藝理論所帶來的主要變化，以及如何實踐這個觀念。第4部分共3章，對比了軟體工藝與軟體工程，並為各自適用的範疇重新劃定了界限。第5部分共3章，分別討論軟體開發中的權宜之計和長期問題。 《軟體工藝》榮獲2002年度Jolt圖書大獎。閱讀本書，有助於引發讀者在軟體開發問題上的獨立思考，《軟體工藝》適合軟體行業的所有從業人員閱讀參考。
基本介紹
- 書名：軟體工藝
- 作者：Pete McBreen
- 出版社：人民郵電出版社
- 頁數：240頁
- 開本：32
- 品牌：人民郵電出版社
- 外文名：Software Craftsmanship: The New Imperative
- 譯者：熊節
- 出版日期：2013年1月1日
- 語種：簡體中文
- ISBN：9787115280688
基本介紹,內容簡介,作者簡介,圖書目錄,
基本介紹
內容簡介
《軟體工藝》曾獲有軟體行業奧斯卡之稱的Jolt圖書大獎，由知名技術作者、CSDN技術主編孟岩，資深技術編輯韓磊傾力推薦，知名IT技術專家 熊節主筆翻譯。《軟體工藝》是顛覆軟體工程、開發回歸人本，值得深思回味的經典力作。
作者簡介
Pete McBeen是一位獨立顧問，對軟體開發情有獨鐘。儘管將很多時間用於寫作、教學和顧問工作，但他仍然堅持每年至少在一個真實項目中親手從事編程工作。Pete特別善於為軟體開發者面臨的問題找到創造性的解決方案。在過去的很多年中，他參與了各種正式與非正式的過程改進活動，所以他能夠以超然的態度看待軟體業普遍存在的問題，並敏銳地意識到：“軟體開發理應有其樂趣。否則，開發過程就是錯的。”Pete住在加拿大亞伯達省的小鎮考昆，沒有再回到大城市居住的計畫。
圖書目錄
第一部分置疑軟體工程
第1章理解軟體工程 3
軟體工程的悖論 4
等待硬體開發時，軟體開發者在乾什麼？ 5
得到可用的硬體之後，軟體開發者如何加快交付的速度？ 5
傳統開發過程的內蘊 6
軟體工程的當代解讀 7
“足夠好”的軟體—庶民的軟體工程 9
軟體工程適合你的項目嗎？ 10
第2章軟體工程的困境 11
“有組織的、可計量的”軟體開發過程現實嗎？ 14
我們當然可以將軟體開發中的某些部分自動化，不是嗎？ 16
“足夠好”的軟體開發方法的危害 17
誰能取代軟體工程？ 19
第3章理解軟體開發 21
軟體資產 23
軟體開發需要團隊協作 25
軟體開發的分工有用嗎？ 26
沒有一勞永逸 27
尋找比“軟體工程”更合用的隱喻 30
第4章尋找一個比軟體工程更好的隱喻 33
軟體開發的工藝 35
與傳統工藝學的比較 37
軟體開發工藝的復興 38
第二部分軟體工藝
第5章重拾軟體開發 45
工藝學致力於改善軟體開發的現狀 46
工藝學鼓勵開發者編寫優秀的軟體 47
吹響號角 48
第6章無須執照的工藝學 51
工藝是私人性的 51
同行認可和推薦是獲得更好軟體的辦法 52
執照只是假象 53
執照是在向風車開戰 55
工藝學關注個人 57
軟體開發者不是太少，而是太多 57
第三部分軟體工藝隱含的意味
第7章工藝學對系統的用戶有何影響 65
軟體容易拷貝，所以軟體工藝能夠有效 66
批量市場的難題 67
工匠與用戶有一種不同的關係 69
但是，請記住：購買者很可能不是使用者 70
優秀的軟體應該簽上開發者的名字 71
為作品簽名會使情況發生變化 72
工匠應當對作品負責 72
工匠需要挑剔的用戶 73
更小、更堅固的軟體更有利於用戶 73
軟體工藝帶來協作式開發 74
第8章顧客與工匠的關係 75
給我一個真實的交付日期 75
揭穿“足夠好的軟體”的謬論 76
另一種選擇 78
不要只考慮出價最低的開發者 79
差勁的客戶將很難吸引優秀的開發者 80
讓軟體工匠因為自己的作品而獲得榮譽 80
要求開發者對作品負責 81
利用開發者之間的差異 81
僱傭優秀開發者組成的小團隊 82
優秀的開發者究竟值多少？ 83
但我們如何知道開發者有多優秀呢？ 84
根據交付的成果來衡量開發者的水平 85
在選擇工匠時，客戶在成本和質量之間作出權衡 87
軟體工匠的專業分工 88
客戶與軟體工匠有長期的聯繫 90
維護者是一個榮耀的身份 90
軟體工藝有益於長期使用的軟體 92
客戶與軟體工匠志趣相投 92
第9章工匠的管理 95
軟體工匠不是僱工 96
好的開發者比管理者更有價值 96
軟體開發的實際過程無法詳細定義 97
軟體工匠與管理者的關係 98
以管理優秀的開發者為樂為榮 98
優秀的管理者理解項目的節奏 99
軟體工匠喜歡創造軟體 100
軟體開發的根本從來沒有改變過 100
家有一老，如有一寶 101
軟體工藝要求全新的管理方式 103
軟體工藝不是“有計畫報廢” 103
軟體工匠堅持自己的要求 104
第10章成為軟體工匠 107
軟體工藝拒絕精細的分工 107
過度的專業化會延誤開發、導致錯誤 108
軟體工匠建造能夠理解的系統 109
工藝學需要獻身精神 109
如何成為軟體工匠？ 110
學徒是比學校教育更有效的學習方式 111
技師是工藝學傳統的關鍵 111
工藝學傳統已經延續多年 112
第11章工藝的掌握 115
軟體工藝大師是什麼樣子？ 116
善用你的老員工 116
“掌握技藝”意味著使用穩定的技術 117
軟體工匠不會僅僅因為工具“最新最好”而使用它 118
軟體工程對COBOL的謀殺 119
技藝需要花時間去掌握 120
“掌握”意味著承擔起傳遞工藝的責任 121
工匠挑選學徒和技師 122
第12章學徒開發者 123
我們必須扭轉開發者培訓質量下滑的局面 123
大學文憑與項目開發無關 125
會編程不等於會開發軟體 125
如果必須送初學者去培訓，選擇好的培訓課程 127
工藝的掌握，學徒比培訓更有效 127
成為學徒是重要的一步 128
為了降低對工作的影響，工匠慎選學徒 128
重要的是學，不是教 129
學徒不是學校 129
活到老學到老 130
學徒審查師傅的作品，並從中學習 131
學徒的角色 132
從低風險的任務開始 133
晉升到產品開發 133
因為能力而晉升 134
學徒不是廉價勞動力 134
學徒期是時間和精力的投資 136
學徒如何成為技師 137
第13章技師開發者 139
技師在工藝學傳統中的位置 140
技師開發者 140
技師很少單獨工作 141
技師關注應用程式的交付 141
技師在軟體工藝中扮演關鍵角色 143
第四部分重新定位軟體工程
第14章軟體工程項目 149
軟體工程的目標是大型系統項目 150
軟體工程需要專業分工 151
軟體工程項目依舊使用瀑布過程 151
編程是一項刻板的工作 152
軟體開發不是軟體工程項目的瓶頸 152
形形色色的軟體工程項目 153
敏捷方法代替縝密的軟體工程 154
第15章“軟體工程”隱喻的危害 155
無法以低成本實施軟體工程 155
魚與熊掌可以兼得？ 156
相信估算軟體工程項目的確需要很長的時間 156
軟體工程鼓勵“科學管理” 157
軟體工程輕視不精確的討論 159
軟體工廠：軟體的生產線 160
跨項目復用極難實現 161
冒險的“長時間復用” 162
“標準軟體開發過程”的迷思 164
傳統的分工無助於軟體開發 165
“最佳實踐”是“科學管理”的遺毒 166
最佳實踐使人墨守成規 166
最佳實踐阻礙了過程革新 167
軟體工程強迫我們忽視個人 168
軟體開發者不是可替換的資源 169
偽造一個“理想的開發過程” 169
開發過程，不嫌其多 170
拋棄軟體工程的瀑布式過程 171
瀑布方法需要大型團隊來實施 172
小型團隊絕不要嘗試軟體工程 173
第16章學習軟體工程的經驗 175
尺度和複雜度 175
做軟體，不容易 176
應用程式需要良好的結構 177
變化的代價很高——如果你不允許變化的話 178
交流至關重要 179
文檔總是錯的 180
用增量式開發來控制風險 180
精確的估算很難得到 181
借用這些經驗 183
第五部分星期一的早上
第17章經驗——項目成功的指示燈 189
根據聲望選擇軟體工匠 189
信任工匠的推薦 190
最後，開始大範圍搜尋 191
根據聲望和作品來評價工匠 191
考察工匠的作品 192
工匠的試演 193
由軟體工匠來組建開發團隊 194
根據個人了解和推薦挑選團隊成員 194
年富力強的開發團隊 195
為低預算團隊擔心 196
通力協作 196
使用增量式開發 197
儘早解決問題 198
任何人都能學會協作式開發 198
迴避極端技術 199
經驗的價值 200
他們去年在哪裡？ 201
獎勵優秀開發者 201
想要人才，就得付高薪 202
我們付得起那么多錢嗎？ 203
做好吃驚的準備 204
第18章為測試和維護而設計 207
是軟體套用，不是軟體項目 208
應用程式只會退休，不會結束 208
維護團隊理應拒絕醜陋的軟體 209
可維護軟體需要有自動測試 209
使應用程式能夠被測試 210
為維護而設計 211
創建可維護軟體需要經驗豐富的開發者 212
可維護軟體能夠生存多年 213
長壽的應用程式需要長壽的開發工具 213
開放源碼，軟體工藝的最愛 214
Java對項目的健康有害 214
可維護軟體需要穩定的基礎設施 215
優秀的軟體是全球性的 216
保證軟體的全球性 217
拒絕“有計畫報廢” 218
優秀的軟體需要優秀的用戶界面 218
能夠安全使用的軟體 219
可維護軟體易於診斷 220
外包的危害 221
外包忽視了軟體開發的本質 222
在外包中堅持軟體工藝 223
藉助外來的工匠 224
維護是軟體生命中最重要的部分 224
提高維護者的地位 225
維護者當受賞 226
並非所有軟體都必須可維護 226
“為測試和維護設計”不能一蹴而就 227
第19章活到老，學到老 229
創造學習的環境 229
用內部研討創造學習環境 230
邀請所有人參加講座 231
學習時間是一種投資 231
掌握軟體開發的技藝 231
鼓勵參加用戶組和技術會議 233
慎選培訓課程 234
課前聯繫 234
課後跟蹤 235
亡羊補牢 235
鼓勵員工活躍於開發者社群中 236
鼓勵出席技術會議 236
鼓勵開發者擔任講師 237
鼓勵開發者寫書 237
沉思的實踐者 238
第1章理解軟體工程 3
軟體工程的悖論 4
等待硬體開發時，軟體開發者在乾什麼？ 5
得到可用的硬體之後，軟體開發者如何加快交付的速度？ 5
傳統開發過程的內蘊 6
軟體工程的當代解讀 7
“足夠好”的軟體—庶民的軟體工程 9
軟體工程適合你的項目嗎？ 10
第2章軟體工程的困境 11
“有組織的、可計量的”軟體開發過程現實嗎？ 14
我們當然可以將軟體開發中的某些部分自動化，不是嗎？ 16
“足夠好”的軟體開發方法的危害 17
誰能取代軟體工程？ 19
第3章理解軟體開發 21
軟體資產 23
軟體開發需要團隊協作 25
軟體開發的分工有用嗎？ 26
沒有一勞永逸 27
尋找比“軟體工程”更合用的隱喻 30
第4章尋找一個比軟體工程更好的隱喻 33
軟體開發的工藝 35
與傳統工藝學的比較 37
軟體開發工藝的復興 38
第二部分軟體工藝
第5章重拾軟體開發 45
工藝學致力於改善軟體開發的現狀 46
工藝學鼓勵開發者編寫優秀的軟體 47
吹響號角 48
第6章無須執照的工藝學 51
工藝是私人性的 51
同行認可和推薦是獲得更好軟體的辦法 52
執照只是假象 53
執照是在向風車開戰 55
工藝學關注個人 57
軟體開發者不是太少，而是太多 57
第三部分軟體工藝隱含的意味
第7章工藝學對系統的用戶有何影響 65
軟體容易拷貝，所以軟體工藝能夠有效 66
批量市場的難題 67
工匠與用戶有一種不同的關係 69
但是，請記住：購買者很可能不是使用者 70
優秀的軟體應該簽上開發者的名字 71
為作品簽名會使情況發生變化 72
工匠應當對作品負責 72
工匠需要挑剔的用戶 73
更小、更堅固的軟體更有利於用戶 73
軟體工藝帶來協作式開發 74
第8章顧客與工匠的關係 75
給我一個真實的交付日期 75
揭穿“足夠好的軟體”的謬論 76
另一種選擇 78
不要只考慮出價最低的開發者 79
差勁的客戶將很難吸引優秀的開發者 80
讓軟體工匠因為自己的作品而獲得榮譽 80
要求開發者對作品負責 81
利用開發者之間的差異 81
僱傭優秀開發者組成的小團隊 82
優秀的開發者究竟值多少？ 83
但我們如何知道開發者有多優秀呢？ 84
根據交付的成果來衡量開發者的水平 85
在選擇工匠時，客戶在成本和質量之間作出權衡 87
軟體工匠的專業分工 88
客戶與軟體工匠有長期的聯繫 90
維護者是一個榮耀的身份 90
軟體工藝有益於長期使用的軟體 92
客戶與軟體工匠志趣相投 92
第9章工匠的管理 95
軟體工匠不是僱工 96
好的開發者比管理者更有價值 96
軟體開發的實際過程無法詳細定義 97
軟體工匠與管理者的關係 98
以管理優秀的開發者為樂為榮 98
優秀的管理者理解項目的節奏 99
軟體工匠喜歡創造軟體 100
軟體開發的根本從來沒有改變過 100
家有一老，如有一寶 101
軟體工藝要求全新的管理方式 103
軟體工藝不是“有計畫報廢” 103
軟體工匠堅持自己的要求 104
第10章成為軟體工匠 107
軟體工藝拒絕精細的分工 107
過度的專業化會延誤開發、導致錯誤 108
軟體工匠建造能夠理解的系統 109
工藝學需要獻身精神 109
如何成為軟體工匠？ 110
學徒是比學校教育更有效的學習方式 111
技師是工藝學傳統的關鍵 111
工藝學傳統已經延續多年 112
第11章工藝的掌握 115
軟體工藝大師是什麼樣子？ 116
善用你的老員工 116
“掌握技藝”意味著使用穩定的技術 117
軟體工匠不會僅僅因為工具“最新最好”而使用它 118
軟體工程對COBOL的謀殺 119
技藝需要花時間去掌握 120
“掌握”意味著承擔起傳遞工藝的責任 121
工匠挑選學徒和技師 122
第12章學徒開發者 123
我們必須扭轉開發者培訓質量下滑的局面 123
大學文憑與項目開發無關 125
會編程不等於會開發軟體 125
如果必須送初學者去培訓，選擇好的培訓課程 127
工藝的掌握，學徒比培訓更有效 127
成為學徒是重要的一步 128
為了降低對工作的影響，工匠慎選學徒 128
重要的是學，不是教 129
學徒不是學校 129
活到老學到老 130
學徒審查師傅的作品，並從中學習 131
學徒的角色 132
從低風險的任務開始 133
晉升到產品開發 133
因為能力而晉升 134
學徒不是廉價勞動力 134
學徒期是時間和精力的投資 136
學徒如何成為技師 137
第13章技師開發者 139
技師在工藝學傳統中的位置 140
技師開發者 140
技師很少單獨工作 141
技師關注應用程式的交付 141
技師在軟體工藝中扮演關鍵角色 143
第四部分重新定位軟體工程
第14章軟體工程項目 149
軟體工程的目標是大型系統項目 150
軟體工程需要專業分工 151
軟體工程項目依舊使用瀑布過程 151
編程是一項刻板的工作 152
軟體開發不是軟體工程項目的瓶頸 152
形形色色的軟體工程項目 153
敏捷方法代替縝密的軟體工程 154
第15章“軟體工程”隱喻的危害 155
無法以低成本實施軟體工程 155
魚與熊掌可以兼得？ 156
相信估算軟體工程項目的確需要很長的時間 156
軟體工程鼓勵“科學管理” 157
軟體工程輕視不精確的討論 159
軟體工廠：軟體的生產線 160
跨項目復用極難實現 161
冒險的“長時間復用” 162
“標準軟體開發過程”的迷思 164
傳統的分工無助於軟體開發 165
“最佳實踐”是“科學管理”的遺毒 166
最佳實踐使人墨守成規 166
最佳實踐阻礙了過程革新 167
軟體工程強迫我們忽視個人 168
軟體開發者不是可替換的資源 169
偽造一個“理想的開發過程” 169
開發過程，不嫌其多 170
拋棄軟體工程的瀑布式過程 171
瀑布方法需要大型團隊來實施 172
小型團隊絕不要嘗試軟體工程 173
第16章學習軟體工程的經驗 175
尺度和複雜度 175
做軟體，不容易 176
應用程式需要良好的結構 177
變化的代價很高——如果你不允許變化的話 178
交流至關重要 179
文檔總是錯的 180
用增量式開發來控制風險 180
精確的估算很難得到 181
借用這些經驗 183
第五部分星期一的早上
第17章經驗——項目成功的指示燈 189
根據聲望選擇軟體工匠 189
信任工匠的推薦 190
最後，開始大範圍搜尋 191
根據聲望和作品來評價工匠 191
考察工匠的作品 192
工匠的試演 193
由軟體工匠來組建開發團隊 194
根據個人了解和推薦挑選團隊成員 194
年富力強的開發團隊 195
為低預算團隊擔心 196
通力協作 196
使用增量式開發 197
儘早解決問題 198
任何人都能學會協作式開發 198
迴避極端技術 199
經驗的價值 200
他們去年在哪裡？ 201
獎勵優秀開發者 201
想要人才，就得付高薪 202
我們付得起那么多錢嗎？ 203
做好吃驚的準備 204
第18章為測試和維護而設計 207
是軟體套用，不是軟體項目 208
應用程式只會退休，不會結束 208
維護團隊理應拒絕醜陋的軟體 209
可維護軟體需要有自動測試 209
使應用程式能夠被測試 210
為維護而設計 211
創建可維護軟體需要經驗豐富的開發者 212
可維護軟體能夠生存多年 213
長壽的應用程式需要長壽的開發工具 213
開放源碼，軟體工藝的最愛 214
Java對項目的健康有害 214
可維護軟體需要穩定的基礎設施 215
優秀的軟體是全球性的 216
保證軟體的全球性 217
拒絕“有計畫報廢” 218
優秀的軟體需要優秀的用戶界面 218
能夠安全使用的軟體 219
可維護軟體易於診斷 220
外包的危害 221
外包忽視了軟體開發的本質 222
在外包中堅持軟體工藝 223
藉助外來的工匠 224
維護是軟體生命中最重要的部分 224
提高維護者的地位 225
維護者當受賞 226
並非所有軟體都必須可維護 226
“為測試和維護設計”不能一蹴而就 227
第19章活到老，學到老 229
創造學習的環境 229
用內部研討創造學習環境 230
邀請所有人參加講座 231
學習時間是一種投資 231
掌握軟體開發的技藝 231
鼓勵參加用戶組和技術會議 233
慎選培訓課程 234
課前聯繫 234
課後跟蹤 235
亡羊補牢 235
鼓勵員工活躍於開發者社群中 236
鼓勵出席技術會議 236
鼓勵開發者擔任講師 237
鼓勵開發者寫書 237
沉思的實踐者 238
