软件之道：软件开发争议问题剖析
软件之道：软件开发争议问题剖析
Andy Oram, Greg Wilson 编著
鲍央舟 张玳 沈欢星 译
出版时间：2012年02月
页数：438
“虽然我们自称是‘工程师’，然而编程过程并非机械地由数据驱动，而是更多地取决于编程人员的感受。以软件开发的大量经验性数据为基础，编程过程完全可以达到个性化与系统化的
统一。”
——Jason Cohen，Smart Bear和WPEngine公司创始人

相信大家常常听说某些工具、技术和实践方法可以改进软件开发，但其中哪些说法是可被证实的，哪些仅仅是人们一厢情愿的想法？本书收录了Steve McConnell、Barry Boehm和Barbara Kitchenham等几十位软件工程领域顶尖研究人员的文章，深入讨论了软件开发社区中常见的一些观点，一些是确凿事实，一些则是荒诞说法。他们的深刻见解定会让你大开眼界。

· 某些编程人员的工作成效果真是他人十倍之多？
· 测试驱动的开发果真能帮助更快、更好地开发代码？
· 软件的bug数量果真可以利用代码度量进行预测？
· 设计模式果真有助于构建更好的应用程序？
· 人员个性会对结对编程产生何种影响？
· 地理位置的距离和公司职位的差距，究竟何者影响更大？
  1. 第一部分 　搜寻和使用证据的一般原则
  2. 第1章　 探寻有力的证据　　
  3. 1.1　 起步阶段　　
  4. 1.2　 当今证据的状态　　
  5. 1.2.1 　精确性研究的挑战　　
  6. 1.2.2　 统计强度的挑战　　
  7. 1.2.3　 结果可复制性的挑战　　
  8. 1.3　 我们可以相信的改变　　
  9. 1.4　 背景的影响　　
  10. 1.5　 展望未来　　
  11. 1.6　 参考文献　　
  12. 第2章 　可信度，为什么我坚决要求确信的证据
  13. 2.1 　软件工程中的证据是如何发现的
  14. 2.2　 可信度和适用性
  15. 2.2.1 　适用性，为什么使你信服的证据不能使我信服
  16. 2.2.2 　定性证据对战定量证据：错误的二分法
  17. 2.3　 整合证据
  18. 2.4　 证据的类型以及它们的优缺点
  19. 2.4.1 　对照实验和准实验
  20. .2.4.2　 问卷调查
  21. 2.4.3　 经验汇报和案例研究
  22. 2.4.4　 其他方法
  23. 2.4.5　 报告中的可信度（或缺乏可信度）的标识
  24. 2.5　 社会、文化、软件工程和你
  25. 2.6　 致谢
  26. 2.7　 参考文献
  27. 第3章 　我们能从系统性评审中学到什么　　
  28. 3.1 　系统性评审总览
  29. 3.2　 系统性评审的长处和短处
  30. 3.2.1 　系统性评审的流程
  31. 3.2.2　 开展一项评审所牵连的问题
  32. 3.3　 软件工程中的系统性评审
  33. 3.3.1 　成本估算研究
  34. 3.3.2　 敏捷方法
  35. 3.3.3　 检验方法
  36. 3.4　 结论
  37. 3.5　 参考文献
  38. 第4章　 用定性研究方法来理解软件工程学
  39. 4.1　 何为定性研究方法
  40. 4.2　 如何解读定性研究
  41. 4.3　 在工作中运用定性研究方法
  42. 4.4　 推广应用定性研究的结果
  43. 4.5　 定性研究方法是系统的研究方法
  44. 4.6　 参考文献
  45. 第5章 　在实践中学习成长：软件工程实验室中的质量改进范式
  46. 5.1 　软件工程研究独有的困难之处
  47. 5.2　 实证研究的现实之路
  48. 5.3　 nasa软件工程实验室：一个充满活力的实证研究测试平台
  49. 5.4　 质量改进范式
  50. 5.4.1 　表征
  51. 5.4.2 　设立目标
  52. 5.4.3 　选择流程
  53. 5.4.4 　执行流程
  54. 5.4.5 　分析
  55. 5.4.6 　封装
  56. 5.5　 结论
  57. 5.6　 参考文献
  58. 第6章 　性格、智力和专业技能对软件开发的影响
  59. 6.1 　如何辨别优秀的程序员
  60. 6.1.1 　个体差异：固定的还是可塑造的　　
  61. 6.1.2　 个性
  62. 6.1.3　 智力
  63. 6.1.4　 编程任务
  64. 6.1.5　 编程表现
  65. 6.1.6　 专业技能
  66. 6.1.7　 软件工作量估算
  67. 6.2　 环境因素还是个人因素
  68. 6.2.1 　软件工程中应该提高技能还是提高安全保障
  69. 6.2.2 　合作
  70. 6.2.3 　再谈个性
  71. 6.2.4 　从更广的角度看待智力
  72. 6.3　 结束语
  73. 6.4　 参考文献
  74. 第7章 　为什么学编程这么难
  75. 7.1 　学生学习编程有困难吗
  76. 7.1.1 　2001年mccracken工作小组
  77. 7.1.2 　lister工作小组
  78. 7.2　 人们对编程的本能理解是什么
  79. 7.3　 通过可视化编程来优化工具
  80. 7.4　 融入语境后的改变
  81. 7.5　 总结：一个新兴的领域
  82. 7.6　 参考文献
  83. 第8章 　超越代码行：我们还需要其他的复杂度指标吗
  84. 8.1 　对软件的调查
  85. 8.2　 计算源代码的指标
  86. 8.3　 指标计算案例
  87. 8.3.1 　源代码行数（sloc）
  88. 8.3.2 　代码行数（loc）
  89. 8.3.3 　c函数的数量
  90. 8.3.4 　mccabe圈复杂度
  91. 8.3.5 　halstead软件科学指标
  92. 8.4　 统计分析
  93. 8.4.1 　总体分析
  94. 8.4.2 　头文件和非头文件之间的区别
  95. 8.4.3 　干扰效应：文件大小对相关性的影响
  96. 8.5　 关于统计学方法的一些说明
  97. 8.6　 还需要其他的复杂度指标吗
  98. 8.7　 参考文献
  99. 第二部分 　软件工程的特有话题
  100. 第9章　 自动故障预报系统实例一则
  101. 9.1　 故障的分布
  102. 9.2　 故障高发文件的特征
  103. 9.3　 预测模型概览
  104. 9.4　 预测模型的复验和变体
  105. 9.4.1 　开发人员的角色
  106. 9.4.2　 用其他类型的模型来预测故障
  107. 9.5　 工具的设计
  108. 9.6　 一些忠告
  109. 9.7　 参考文献
  110. 第10章 　架构设计的程度和时机
  111. 10.1 　修正缺陷的成本是否会随着项目的进行而增加
  112. 10.2 　架构设计应该做到什么程度
  113. 10.3 　架构设计的成本—修复数据给予我们的启示
  114. 10.3.1 　关于cocomo ii架构设计和风险解决系数的基础知识
  115. 10.3.2 　ada cocomo及cocomo ii中的架构设计以及风险应对系数
  116. 10.3.3　 用于改善系统设计的投入的roi　　
  117. 10.4　 那么到底架构要做到什么程度才够
  118. 10.5　 架构设计是否必须提前做好
  119. 10.6　 总结
  120. 10.7　 参考文献
  121. 第11章 　康威推论
  122. 11.1 　康威定律
  123. 11.2 　协调工作、和谐度和效率
  124. 11.3 　微软公司的组织复杂度
  125. 11.4 　开源软件集市上的小教堂
  126. 11.5 　总结
  127. 11.6 　参考文献
  128. 第12章 　测试驱动开发的效果如何
  129. 12.1　 tdd药丸是什么
  130. 12.2　 tdd临床试验概要
  131. 12.3　 tdd的效力
  132. 12.3.1 　内部质量
  133. 12.3.2 　外部质量
  134. 12.3.3　 生产力
  135. 12.3.4 　测试质量
  136. 12.4　 在试验中强制tdd的正确剂量
  137. 12.5　 警告和副作用
  138. 12.6　 结论
  139. 12.7　 致谢
  140. 12.8　 参考文献
  141. 第13章 　为何计算机科学领域的女性不多
  142. 13.1 　为什么女性很少
  143. 13.1.1 　能力缺陷，个人喜好以及文化偏见
  144. 13.1.2 　偏见、成见和男性计算机科学文化
  145. 13.2　 值得在意吗
  146. 13.2.1 　扭转这种趋势，我们可以做些什么
  147. 13.2.2 　跨国数据的意义
  148. 13.3　 结论
  149. 13.4　 参考文献
  150. 第14章 　两个关于编程语言的比较
  151. 14.1 　一个搜索算法决定了一种语言的胜出
  152. 14.1.1 　编程任务：电话编码
  153. 14.1.2 　比较执行速度
  154. 14.1.3 　内存使用情况的比较
  155. 14.1.4 　比较效率和代码长度
  156. 14.1.5 　比较可靠性
  157. 14.1.6 　比较程序结构
  158. 14.1.7 　我可以相信吗
  159. 14.2　 plat_forms：网络开发技术和文化
  160. 14.2.1 　开发任务：人以类聚
  161. 14.2.2 　下注吧
  162. 14.2.3 　比较工作效率
  163. 14.2.4 　比较软件工件的大小
  164. 14.2.5 　比较可修改性
  165. 14.2.6 　比较稳健性和安全性
  166. 14.2.7 　嘿，“插入你自己的话题”如何　　
  167. 14.3　 那又怎样
  168. 14.4　 参考文献
  169. 第15章 　质量之战：开源软件对战专有软件
  170. 15.1 　以往的冲突
  171. 15.2 　战场
  172. 15.3 　开战
  173. 15.3.1 　文件组织
  174. 15.3.2 　代码结构
  175. 15.3.3 　代码风格
  176. 15.3.4 　预处理
  177. 15.3.5 　数据组织
  178. 15.4　 成果和结论
  179. 15.5　 致谢
  180. 15.6　 参考文献
  181. 第16章 　码语者
  182. 16.1 程序员的一天
  183. 16.1.1　 日记研究
  184. 16.1.2　 观察研究
  185. 16.1.3　 程序员们是不是在挣表现
  186. 16.2　 说这么多有什么意义
  187. 16.2.1　 问问题
  188. 16.2.2　 探寻设计理念
  189. 16.2.3　 工作的中断和多任务
  190. 16.2.4　 程序员都在问什么问题
  191. 16.2.5　 使用敏捷方法是不是更利于沟通　　
  192. 16.3　 如何看待沟通
  193. 16.4　 参考文献
  194. 第17章　 结对编程
  195. 17.1　 结对编程的历史
  196. 17.2　 产业环境中的结对编程
  197. 17.2.1 　 结对编程的行业实践
  198. 17.2.2　 业内使用结对编程的效果
  199. 17.3　 教育环境中的结对编程
  200. 17.3.1 　教学中特有的实践
  201. 17.3.2　 教学中使用结对编程的效果
  202. 17.4　 分布式结对编程
  203. 17.5　 面对的挑战
  204. 17.6　 经验教训
  205. 17.7　 致谢
  206. 17.8　 参考文献
  207. 第18章　 现代化代码审查
  208. 18.1　 常识
  209. 18.2　 程序员独立进行小量代码审查
  210. 18.2.1 　防止注意力疲劳
  211. 18.2.2 　切忌速度过快
  212. 18.2.3 　切忌数量过大
  213. 18.2.4 　上下文的重要性
  214. 18.3　 团队影响
  215. 18.3.1 　是否有必要开会
  216. 18.3.2 　虚假缺陷
  217. 18.3.3 　外部审查真的需要吗
  218. 18.4　 结论
  219. 18.5　 参考文献
  220. 第19章 　公共办公室还是私人办公室
  221. 19.1 　私人办公室
  222. 19.2 　公共办公室
  223. 19.3 　工作模式
  224. 19.4 　最后的忠告
  225. 19.5 　参考文献
  226. 第20章 　识别及管理全球性软件开发中的依赖关系
  227. 20.1 　为什么协调工作对于gsd来说是挑战
  228. 20.2 　依赖关系及其社会/技术二重性　　
  229. 20.2.1 　技术方面
  230. 20.2.2 　社会/组织结构方面
  231. 20.2.3 　社会—技术方面
  232. 20.3　 从研究到实践
  233. 20.3.1 　充分使用软件储存库中的数据　　
  234. 20.3.2 　团队领导和管理者在依赖关系管理中的角色
  235. 20.3.3 　开发人员、工作项目和分布式开发
  236. 20.4　 未来的方向
  237. 20.4.1 　适合gsd的软件架构
  238. 20.4.2 　协作软件工程工具
  239. 20.4.3 　标准化和灵活度的平衡
  240. 20.5　 参考文献
  241. 第21章 　模块化的效果如何
  242. 21.1 　所分析的软件系统
  243. 21.2 　如何定义“修改”
  244. 21.3 　如何定义“模块”
  245. 21.4 　研究结果
  246. 21.4.1 　修改的范围
  247. 21.4.2 　需要参考的模块
  248. 21.4.3 　自发式的模块化
  249. 21.5　 有效性的问题
  250. 21.6　 总结
  251. 21.7　 参考文献
  252. 第22章 　设计模式的证据
  253. 22.1 　设计模式的例子
  254. 22.2　 为什么认为设计模式可行
  255. 22.3　 第一个实验：关于设计模式文档的测试
  256. 22.3.1 　实验的设计
  257. 22.3.2 　研究结果
  258. 22.4　 第二个实验：基于设计模式的解决方案和简单解决方案的对比
  259. 22.5　 第三个试验：设计模式之于团队沟通
  260. 22.6 　经验教训
  261. 22.7　 总结
  262. 22.8　 致谢
  263. 22.9　 参考文献
  264. 第23章 　循证故障预测
  265. 23.1　 简介
  266. 23.2　 代码覆盖率
  267. 23.3　 代码变动
  268. 23.4　 代码复杂度
  269. 23.5　 代码依赖
  270. 23.6　 人与组织度量
  271. 23.7　 预测缺陷的综合方法
  272. 23.8　 结论
  273. 23.9　 致谢
  274. 23.10 　参考文献
  275. 第24章 　采集缺陷报告的艺术
  276. 24.1 　缺陷报告的优劣之分
  277. 24.2　 优秀缺陷报告需要具备的要素
  278. 24.3　 调查结果
  279. 24.3.1 　开发人员眼中的缺陷报告内容　　
  280. 24.3.2 　报告者眼中的缺陷报告内容
  281. 24.4　 来自不一致信息的证据
  282. 24.5　 缺陷报告的问题
  283. 24.6　 重复缺陷报告的价值
  284. 24.7　 并非所有的缺陷都被修复了
  285. 24.8　 结论
  286. 24.9　 致谢
  287. 24.10 　参考文献
  288. 第25章 　软件的缺陷都从哪儿来
  289. 25.1 　研究软件的缺陷
  290. 25.2 　本次研究的环境和背景
  291. 25.3 　第一阶段：总体调查
  292. 25.3.1 　调查问卷
  293. 25.3.2 　数据的总结　　
  294. 25.3.3 　第一部分的研究总结
  295. 25.4　 第二阶段：设计/代码编写类故障调查
  296. 25.4.1 　调查问卷
  297. 25.4.2　 统计分析
  298. 25.4.3　 界面故障与实现故障
  299. 25.5　 研究结果可靠吗
  300. 25.5.1 　我们调查的对象是否正确
  301. 25.5.2 　我们的方法是否正确
  302. 25.5.3 　我们能用这些结果做什么
  303. 25.6　 我们明白了什么
  304. 25.7　 致谢
  305. 25.8　 参考文献
  306. 第26章 　新手专家：软件行业的应届毕业生们
  307. 26.1 　研究方法
  308. 26.1.1 　研究对象
  309. 26.1.2　 任务分析
  310. 26.1.3　 任务案例
  311. 26.1.4　 做回顾的方法
  312. 26.1.5　 有效性问题
  313. 26.2 　软件开发任务
  314. 26.3　 新手开发人员的优点和缺点
  315. 26.3.1 　优点分析
  316. 26.3.2　 缺点分析
  317. 26.4　 回顾
  318. 26.4.1　 管理层的介入
  319. 26.4.2　 毅力、疑惑和新人特质
  320. 26.4.3　 大型的软件团队环境
  321. 26.5　 妨碍学习的误解
  322. 26.6　 教育方法的反思
  323. 26.6.1 　结对编程
  324. 26.6.2　 合理的边际参与
  325. 26.6.3　 导师制
  326. 26.7　 改变的意义
  327. 26.7.1 　新人培训
  328. 26.7.2 　学校教育
  329. 26.8　 参考文献
  330. 第27章 　挖掘你自己的证据
  331. 27.1 　对什么进行数据挖掘
  332. 27.2 　设计你的研究
  333. 27.3 　数据挖掘入门
  334. 27.3.1 　第一步：确定要用哪些数据
  335. 27.3.2　 第二步：获取数据
  336. 27.3.3　 第三步：数据转换（可选）
  337. 27.3.4　 第四步：提取数据
  338. 27.3.5　 第五步：解析bug报告
  339. 27.3.6　 第六步：关联数据
  340. 27.3.7　 第六步：找出漏掉的关联
  341. 27.3.8　 第七步：将bug对应到文件
  342. 27.4　 下面怎么办
  343. 27.5　 致谢
  344. 27.6　 参考文献
  345. 第28章 　正当使用“复制—粘贴”大法　　
  346. 28.1　 代码克隆的示例
  347. 28.2　 寻找软件中的克隆代码
  348. 28.3　 对代码克隆行为的调查
  349. 28.3.1 　分叉
  350. 28.3.2 　模板
  351. 28.3.3 　定制
  352. 28.4　 我们的研究
  353. 28.5　 总结
  354. 28.6　 参考文献
  355. 第29章 　你的api有多好用
  356. 29.1 　为什么研究api的易用性很重要　　
  357. 29.2 　研究api易用性的首次尝试
  358. 29.2.1 　研究的设计
  359. 29.2.2 　第一次研究的结论摘要
  360. 29.3　 如果一开始你没有成功
  361. 29.3.1 　第二次研究的设计
  362. 29.3.2 　第二次研究的结论摘要
  363. 29.3.3 　认知维度
  364. 29.4　 使用不同的工作风格
  365. 29.5　 结论
  366. 29.6　 参考文献
  367. 第30章 “10倍”意味着什么？编程生产力的差距测量
  368. 30.1　 软件开发中的个人效率的变化
  369. 30.1.1 　巨大的差距带来的负面影响
  370. 30.1.2　 什么造就了真正的“10倍程序员”
  371. 30.2　 测量程序员的个人生产力的问题　　
  372. 30.2.1 　生产力=每月产出的代码行数吗　　
  373. 30.2.2 　生产力=功能点吗
  374. 30.2.3　 复杂度呢
  375. 30.2.4　 到底有没有办法可以测量个人生产力
  376. 30.3　 软件开发中的团队生产力差距
  377. 30.4　 参考文献
  378. 撰稿人
书名：软件之道：软件开发争议问题剖析
作者：Andy Oram, Greg Wilson 编著
译者：鲍央舟 张玳 沈欢星 译
国内出版社：人民邮电出版社
出版时间：2012年02月
页数：438
书号：978-7-115-27044-3
原版书书名：Making Software
原版书出版商：O'Reilly Media
Andy Oram
 
Andy Oram是O'Reilly Media的编辑。他从1992年开始就在这家公司工作，Andy目前主要关注自由软件和开源技术。他在O'Reilly的工作成果包括第一批Linux系列丛书以及2001年的P2P系列丛书。他的编程技术和系统管理技术大多都是自学的。Andy还是Computer Professionals for Social Responsibility协会的成员并且经常在O'Reilly Network(http://oreillynet.com)和其他一些刊物上撰写文章，这些文章的主题包括互联网上的政策问题，以及影响技术创新的潮流及其对社会的影响。他的网址为http://www.praxagora.com/andyo。
 
 
Greg Wilson
 
Greg Wilson在爱丁堡大学获得了计算机科学博士学位，他的研究领域包括高性能科学计算，数据虚拟化以及计算机安全。他现在是多伦多大学计算机科学系的一位副教授，并且是《Dr. Dobb's Journal》杂志的特约编辑。
 
 
购买选项
定价：89.00元
书号：978-7-115-27044-3
出版社：人民邮电出版社
联系出版社邮购

© 2024，奥莱利技术咨询(北京)有限公司。版权所有。
传真: +86-10-88097463
 京ICP备05003502号