《代码走查》杂记

代码走查

一、定义 

 

2 代码走查(code walkthrough)和代码审查(code inspection)是两种不同的代码评审方法,代码审查是一种正式的评审活动，而代码走查的讨论过程是非正式的。

 

3 从定义上来讲，代码走查是以小组为单元进行代码阅读的，同样也是一系列规程和错误检查技术的集合。且代码走查也采用了持续一至两个小时的不间断会议的形式。代码走查的小组成员的构成而言，一般是由三至五人组成，其中一人扮演“协调人”；一人担任秘书角色，负责记录所有查处的错误；还有一人担任测试人员。不过最佳的组合应该是：

一位极富经验的程序员；
一位程序设计语言专家；
一位程序员新手（可以给出新颖、不带偏见的观点）；
最终将维护程序的人员；
一位来自其他不同项目的人员；
一位来自该软件编程小组的程序员。

 

4 代码检查、走查以及可用性测试是三种主要的人工测试方法。这些测试方法可以应用在软件开发的任何阶段，包括在一个应用程序编码基本结束或者每一个模块（单元）编码结束之后（阅读第5章关于模块或单元测试的更多内容）。本章将主要介绍前两种针对代码的（白盒级别的）测试方法。
http://book.2cto.com/201210/6965.html

 

5 文章

为什么要做代码走查？

http://www.51testing.com/html/98/n-228098.html

代码走查的一点思考

http://www.51testing.com/html/66/n-220766.html

 一个典型的代码走查检查单

http://www.51testing.com/html/73/n-71873.html

代码走查表

http://www.51testing.com/?uid-148-action-viewspace-itemid-70260

如何执行代码走查活动才会有效呢(转) 

http://www.51testing.com/?uid-318121-action-viewspace-itemid-219112

关于代码走查和代码审查
http://www.51testing.com/?uid-181883-action-viewspace-itemid-249971

同行评审过程描述（三）——走查步骤

http://www.51testing.com/html/58/1158.html

IEEE Standard for Software Reviews 1028-2008

 

 

 

二、参与人员

走查负责人

秘书

程序员本人

其他团队成员

 

三、走查内容

 

1. Comment　　注释没写，或者格式不对，或者毫无意义　　

2. Coding Standard　　没遵守代码规范　　

3. Existing Wheel　　重复现成的代码，或者是开源项目，或者公司已有代码　　

4. Better practice　　Java或者开源项目，有更好的写法　　

5. Performance bottle and Improvement　　性能瓶颈和提高　　

6. Code Logic Error　　代码逻辑错误　　

7. Business Logic Error　　业务逻辑错误

 

走查流程

走查对形式的要求更为简单，主要有下述两种方式。

（1）参与者驱动法： 参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。作者必须回答每个质疑，要么承认确实有错误，要么对质疑做出解释。

（2）文档驱动法： 作者向评审人仔细解释文档（或代码）。在此过程中，可以将评审的内容（如关键代码、架构图、业务逻辑图等）用投影仪投射到屏幕上，作者对工作产品进行讲解，评审人不时针对事先准备好的问题或解释过程中发现的问题提出质疑。它比参与者驱动法可能更有效，往往能检查出更多错误。经验表明，使用文档驱动法时许多错误是由文档讲解者自己发现的。

在走查过程中，每个评审人都要记录错误或建议，会后要整理会议记录，作为走查报告。工作产品的作者可以根据自己的思路对走查报告质疑。

注：对代码的同行评审其实就是代码走查，可以使用投影仪打出关键代码位置与参与人员一起读，也可以几个开发人员一起进行交叉走查。选定的进行代码走查的范围根据需求的优先级来具体确定。

 

 

四、其他资料

 

1 、 至于测试的流程跟代码检查很类似，类似之处就不多谈，只说一下不同之处吧。稍有不同的是代码走查的任务：就是参与者“使用了计算机”。被指定为测试人员的那个人会带着一些书面的测试用例（程序或模块具有代表性的输入集及预期的输出集）来参加会议。且在会议期间，每个测试用例都在人们头脑中进行推演，即：把测试数据沿程序的逻辑结构走一遍，并把程序的状态（如变量的值）记录在纸张或白板上以供监视。

 

这里，需指出：这些书面的测试用例必须结构简单、数量较少，因为人脑执行程序的速度比计算机执行程序的速度慢上若干量级。之所以提供这些测试用例，目的不是在于其本身对测试了关键的作用，而是其提供了启动代码走查和质疑程序员逻辑思路及其设想的手段。因为，在大多数的代码走查中，很多问题是在向程序员提问的过程中发现的，而不是由测试用例本身直接发现的。

 

文尾，至于代码走查所需要从心理学角度给予提前的心理筹备、后续过程和附带的几个有益的作用，都与代码检查的类似，所以在这里就不提了。

 

2、 请注意，要使检查过程有成效，必须树立正确的态度。如果程序员将代码检查视为对其人格的攻击、采取了防范的态度，那么检查过程就不会有效果。正确的做法是，程序员必须怀着非自我本位的态度来对待检查过程，对整个过程采取积极和建设性的态度：代码检查的目标是发现程序中的错误，从而改进软件的质量。正因为这个原因，大多数人建议应对代码检查的结果进行保密，仅限于参与者范围内部。尤其是如果管理人员想利用代码检查的结果，那么就与检查过程的目的背道而驰了。

 

 

五、 代码走查与检查的共同点

 ⊙方法：组成一个小组来阅读或直观检查特定的程序；并在“头脑风暴会”上要形成统一的目标：找出错误，但不必找出改正错误的方法。换句话说，是测试，而不是调试。该组开发人员（三至四人为最佳）是对代码进行审核，其中参加者当中只有一人是程序编写者；也可以说它是对过去桌面检查过程的改进。

⊙优点：一旦发现错误，就可以在代码中对其进行精确定位，这就降低了调试的成本；还通常可以发现成批的错误，这样就可以一同得到修正，这也优于机器测试，因为后者只能暴露出错误的某个表症。

⊙效果：通常是能够有效地查找出30%-70%的逻辑设计和编码错误，但不能有效地查找出高层次的设计错误。

⊙地位：是与计算机的测试互补的，缺少其中任何一种错误检查的效率都会降低。

值得提出的是：该处的错误发现率，并不是说所有错误中多达70%可能会被找出来，而是讲这些方法在测试过程结束时，可以有效地查找出多达70%的已知错误。

应始终记住的是：程序中的错误总数始终是未知的。否则就会浪费大量的精力跟人力，也会在经济效益上或多或少有一些损失的。不过，就经验而言，修改一个现存的程序比编写一个新程序更容易产生错误，这依据于以每写一行代码的错误数量来计的。