WHAT?

所有的协同构建技术都试图通过这样那样的途径，将展示工作的过程正式化，以便将错误暴露出来

WHY?

• 提高缺陷检出率，从而缩短开发周期，降低开发成本
• 发现不明显的错误信息，如不恰当的注释、硬编码的变量值、重复出现需要统一的代码模式——这些是测试所发现不了的
• 让人们知道他们的代码将要被复查，这样他们会小心谨慎检查自己的工作
• 提供技术交流平台，提升开发者水平

HOW?

结对编程

• 用编码规范来支撑编程
• 不要让结对编程变成旁观
• 不要强迫在简单的问题上使用结对编程
• 有规律地对结对人员和分配的工作任务进行轮换
• 鼓励双方跟上对方的步伐
• 确认两个人都能看得清显示器
• 不要强迫程序员与关系紧张的人结对
• 避免新手组合
• 指定一个组长

正式检查（详查）

独立的详查通常能捕捉到60%的缺陷——比除了原型和大规模beta测试之外的其他技术都要好

对设计和代码都进行详查的项目，详查通常会占到项目预算的10%～15%

详查中的角色

• 主持人：保证详查以特定的速度进行，使其既能保证效率，又能发现尽可能多的错误。主持人在技术上必须能够胜任，负责管理详查的其他方面，例如分派任务、分发核对表、预订会议室、报告详查结果、跟踪详查会议产生的决议
• 作者：代码编写人，负责让代码被清晰的理解（虽然这应该在编码时就应该尽力做到），解释那些看起来有错的地方为什么是对的
• 评论员：同设计和代码有直接关系，但又不是作者的人（注意分词，别想歪）。可以是程序员、测试人员、架构师，通常在详查会议做准备的时候就找出了若干缺陷，随着会议的进行与讨论，他们应该有更多的疑问提出
• 记录员：记录详查期间提出的错误，记录指派的任务。作者和主持人都不应当兼职记录员
• 经理：让他参加这样一个纯技术的会议并不是个好主意，因为他什么都不懂却什么都要插一腿。不过经理有权知道详查会议的结果——需要有一份详查报告

详查会议的结果不因该作为员工表现的评定标准——对员工表现的界定应该基于最终产品，而并非开发阶段的代码

详查的目的是找出缺陷，而不是探索替代方案，或者争论谁对谁错。详查会议不应该让作者觉得团队中的某一个人是白痴，或者产生另谋高就的想法

核对表用来记录曾经发现的问题，应该随着时间进行积累

详查的一般步骤

• 计划：作者将设计或代码提交给主持人，主持人决定哪些人复查这些材料，决定会议时间地点，将设计、代码、核对表分发给参与会议的各人
• 概述：作者向评论员描述设计或代码的技术背景——这些更多地需要在代码中通过自说明的形式来做，而不是现场解说
• 准备：每一个评论员独立地对设计或代码进行详查，找出其中的错误，评论员使用核对表来激励和指导他们的详查。最高效详查速度的变化范围可能很大，因此要保留所在组织的详查速度记录，以便确定所在环境的最高效详查速度
• 详查会议：主持人挑选出除作者外的某个人对设计和代码进行阐释，所有逻辑（每个分支）都要解释。所有的讨论应该在确认这是一个错误的时候停止（不应深入到解决方案层次）。系统级代码90行/h，应用程序代码500行/h，每小时150～200行非空注释的代码是个不错的开始。通常会议不会超过2h，一天进行一次以上的详查会议也是不合理的
• 详查报告：主持人撰写，列出每一个缺陷，包括它的类型和严重级别。应当对每次详查会议的时间与发现错误进行记录，客观数据更具有说服力
• 返工：主持人将缺陷交由某人修复——通常是作者
• 跟进：主持人负责监督缺陷的修复进度
• 第三个小时的会议：若有人对解决方案有兴趣，可以组织一个非正式的讨论会议

走查（walk-throughs）

走查通常涉及两个或更多的人，进行设计或代码的相关讨论，可以是白板前的一段随意探讨，也可以是在会议室中有着丰富ppt的讨论

走查通常持续30～60min

相较与详查，走查更为随意，效率也更低

代码阅读（code reading）

通常有两到三人参与，阅读人员独立阅读代码，然后与作者进行讨论，总结出设计／代码缺陷

应该至少有两个人阅读代码，用以鼓励评论员之间的竞争

阅读速度估计每天1000行代码

其实是简化的复查会议——90%的错误是在复查会议的准备阶段发现的，只有10%是在复查会议中被提出

公开展示（Dog-and-Pony Shows）

目的是向客户展示一切顺利（all is well）