从这个release开始,我所在的团队会对每一名developer的代码,也就是产品代码,在正式check-in之前进行code inspection。要求开发团队和peer test参加,人员控制在7-8名以内。我作为一名SDET,参加了我peer developer代码部分的inspection。一般分成三个阶段:
- Preparation meeting:代码的撰写者进行的准备会议,告诉inspector要看的代码在哪里,相对应的design spec地址。一般持续时间为15分钟。
- Offline inspecting:每一个inspector对代码进行审查。Code Inspection的速度,根据程序所使用的语言和所写功能的复杂程度不同而变化。对于我个人的这次code inspection,6个小时看了1900行程序。
- 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.
我所在的团队中亦是采用敏捷开发的模式展开工作。主要有三点:
- 我们把整个开发流程划分几个小的迭代过程,在每一个迭代过程中,会制定清晰明确的milestone和deadline,几个迭代过程组合成了一个完整的产品周期。
- 我们每天会进行scrum meeting,时间原则是不超15分钟,在有issue需要团队讨论的时不超过30分钟。在这段时间中,团队中的每个人(SDE/SDET/PM)都会说今天的work item、每个Item所花费的时间以及遇到的各种问题,以方便进行讨论。
- 我们也会在正式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 Inspection | 45-70% |
非正式代码审查 | 20-40% |
单元测试 | 15-50% |
系统测试 | 25-55% |
除了能够发现被审查的代码存在的问题之外,对于每个审查者,每次的审查过程即是认真阅读团队其他成员代码的过程,是一次良好的学习过程,可以发现漂亮的代码写法和合理的异常处理方式等。同时,因为有code inspection的压力,开发人员在撰写代码的过程中,也会注重代码可读性和正确性。这点,有点结对编程的感觉。
综上,code inspection可以发现代码潜在的问题,但是也需要花费团队成员大量的时间。所以,要根据项目和时间安排进行安排。