內容介紹
相 信大家常常聽說某些工具、技術和實踐方法可以改進軟體開發，但其中哪些說法是可被證實的，哪些僅僅是人們一廂情願的想法？本書收錄了Steve McConnell、 Barry Boehm和 Barbara Kitchenham等幾十位軟體工程領域頂尖研究人員的文章，深入討論了軟體開發社區中常見的一些觀點，一些是確鑿事實，一些則是荒誕說法。他們的深刻 見解定會讓你大開眼界。某些編程人員的工作成效果真是他人十倍之多？
測試驅動的開發果真能幫助更快、更好地開發代碼？
軟體的bug數量果真可以利用代碼度量進行預測？
設計模式果真有助於構建更好的應用程式？
人員個性會對結對編程產生何種影響？
地理位置的距離和公司職位的差距，究竟何者影響更大？
作者介紹
本書是一本文集，作者包括：Jorge Aranda、Tom Ball、Victor R. Basili、Andrew Begel、Christian Bird、Barry Boehm、Marcelo Cataldo、Steven Clarke、Jason Cohen、Robert DeLine、Madeline Diep、Hakan 、Erdogmus、Michael Godfrey、Mark Guzdial、Jo E. Hannay、Ahmed E. Hassan、Israel Herraiz、Kim Sebastian Herzig、Cory Kapser、Barbara 、Kitchenham、Andrew Ko、Lucas Layman、Steve McConnell、Tim Menzies、Gail Murphy、Nachi Nagappan、Thomas J. Ostrand、Dewayne Perry
、Marian Petre、Lutz Prechelt、Rahul Premraj、Forrest Shull、Beth Simon
、Diomidis Spinellis、Neil Thomas、Walter Tichy、Burak Turhan、Elaine J. Weyuker、Michele A. Whitecraft、Laurie Williams、Wendy M. Williams、Andreas Zeller、Thomas Zimmermann
作品目錄
目錄第一部分 搜尋和使用證據的一般原則
第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 用於改善系統設計的投入的ROI130
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
