Code Inspection

从这个release开始,我所在的团队会对每一名developer的代码,也就是产品代码,在正式check-in之前进行code inspection。要求开发团队和peer test参加,人员控制在7-8名以内。我作为一名SDET,参加了我peer developer代码部分的inspection。一般分成三个阶段:

  1. Preparation meeting:代码的撰写者进行的准备会议,告诉inspector要看的代码在哪里,相对应的design spec地址。一般持续时间为15分钟。
  2. Offline inspecting:每一个inspector对代码进行审查。Code Inspection的速度,根据程序所使用的语言和所写功能的复杂程度不同而变化。对于我个人的这次code inspection,6个小时看了1900行程序。
  3. Collection meeting:统计代码缺陷的会议。这个会议中,最为重要的角色是Gatekeeper,一般由一名开发人员担任。Gatekeeper的职责有两个,一是对每个valid bug进行统计,一个是控制会议时间。在公司内部,我们使用excel文档作为载体,对所有的bug进行统计,同时进行数据分析。一般,统计项包括代码行数,个体/整体审查时间,平均阅读速度,总体缺陷数,主要缺陷数量,每千行代码缺陷个数等。

Code Inspection是Code Review的一种严格形式,常在敏捷开发模式中用到。敏捷开发主要强调交互性,包括团队成员内部的交互和外部用户之间的交互。强调交互性的实质是可以让产品中的问题尽早暴露出来,以便得到及时的更改:

Individuals and interactions over process and tools.

Working software over comprehensive document.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

 

我所在的团队中亦是采用敏捷开发的模式展开工作。主要有三点:

  1. 我们把整个开发流程划分几个小的迭代过程,在每一个迭代过程中,会制定清晰明确的milestone和deadline,几个迭代过程组合成了一个完整的产品周期。
  2. 我们每天会进行scrum meeting,时间原则是不超15分钟,在有issue需要团队讨论的时不超过30分钟。在这段时间中,团队中的每个人(SDE/SDET/PM)都会说今天的work item、每个Item所花费的时间以及遇到的各种问题,以方便进行讨论。
  3. 我们也会在正式check-in项目代码的之前,进行peer code review。

这些方式,都是我们一种个体交互的方式。其中,code review是团队内部成员之间互相学习和沟通的方式,尤其是可以找到一些代码的死角,便于及时修复。但是,code review,尤其是在项目时间安排紧张的时候,往往存在浮于表面、不够深入细致等问题。所以,我们引入了更为严格的code inspection机制。

 

Code Inspection同Code Review一样,都是对代码进行静态、人工审查的过程。和Code Review不一样的是,每个Inspector独立工作,对代码进行认真的审查,而不是简单略过。Code Inspection要求每个审查人员找出所有可能的代码问题,包括语句逻辑问题,设计问题,代码不清晰问题等等。一般,Code Inspection主要检查的问题有:

  • 代码是否实现了design spec中的所有功能
  • 代码是否存在逻辑错误
  • 代码是否调用不安全的类库
  • 代码是否规范,可以包括:变量命名
  • 代码中所有异常处理完备
  • 代码注释是否清晰、完整并且正确的描述了代码功能
  • 代码是否存在缺陷
  • 代码是否存在死循环
  • 代码是否存在潜在的性能问题
  • 等等

《代码大全》中有具体的业界统计数据:

代码测试行为找到的缺陷比例
Code Inspection45-70%
非正式代码审查20-40%
单元测试15-50%
系统测试25-55%

 

除了能够发现被审查的代码存在的问题之外,对于每个审查者,每次的审查过程即是认真阅读团队其他成员代码的过程,是一次良好的学习过程,可以发现漂亮的代码写法和合理的异常处理方式等。同时,因为有code inspection的压力,开发人员在撰写代码的过程中,也会注重代码可读性和正确性。这点,有点结对编程的感觉。

 

综上,code inspection可以发现代码潜在的问题,但是也需要花费团队成员大量的时间。所以,要根据项目和时间安排进行安排。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值