蛙蛙推荐：代码大全第20，21，30章摘抄，软件质量概述，代码复查，结对编程及个人性格

第20章 软件质量概述 

大部分研究都发现，检测比测试的成本更小。NASA软件工程实验室的一项研究发现，阅读代码每小时能够检测出来的缺陷要比测试高出80%左右(Basili and Selby 1987)。后来，IBM的一项研究又发现，检查发现的一个错误只需要3.5个工作时，而测试则需要花费15-25个工作时（Kaplan 1995)。

　　微软的应用程序部门发现，用代码检查这种一步到位的方法找出并修正一个错误要花费3个工作时，而通过测试这种两步完成的方法则要花费12个工作时（Moore 1992）。

　　Collofello和Woodfield报告称，在一个由超过400名程序员创建的70万行代码的程序中，代码复查(review)的成本效益要比测试高出几倍前者的投资回报率是1.38，而后者只有0.17。

第21章摘抄-协同构建

代码复查的重要性

CMU软件工程研究所(Software engineering Instiute)的调查表明，在软件设计过程中开发人员平均每小时会引入1到3个缺陷，在编码阶段则会平均每小时引入5到8个(Humphrey, 1997年)，因此攻击这些盲点就成为了有效构建的关键。　　软件测试在单独运用的时候效果比较有限，单元测试的平均缺陷检出率只有大约30%，集成测试大约是35%，小规模的Beta测试是35%。与此相反，对设计和代码进行详细检查的平均效能为55%和60%(Jones 1996)。协同构建的另一个好处是，它可以缩短开发周期，从而降低开发成本。

　　关于技术性复查的研究

1. IBM发现，一小时的代码检查能够节约大约100小时的相关工作（测试和缺陷修正）（Holland 1999)。
2. 通过一个关注检测工作的创意，Raytheon将修成缺陷的成本占项目总成本的比例，从约40%降至20%(Haley 1996)。
3. 惠普公司报告称，它的正式检查计划大约每年会为公司节省2150万美元（Grady and Van Slack 1994）。
4. 帝国化工(Imperial Chemical Industries)发现维护400个程序所有文档的费用，仅仅是维护与之类似但未经检查的程序的费用的十分之一。
5. 对一些大型程序的一项研究发现，在正式检查上面花一个小时，平均可以避免33个小时的维护工作，并且检查的效能是测试的20倍以上（Russell 1991）。
6. 在引入代码复查之前，一个软件维护组织的55%的单行修改是有错误的。而引入代码复查之后，这一数字降低到了2%(Freedman and Weinberg 1990)。如果考虑所有类型的变更，在引入复查之后的95%的修正是一次性正确的，而没有引入复查时只有20%是一次性正确的。
7. 同一组开发人员开发了11个程序，并将他们发布到产品当中。其中前5个没有进行复查，其平均每百行代码存在4.5个错误。另外6个经过了代码检查，平均每百行代码只有0.82个错误。复查消灭了超过80%的错误(Freedman and Weinberg 1990)。
8. Capers Jones的报告称，他所研究过的所有排错率达到或者超过99%的项目，都采用了正式的代码检查。同样的，排错率低于75%的项目都未采用正式的代码检查（Jones 2000）。

　　这些例子阐释了软件质量的普遍原理，该原理告诉我们，在减少软件中缺陷数量的同事，开发周期也能得到缩短。

　　各种不同的研究表明，协同开发不但在捕获错误方面比测试的效能更高，所能发现的错误类型也不同于测试(Myers 1978;Basili,Selby and Hutchens 1986)。正如Karl Wiegers所指出的那样，“由人进行的复查能够发现不明显的错误信息，不恰当的主持，硬编码的变量值，以及重复出现的需要进行统一的代码模式，这些是测试发现不了的”（Wiegers 2002）。

结对编程的几条准则

虽然结对编程的基本概念很简单，但要从中获得收益，就要遵循下述几条准则。

1. 用编码规范来支持结对编程：如果两个人整天把时间浪费在争论代码风格问题上，那么结对编程就不可能发挥它的威力。应该尝试对风格进行标准化，在第五章“构建期间进行设计”里面将其称为“偶然属性”，以便程序员集中精力到“本质”任务上。
2. 不要让结对编程编程旁观：不掌握键盘的那个人应该主动参与到编程当中，他应该分析代码，提前思考接下来的代码应该做什么，对设计进行评估，并对如何测试代码做出计划。
3. 不要强迫在简单的问题上使用结对编程：一个运用结对编程来解决最复杂问题的小组发现，如果一起在白板上面画15分钟，然后再分别独立编程会更有利（Manzo 2002)。绝大多数尝试过结对编程的组织最终都是对部分工作采用结对编程，而不是全部（Boehm and Turner 2004)。
4. 有规律地对结对人员和份和分配的工作任务进行轮换：如同在其他的协同开发实践一样，结对编程的好处在于能够让不同的人熟悉系统的不同部分。有规律的进行轮换有助于知识的互相传播--有些专家建议尽可能的进行人员轮换，甚至每天进行（Reifer 2002）。
5. 鼓励双方跟上对方的步伐：要是其中一个人相对走得太快的话，那就会大大限制了其结对搭档的作用。速度太快的人需要放慢步伐，否则这对组合应该被拆开，然后和其他人重新组合。
6. 确认两个人都能够看到显示器：即使无法看到显示器，使用了太小的字体等细枝末节，都可能造成问题。
7. 不要强迫程序员与自己关系紧张的人组队：有时个人性格之间的冲突会导致组合效能出问题，强迫无法配对的两个人进行组合是毫无意义的，因此请对个性匹配的问题保持警惕(Bcck 2000,Reifer 2002)。
8. 避免新手组合：两个人当中至少一个有结对经历时，结对编程的效果最好(Larman 2004)。
9. 指定一个组长：即使你的整个队伍希望所有工作都通过结对编程的方法来做，你还是需要指定一个人来协调工作的分配，对结果负责以及负责与项目外的其它人的联系。

结对编程的好处

1. 与单独开发相比，结对能够使人们在压力之下保持更好的状态。结对编程鼓励双方保持代码的高质量，即使在出现了让人不得不飞快地写代码的压力下仍然如此。
2. 他能够改善代码质量。代码的可读性和可理解性都倾向于上升至团队中最优秀程序员的水平。
3. 他能缩短进度时间表。结对往往能够更快的编写代码，代码错误也更少。这样一来，项目组在项目后期花费在修复缺陷的时间会更少。
4. 它还具有协同构建的其他常见好处，包括传播公司文化，指导初级程序员，以及培养集体归属感。

关于正式检查

1. 详查表关注的是复查者过去遇到的所有的问题。
2. 详查专注于缺陷的检测，而非修正。
3. 复查人员要为详查会议做好预先准备，并且带来一份他们所发现的已知问题列表。
4. 参与者都被赋予了明确的角色。
5. 详查的主持人不是被检查产品的作者。
6. 详查的主持人应该已经接受过主持详查会议方面的培训。
7. 只有在与会者都做好充分准备之后才会召开详查会议。
8. 每次详查所收集的数据都会被应用到以后的详查当中，以便对详查进行改进。
9. 高层管理人员不参加详查会议，除非你们正在详查一个项目的计划，或者其它管理方面的资料。但技术负责人可能参加。
10. 无论在任何情况下，详查的结果都不应当作为员工表现的评估标准，这种杀鸡取卵的行为不可取。在详查中被检验的代码仍处于开发阶段。对员工表现的评估应当基于最终产品，而不是尚未完成的工作。

第33章 个人性格

编程活动非常好用脑力，这种特性使得个人性格显得重要。人们都知道聚精会神地一天工作八个小时有多么困难！也许你有过某天精力过分集中，以至于第二天无精打彩的体会。你可能某天从上午8点工作到下午2点，就感到累的不行了。但你还是坚持了下来，又从下午2点拼命感到下午5点。之后一周的时间，你却在修改者三小时里写出来的东西。

　　老板无法强迫你成为好的程序员，很多时候他甚至无法判断你是否合格。如果你想有所成就，只能全凭自己。

　　大多数程序员一年下来还看不完一本书，只要稍稍看一些书就会使你的专业知识又迈进一步。如果每两个月能看一本计算机好书，大约每周35页，过不了多久，你就能把握本行业的脉搏，并脱颖而出。

　　依据我的经验，有人之所以写出难以看懂的代码，主要还是因为其代码质量太差，他们不会自言自语道：“我的代码不好，所以我得让他们不好懂。”他们只是没有了解透所写的代码，自然无法使之易读。