Procedure（走查步骤） 6. Walkthrough Procedure（走查步骤）
Participants 参与者 Entry Criteria 入口条件 Tasks 任务 The author selects the participants in a walkthrough. No specific roles are assigned.由创建者选择走查的参与者。不需要分配特定的角色。 o The author selected a walkthrough review approach for the product being reviewed.o 创建者为需要评审的工作产品选择了走查评审方法。o The author has stated his or her objectives for the review.o 创建者陈述了评审目标。 Task 任务 1. Select review participants, obtain their agreement to participate, and schedule a walkthrough meeting.选者评 Author 创建者 审参与者，确认他们同意参与评审，安排走查会议时间。 2. Distribute work product to reviewers prior to the meeting.在会议之前分发工作产品给评审者 3. Describe the work product to the reviewers during the meeting in any appropriate way. Lead discussion on the topics of interest or concerns about the work product. Author 创建者 在会议期间，以适当的方式向评审者描述工作产品。针对工作 产品中关心的或感兴趣的议题组织讨论。 4. Present comments, possible defects, and improvement suggestions to the author.向创建者表述评论，可能的缺陷，Reviewers 评审者 和改进建议。 5. Based on reviewer comments, perform any necessary rework of the work product.基于评审者的评论，对工作产品 Author 创建者 执行必要的返工 Deliverables 交付物 Verification 审核 Exit Criteria 出口条件 Modified work product 修改的工作产品 No verification of rework is required. Changes are made at the author’s discretion.不需要审核返工工作。根据创建者的判断进行修改。 o The author has made any appropriate changes in the work product.o 创建者 已经对工作产品做了恰当的修改。 Author 创建者 Responsible 责任人
走
查
目的
评估、提高工 作产品，教育参加 者 工作产品计划 中标识 架构、蓝图、 草稿 2～3 人 中等
入口 准则 时机 规模 评审 材料 准备 时间 主持

作者
人 变更 验证 成果 物 主持人验证返工 缺陷清单和度量 元总结 组长验证， 作为评审 报告的一部分 技术评审报告， 包括 缺陷清单以及行动计划 由其他的项目 控制手段执行 走查报告，缺 陷记录以及改进建 议
代码走查的最主要的目的是为了发现程序中的逻辑错误， 编程风格方面的错误可以通过 风格检查的工具去检查。 如下的检查单给代码走查的专家发现逻辑错误提供了一个很好的帮 助。 序号检查项
1、代码的注释与代码是否一致?注释是否是多余的? 2、是否存在超过 3 层嵌套的循环与/或判断? 3、变量的命名是否代表了其作用? 4、所有的循环边界是否正确? 5、所有的判断条件边界是否正确? 6、输入参数的异常是否处理了? 7、程序中所有的异常是否处理了? 8、是否存在重复的代码? 9、是否存在超过 20 行的方法? 10、是否存在超过 7 个方法的类? 11、方法的参数是否超过 3 个? 12、是否有多种原因导致修改某个类? 13、当发生某个功能变化时，是否需要修改多个类? 14、代码中的常量是否合适? 15、一个方法是否访问了其他类的多个属性? 16、某几项数据是否总是同时出现，而又不是一个类的属性? 17、switch 语句是否可以用类来替代? 18、是否有一类的职责很少? 19、是否有一个类的某些属性或者方法没有被其他类所使用? 20、在类的方法中是否存在如下的调用形式：a.b().c()? 21、是否某个类的方法总是调用另外一个类的同名方法? 22、是否某个类总是访问另外一个类的属性与方法? 23、是否两个类完成了类似的工作，使用了不同的方法名，却没有拥有同一个父类? 24、是否某个类仅有字段和简单的赋值方法与取值方法构成? 25、是否某个子类仅使用了父类的部分属性或方法?
种 类
正式评审 以比较详细的粒 度，定位并去除工作 产品中的缺陷 工作产品符合已 建立的准备准则 工作产品全部完 成 3～8 人 相对较少 3～5 天准备 专职主持人
技术审查 表明工作产品与规 约、 计划、 标准的符合性 或者变更被正确地执行 了 发布了评审目的， 工 作产品就绪， 作者准备好 完成独立的章节 3～5 人 中等或较多， 需要根 据评审的目的确定 2 天准备 小组长/组长
使用测试用例进行启发检测错误，沿程序逻辑走一遍，检查源代码是否符合开发规范，检测 程序结构和实现上是否有问题， 并逐步形成部门内部适用的公认的编码规范， 减少出错的概 率。通过介绍自己的代码和检查他人的代码，发现编码缺陷，以及好的编程方法，养成良好 的编程习惯。 参与人员：项目经理：把握协调整体情况 参与人员 需求管理员：关注需求，如检查代码是否符合需求 需求管理员 有经验的技术人员：主要关注代码本身，如检查代码是否符合规范、程序效率情况、是否存 有经验的技术人员 在缺陷等。 项目小组成员：关注模块之间的关联，如检查模块之间的关联是否符合要求、是否存在重复 项目小组成员 开发的情况、对同张表操作是否存在锁定情况等。并发现程序的缺陷和优点，。 1－2 个其他组开发人员（视项目大小来定）：从不同角度提出建议，互相吸取经验。 － 个其他组开发人员（视项目大小来定）
4.3.3 走查流程 走查对形式的要求更为简单，主要有下述两种方式。 （1）参与者驱动法：参与者按照事先准备好的列表，提出他们不理解的术语和认为不 ）参与者驱动法： 正确的术语。作者必须回答每个质疑，要么承认确实有错误，要么对质疑做出解释。 （2）文档驱动法：作者向评审人仔细解释文档（或代码）。在此过程中，可以将评审 ）文档驱动法： 的内容（如关键代码、架构图、业务逻辑图等）用投影仪投射到屏幕上，作者对工作产品进 行讲解， 评审人不时针对事先准备好的问题或解释过程中发现的问题提出质疑。 它比参与者 驱动法可能更有效，往往能检查出更多错误。经验表明，使用文档驱动法时许多错误是由文 档讲解者自己发现的。 在走查过程中， 每个评审人都要记录错误或建议， 会后要整理会议记录， 作为走查报告。 工作产品的作者可以根据自己的思路对走查报告质疑。 注： 对代码的同行评审其实就是代码走查， 可以使用投影仪打出关键代码位置与参与人 员一起读， 也可以几个开发人员一起进行交叉走查。 选定的进行代码走查的范围根据需求的 优先级来具体确定。