具体描述
相 信大家常常听说某些工具、技术和实践方法可以改进软件开发，但其中哪些说法是可被证实的，哪些仅仅是人们一厢情愿的想法？本书收录了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 用于改善系统设计的投入的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
· · · · · · (收起)
读后感
评分
评分
评分
评分
用户评价
这是一本需要“慢读”的书，急躁是读不透它的。初次翻阅时，我可能只领会了表面上的几层含义，但随着工作场景的变换和自身经验的积累，每隔一段时间重读，总能从中挖掘出全新的洞察。作者对复杂性和熵增的理解尤其深刻，他将软件系统比作一个不断抵抗无序化的生命体，这个比喻让我对“技术债”有了全新的敬畏之心。书中对“沟通”在工程实践中的核心地位的论述，简直是振聋发聩。在很多技术分享中，人际沟通往往被轻描淡写地带过，但这本书却将其提升到了与算法同等重要的位置，指出所有技术决策的最终载体都是人。这种宏观的视角，帮助我跳出了纯粹的技术圈子，开始更全面地理解软件项目的生态系统。它的结构像是一座精心规划的城市，每一章都是一个功能完备的街区，它们之间又通过隐形的规划线索紧密相连。
评分这本书简直是思想的炼金炉，每一次翻阅都像是在和一位沉默却睿智的导师对话。作者的叙事方式极具感染力，他没有堆砌那些冷冰冰的专业术语，而是将那些抽象的工程哲学，用一个个生动的故事和恰到好处的比喻串联起来。我尤其欣赏他对“权衡”（Trade-offs）的深入剖析，那不是简单地告诉你A和B哪个好，而是细致地拆解了在特定情境下，每一种选择背后的代价和收益。读到关于系统设计那一部分时，我仿佛置身于一个巨大的、错综复杂的迷宫中，而作者就像手持火炬的向导，指引我辨认出那些隐藏的陷阱和通往清晰架构的捷径。他对于“渐进式改进”的强调，更是颠覆了我过去那种追求一步登天的想法，让人明白了软件的生命力在于持续的演化，而非一蹴而就的完美。这本书的深度在于，它让你反思的不是技术本身，而是你对“构建”这件事的态度和哲学根基。
评分与其说这是一本关于软件的书，不如说它是一本关于“制造”的书，它超越了具体的编程语言和框架限制，触及了所有创造性工作的核心。作者的写作风格如同一个经验丰富的老船长，在风浪中向新水手传授航海的智慧，既有对风险的警示，更有对稳定航行的期许。书中对于“一致性”的讨论，对我影响最为深远，它不仅仅指数据层面的一致，更延伸到了团队工作方式和设计理念上的一致性。这种深层次的统一，是任何优秀工程文化的基石。我发现，书中的很多观点，虽然是关于软件的，但完全可以移植到项目管理、乃至个人生活规划中去，显示了其极高的普适价值。它不提供即时见效的“灵丹妙药”，而是帮你构建一个稳固的认知框架，让你能够自我修正和持续成长。
评分这本书的结构非常巧妙，它仿佛遵循着一种螺旋上升的逻辑。它从最基础、最朴素的原则讲起，逐步推导出关于大型系统架构的复杂决策。我尤其欣赏作者对“简单性”的执着追求。在当前这个追求“酷炫技术栈”的时代，他旗帜鲜明地反对为了复杂而复杂，主张回归事物的本质。这就像是在喧嚣的市场中，有人为你提供了一块安静的基石。书中对重构和演化方法的讨论，不是提供僵硬的流程，而是提供了一套思维框架，让你能够根据实际情况灵活变通。我感觉作者是在教我们如何培养一种“工程直觉”，这种直觉是经验的结晶，无法通过死记硬背获得。读完之后，我手中的技术文档不再只是命令的集合，而更像是某种长期契约的体现。
评分坦白说，我原本对这类理论书籍抱持着一种敬而远之的态度，总觉得它们高高在上，与我日常面对的Bug和Deadline格格不入。然而，这本书以一种令人惊讶的接地气方式，彻底打消了我的疑虑。它的语言风格非常平实，甚至带着一丝幽默感，让你在会心一笑中，不知不觉就被引导到更深层次的思考。比如，他描述调试过程时，那种“仿佛在跟一个固执的幽灵搏斗”的场景，简直是每一个一线开发者的真实写照。这本书的价值不仅仅在于提供了解决方案，更在于它教会了我如何更优雅地面对困境。它不是一本教你写出特定语言代码的工具书，而是一本关于如何像一个成熟的工匠那样思考的指南。读完后，我发现自己看待代码库的眼光变了，不再只关注眼前的功能实现，而是开始审视其长期的可维护性和内在的逻辑美感。
评分感觉就是本论文集，不过内容不错，但是不太喜欢纸张
评分Making Software的中文翻译版，没啥意思
评分Making Software的中文翻译版，没啥意思
评分可有趣了。btw装了一个插件之后下面显示价格amazon果然业界良心不解释。
评分软件项目成功需要有理论功底，这就是你要的一本
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 book.quotespace.org All Rights Reserved. 小美书屋 版权所有