软件之道：软件开发争议问题剖析

第一部分　搜寻和使用证据的一般原则第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