出版信息
定價：89.00元
作者：[美]Andy Oram Greg Wilson 編著
出版社：人民郵電出版社
出版時間：2012年03月
版次：1.1
開本：16開
裝幀：平裝
字數：728千字
頁數：438頁
開卷分類：計算機
內容簡介
《軟體之道：軟體開發爭議問題剖析》集合了幾十位軟體工程領域頂尖研究人員的實證研究，通過呈現他們長達幾年甚至幾十年的研究成果，揭示了軟體開發社區普遍存在的一些確鑿事實和虛構之事。書中探討了更有效的程式語言，對比了軟體開發人員之間的效率差異，驗證了康威定理，並反思了軟體行業的最新模式。《軟體之道：軟體開發爭議問題剖析》將幫助讀者拓寬視野，更好地選擇適合的工具和技術，並最終成為一名更加優秀的軟體行業從業人員。 《軟體之道：軟體開發爭議問題剖析》適合所有軟體開發人員和研究人員閱讀。
目錄
第一部分 搜尋和使用證據的一般原則
第1章 探尋有力的證據 2
1.1 起步階段 2
1.2 當今證據的狀態 3
1.2.1 精確性研究的挑戰 3
1.2.2 統計強度的挑戰 3
1.2.3 結果可複製性的挑戰 4
1.3 我們可以相信的改變 5
1.4 背景的影響 7
1.5 展望未來 7
1.6 參考文獻 9
第2章 可信度，為什麼我堅決要求確信的證據 12
2.1 軟體工程中的證據是如何發現的 12
2.2 可信度和適用性 13
2.2.1 適用性，為什麼使你信服的證據不能使我信服 14
2.2.2 定性證據對戰定量證據：錯誤的二分法 15
2.3 整合證據 16
2.4 證據的類型以及它們的優缺點 17
2.4.1 對照實驗和準實驗 18
2.4.2 問卷調查 19
2.4.3 經驗匯報和案例研究 20
2.4.4 其他方法 20
2.4.5 報告中的可信度(或缺乏可信度)的標識 21
2.5 社會、文化、軟體工程和你 23
2.6 致謝 24
2.7 參考文獻 24
第3章 我們能從系統性評審中學到什麼 25
3.1 系統性評審總覽 26
3.2 系統性評審的長處和短處 27
3.2.1 系統性評審的流程 28
3.2.2 開展一項評審所牽連的問題 30
3.3 軟體工程中的系統性評審 31
3.3.1 成本估算研究 32
3.3.2 敏捷方法 33
3.3.3 檢驗方法 35
3.4 結論 35
3.5 參考文獻 36
第4章 用定性研究方法來理解軟體工程學 40
4.1 何為定性研究方法 41
4.2 如何解讀定性研究 42
4.3 在工作中運用定性研究方法 44
4.4 推廣套用定性研究的結果 45
4.5 定性研究方法是系統的研究方法 46
4.6 參考文獻 46
第5章 在實踐中學習成長：軟體工程實驗室中的質量改進範式 47
5.1 軟體工程研究獨有的困難之處 47
5.2 實證研究的現實之路 48
5.3 NASA軟體工程實驗室：一個充滿活力的實證研究測試平台 48
5.4 質量改進範式 49
5.4.1 表征 51
5.4.2 設立目標 51
5.4.3 選擇流程 51
5.4.4 執行流程 53
5.4.5 分析 53
5.4.6 封裝 53
5.5 結論 55
5.6 參考文獻 55
第6章 性格、智力和專業技能對軟體開發的影響 57
6.1 如何辨別優秀的程式設計師 58
6.1.1 個體差異：固定的還是可塑造的 58
6.1.2 個性 59
6.1.3 智力 63
6.1.4 編程任務 65
6.1.5 編程表現 65
6.1.6 專業技能 66
6.1.7 軟體工作量估算 68
6.2 環境因素還是個人因素 68
6.2.1 軟體工程中應該提高技能還是提高安全保障 69
6.2.2 合作 69
6.2.3 再談個性 72
6.2.4 從更廣的角度看待智力 72
6.3 結束語 74
6.4 參考文獻 75
第7章 為什麼學編程這么難 81
7.1 學生學習編程有困難嗎 82
7.1.1 2001年McCracken工作小組 82
7.1.2 Lister工作小組 83
7.2 人們對編程的本能理解是什麼 83
7.3 通過可視化編程來最佳化工具 85
7.4 融入語境後的改變 86
7.5 總結：一個新興的領域 88
7.6 參考文獻 89
第8章 超越代碼行：我們還需要其他的複雜度指標嗎 92
8.1 對軟體的調查 92
8.2 計算原始碼的指標 93
8.3 指標計算案例 94
8.3.1 原始碼行數(SLOC) 96
8.3.2 代碼行數(LOC) 96
8.3.3 C函式的數量 96
8.3.4 McCabe圈複雜度 96
8.3.5 Halstead軟體科學指標 97
8.4 統計分析 98
8.4.1 總體分析 98
8.4.2 頭檔案和非頭檔案之間的區別 99
8.4.3 干擾效應：檔案大小對相關性的影響 100
8.5 關於統計學方法的一些說明 103
8.6 還需要其他的複雜度指標嗎 103
8.7 參考文獻 104
第二部分 軟體工程的特有話題
第9章 自動故障預報系統實例一則 106
9.1 故障的分布 106
9.2 故障高發檔案的特徵 109
9.3 預測模型概覽 109
9.4 預測模型的復驗和變體 110
9.4.1 開發人員的角色 111
9.4.2 用其他類型的模型來預測故障 113
9.5 工具的設計 115
9.6 一些忠告 115
9.7 參考文獻 117
第10章 架構設計的程度和時機 119
10.1 修正缺陷的成本是否會隨著項目的進行而增加 119
10.2 架構設計應該做到什麼程度 120
10.3 架構設計的成本——修複數據給予我們的啟示 123
10.3.1 關於COCOMO II架構設計和風險解決係數的基礎知識 123
10.3.2 Ada COCOMO及COCOMO II中的架構設計以及風險應對係數 125
10.3.3 用於改善系統設計的投入的ROI 130
10.4 那么到底架構要做到什麼程度才夠 132
10.5 架構設計是否必須提前做好 135
10.6 總結 135
10.7 參考文獻 136
第11章 康威推論 138
11.1 康威定律 138
11.2 協調工作、和諧度和效率 140
11.3 微軟公司的組織複雜度 143
11.4 開源軟體集市上的小教堂 148
11.5 總結 152
11.6 參考文獻 152
第12章 測試驅動開發的效果如何 153
12.1 TDD藥丸是什麼 153
12.2 TDD臨床試驗概要 154
12.3 TDD的效力 156
12.3.1 內部質量 156
12.3.2 外部質量 157
12.3.3 生產力 157
12.3.4 測試質量 158
12.4 在試驗中強制TDD的正確劑量 158
12.5 警告和副作用 159
12.6 結論 160
12.7 致謝 160
12.8 參考文獻 160
第13章 為何計算機科學領域的女性不多 163
13.1 為什麼女性很少 163
13.1.1 能力缺陷，個人喜好以及文化偏見 164
13.1.2 偏見、成見和男性計算機科學文化 166
13.2 值得在意嗎 168
13.2.1 扭轉這種趨勢，我們可以做些什麼 170
13.2.2 跨國數據的意義 171
13.3 結論 172
13.4 參考文獻 172
第14章 兩個關於程式語言的比較 175
14.1 一個搜尋算法決定了一種語言的勝出 175
14.1.1 編程任務：電話編碼 176
14.1.2 比較執行速度 176
14.1.3 記憶體使用情況的比較 178
14.1.4 比較效率和代碼長度 178
14.1.5 比較可靠性 180
14.1.6 比較程式結構 180
14.1.7 我可以相信嗎 181
14.2 Plat_Forms：網路開發技術和文化 182
14.2.1 開發任務：人以類聚 182
14.2.2 下注吧 183
14.2.3 比較工作效率 184
14.2.4 比較軟體工件的大小 185
14.2.5 比較可修改性 186
14.2.6 比較穩健性和安全性 187
14.2.7 嘿，“插入你自己的話題”如何 189
14.3 那又怎樣 189
14.4 參考文獻 189
第15章 質量之戰：開源軟體對戰專有軟體 191
15.1 以往的衝突 192
15.2 戰場 192
15.3 開戰 195
15.3.1 檔案組織 196
15.3.2 代碼結構 200
15.3.3 代碼風格 204
15.3.4 預處理 209
15.3.5 數據組織 211
15.4 成果和結論 213
15.5 致謝 215
15.6 參考文獻 215
第16章 碼語者 219
16.1 程式設計師的一天 219
16.1.1 日記研究 220
16.1.2 觀察研究 220
16.1.3 程式設計師們是不是在掙表現 220
16.2 說這么多有什麼意義 221
16.2.1 問問題 221
16.2.2 探尋設計理念 223
16.2.3 工作的中斷和多任務 223
16.2.4 程式設計師都在問什麼問題 224
16.2.5 使用敏捷方法是不是更利於溝通 227
16.3 如何看待溝通 228
16.4 參考文獻 229
第17章 結對編程 230
17.1 結對編程的歷史 230
17.2 產業環境中的結對編程 232
17.2.1 結對編程的行業實踐 232
17.2.2 業內使用結對編程的效果 233
17.3 教育環境中的結對編程 234
17.3.1 教學中特有的實踐 234
17.3.2 教學中使用結對編程的效果 235
17.4 分散式結對編程 235
17.5 面對的挑戰 236
17.6 經驗教訓 237
17.7 致謝 237
17.8 參考文獻 237
第18章 現代化代碼審查 243
18.1 常識 243
18.2 程式設計師獨立進行小量代碼審查 243
18.2.1 防止注意力疲勞 244
18.2.2 切忌速度過快 244
18.2.3 切忌數量過大 245
18.2.4 上下文的重要性 246
18.3 團隊影響 247
18.3.1 是否有必要開會 247
18.3.2 虛假缺陷 247
18.3.3 外部審查真的需要嗎 248
18.4 結論 249
18.5 參考文獻 249
第19章 公共辦公室還是私人辦公室 251
19.1 私人辦公室 251
19.2 公共辦公室 253
19.3 工作模式 255
19.4 最後的忠告 257
19.5 參考文獻 257
第20章 識別及管理全球性軟體開發中的依賴關係 258
20.1 為什麼協調工作對於GSD來說是挑戰 258
20.2 依賴關係及其社會/技術二重性 259
20.2.1 技術方面 261
20.2.2 社會/組織結構方面 263
20.2.3 社會—技術方面 266
20.3 從研究到實踐 267
20.3.1 充分使用軟體儲存庫中的數據 267
20.3.2 團隊領導和管理者在依賴關係管理中的角色 268
20.3.3 開發人員、工作項目和分散式開發 269
20.4 未來的方向 269
20.4.1 適合GSD的軟體架構 269
20.4.2 協作軟體工程工具 270
20.4.3 標準化和靈活度的平衡 271
20.5 參考文獻 271
第21章 模組化的效果如何 274
21.1 所分析的軟體系統 275
21.2 如何定義“修改” 276
21.3 如何定義“模組” 280
21.4 研究結果 281
21.4.1 修改的範圍 281
21.4.2 需要參考的模組 283
21.4.3 自髮式的模組化 284
21.5 有效性的問題 286
21.6 總結 287
21.7 參考文獻 287
第22章 設計模式的證據 289
22.1 設計模式的例子 290
22.2 為什麼認為設計模式可行 292
22.3 第一個實驗：關於設計模式文檔的測試 293
22.3.1 實驗的設計 293
22.3.2 研究結果 295
22.4 第二個實驗：基於設計模式的解決方案和簡單解決方案的對比 297
22.5 第三個試驗：設計模式之於團隊溝通 300
22.6 經驗教訓 302
22.7 總結 304
22.8 致謝 304
22.9 參考文獻 305
第23章 循證故障預測 306
23.1 簡介 306
23.2 代碼覆蓋率 308
23.3 代碼變動 308
23.4 代碼複雜度 311
23.5 代碼依賴 312
23.6 人與組織度量 312
23.7 預測缺陷的綜合方法 315
23.8 結論 317
23.9 致謝 319
23.10 參考文獻 319
第24章 採集缺陷報告的藝術 322
24.1 缺陷報告的優劣之分 322
24.2 優秀缺陷報告需要具備的要素 323
24.3 調查結果 325
24.3.1 開發人員眼中的缺陷報告內容 325
24.3.2 報告者眼中的缺陷報告內容 326
24.4 來自不一致信息的證據 327
24.5 缺陷報告的問題 329
24.6 重複缺陷報告的價值 330
24.7 並非所有的缺陷都被修復了 332
24.8 結論 333
24.9 致謝 334
24.10 參考文獻 334
第25章 軟體的缺陷都從哪兒來 335
25.1 研究軟體的缺陷 335
25.2 本次研究的環境和背景 336
25.3 第一階段：總體調查 337
25.3.1 調查問卷 337
25.3.2 數據的總結 339
25.3.3 第一部分的研究總結 342
25.4 第二階段：設計/代碼編寫類故障調查 342
25.4.1 調查問卷 342
25.4.2 統計分析 345
25.4.3 界面故障與實現故障 358
25.5 研究結果可靠嗎 360
25.5.1 我們調查的對象是否正確 360
25.5.2 我們的方法是否正確361
25.5.3 我們能用這些結果做什麼 362
25.6 我們明白了什麼 362
25.7 致謝 364
25.8 參考文獻 364
第26章 新手專家：軟體行業的應屆畢業生們 367
26.1 研究方法 368
26.1.1 研究對象 369
26.1.2 任務分析 370
26.1.3 任務案例 370
26.1.4 做回顧的方法 371
26.1.5 有效性問題 371
26.2 軟體開發任務 372
26.3 新手開發人員的優點和缺點 374
26.3.1 優點分析 375
26.3.2 缺點分析 375
26.4 回顧 376
26.4.1 管理層的介入 377
26.4.2 毅力、疑惑和新人特質 377
26.4.3 大型的軟體團隊環境 378
26.5 妨礙學習的誤解 378
26.6 教育方法的反思 379
26.6.1 結對編程 380
26.6.2 合理的邊際參與 380
26.6.3 導師制 380
26.7 改變的意義 381
26.7.1 新人培訓 381
26.7.2 學校教育 382
26.8 參考文獻 383
第27章 挖掘你自己的證據 385
27.1 對什麼進行數據挖掘 385
27.2 設計你的研究 386
27.3 數據挖掘入門 387
27.3.1 第一步：確定要用哪些數據 387
27.3.2 第二步：獲取數據 388
27.3.3 第三步：數據轉換(可選) 389
27.3.4 第四步：提取數據 389
27.3.5 第五步：解析bug報告 390
27.3.6 第六步：關聯數據 390
27.3.7 第六步：找出漏掉的關聯 391
27.3.8 第七步：將bug對應到檔案 391
27.4 下面怎么辦 392
27.5 致謝 394
27.6 參考文獻 394
第28章 正當使用“複製-貼上”大法 396
28.1 代碼克隆的示例 396
28.2 尋找軟體中的克隆代碼 398
28.3 對代碼克隆行為的調查 399
28.3.1 分叉 400
28.3.2 模板 401
28.3.3 定製 402
28.4 我們的研究 403
28.5 總結 405
28.6 參考文獻 406
第29章 你的API有多好用 407
29.1 為什麼研究API的易用性很重要 407
29.2 研究API易用性的首次嘗試 409
29.2.1 研究的設計 410
29.2.2 第一次研究的結論摘要 411
29.3 如果一開始你沒有成功 412
29.3.1 第二次研究的設計 412
29.3.2 第二次研究的結論摘要 412
29.3.3 認知維度 414
29.4 使用不同的工作風格 418
29.5 結論 421
29.6 參考文獻 422
第30章 “10倍”意味著什麼？編程生產力的差距測量 423
30.1 軟體開發中的個人效率的變化 423
30.1.1 巨大的差距帶來的負面影響 424
30.1.2 什麼造就了真正的“10倍程序員” 424
30.2 測量程式設計師的個人生產力的問題 424
30.2.1 生產力=每月產出的代碼行數嗎 424
30.2.2 生產力=功能點嗎 425
30.2.3 複雜度呢 425
30.2.4 到底有沒有辦法可以測量個人生產力 425
30.3 軟體開發中的團隊生產力差距 426
30.4 參考文獻 427
撰稿人 429
