《Code Complete》ch.21 协同构建

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)

上一篇:POS Tagging 标签类型查询表(Penn Treebank Project)


下一篇:夺命雷公狗-----React---22--小案例之react经典案例todos(完成数据的遍历)