軟件之道：軟件開發(fā)爭議問題剖析

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