内容


您使用工具集来检查代码吗?

简介

许多人认为代码检查就是程序员逐行地查看源代码。为了提高效率,这种人工式的代码检查必须有高级程序员和技术专家的参与。毫无疑问,由专家参与检查代码缺陷是很缜密高效的,但是在实际操作中,专家们很难抽出时间来参与代码检查。

这并不意味着软件检查活动的每个阶段必须依赖于高级专家。事实上,有些阶段可以通过软件或其他便利工具来自动完成,包括静态分析软件、角色分配和检查列表,而不需要技术人员的参与。

许多文章都阐述了使用工具集带来的效率(见 参考资料)。本文展示了一个用于代码检查的工具集,并通过示例演示如何使用这些工具。不过,这些工具中的大部分都可用于检查其他工件,比如需求描述和设计文档。本文的最后部分简单讨论了使用工具如何提高检查效率以及该领域的发展预期。

代码检查过程

表 1 列出了软件检查涉及到的所有阶段和活动(见 参考资料)。作者添加了 “Toolset” 小节。本文的其余部分介绍这些检查阶段需要使用的各个工具。

表 1. 软件检查涉及到的阶段
概览准备检查(发现缺陷)返工(改正)后续观察
任务内容
  • 确定角色
  • 确定视角和技术
  • 计划
  • 确定检查目标
  • 配合角色理解目标
  • 分配角色
  • 每个角色发现的缺陷
改正缺陷
  • 核实改正结果
  • 确保改正过程中没有引入其他缺陷
工具集
  • 角色定义
  • 阅读技巧
  • 静态分析工具
  • 角色分配
  • 代码编写约定
  • 编译器(警告)
  • 阅读技巧
  • 静态分析工具
  • 角色分配
  • 阅读技巧
  • 检查工具
  • 缺陷跟踪工具
  • 检查工具
  • 缺陷跟踪工具
  • 检查工具
  • 缺陷跟踪工具

概览、准备和缺陷检查阶段

角色定义和分配是概览和检查的工具

如果在检查过程中出现角色不明确的现象,那么就很难将检查过程顺利进行下去。角色是在检查阶段分配的,参与检查的人员必须根据自己充当的角色去发现问题。从这种意义上讲,角色定义本身就是用于检查的工具。表 2 基于 IEEE 1028 “Standard for Software Reviews and Audits”(见 参考资料)和论文 “An Encompassing Lifecycle Centric Survey of Software Inspection”(见 参考资料)。可以出现多个参与者担任同一个角色的情况下,也可以出现同一个参与者担任多个角色的情况。例如,两个或多个参与者担任检查员角色。

表 2. 软件检查的角色
角色说明
协调员协调员的任务是引导参与者完成其目标。通常由一个人来担任协调员,他准备一个能够在指定的时间段内检查到可能出现的缺陷的环境,从而确保检查能够继续进行。协调员确保讨论不会偏离主题,并且确保适当的讨论速度,让记录员能够将发现的缺陷记录下来。时间管理也是协调员的一个重要任务。
检查员检查员负责识别和找出缺陷。通常情况下,不管其具体角色是什么,所有成员都可以充当检查员。
记录员记录员负责记录检查员发现的所有缺陷。通常情况下由一个人担任记录员。记录员必须具有经验才能准确完全地记录下所有发现的缺陷。如果以电子邮件的方式收集缺陷报告,记录员就负责排除重复的缺陷报告并整理出发现的所有缺陷。
组织者组织者负责将整个计划关联起来,包括总体开发计划,以及确定检查的时间表。
作者作者开发出需要检查的产品。作者负责改正产品缺陷。
解释员解释员在检查过程中解释产品。解释员必须是作者之外的人员,他代表作者解释产品。

概览、准备和缺陷检查阶段

阅读技巧

阅读技巧能够让识别缺陷代码的流程更便捷。最常见的阅读技巧是使用检查列表。检查列表包含 “是否正确地释放资源?” 和 “过多的嵌套循环是否会损害性能?” 等问题。该列表用于帮助检查员检查缺陷。检查员根据这种检查列表阅读源代码,查找与这些问题相关的缺陷。可以根据目标软件的需求修改或选择检查列表中的问题。

基于透视图的阅读是一种能够为阅读者提供特定视角的技术,比如 “用户” 或 “测试员” 视角。有报告表明这种技术在全面检查缺陷过程中可以大大提高效率,因为可以从多个视角执行检查。负责用户透视图的人员需要通读代码,并且要时刻记住以用例作为标准。负责测试员透视图的人员需要通读代码,并且要考虑哪些测试例子能够证明代码能正常工作。

因此,与毫无计划的检查相比,基于透视图的阅读为缺陷检查创建了更加广阔的视角。读者的透视图不一定要与他们在项目中的角色相对应。例如,用户透视图可以分配给项目主管。此外,可以将某个透视图细分为更多的透视图。表 2 显示了项目中的每种编程技能涉及到的透视图(参见 参考资料 了解更多信息)。

表 3. 基于透视图的阅读的示例透视图,Denger 和 Shull 在一篇介绍 IEEE Software 的文章中首次使用(见参考资料)
初级开发人员高级开发人员
介绍在您的检查过程中以这些用例为中心。从最复杂、最重要的部分开始阅读。此外还要考虑必须理解整个系统的功能的开发人员应该理解哪些类。
说明根据重要性划分用例的优先级别。对于每个用例,尝试在将要调用的代码中跟踪控制流。根据重要性和复杂性划分检查的优先级别。
问题
  • 源代码中是否有充足的注释?
  • 每个用户交互中是否存在错误处理?
  • 是否有足够的错误和调试日志来定位 bug?
  • 是否在兼顾性能和内存的同时适当地使用数据结构?
  • 与浮点数相关的代码是否正确?
  • 是否值得花费精力去实现该代码的重用性和可用性?

准备和检查阶段

使用源代码静态分析工具识别检查区域

词组 “源代码静态分析工具” 是一个通用的词汇,它表示用于在未执行程序的情况下从源代码提取信息的工具。这种分析包括计算源代码指标、根据预定义模式筛查潜在的 bug 和发现是否违反编程约定和规则。这种分析有益于代码检查,因为它能够识别容易出现 bug 的代码。例如,它将 bug 目标锁定为方法、函数、类或包含复杂逻辑的模块。有大量研究表明,这些复杂的区域最容易出现 bug。识别这些区域有利于将代码检查的力量集中在关键区域,从而提高效率。

通过识别潜在的源代码,静态分析工具还能帮助发现资源泄漏,比如无法释放内存或资源。

源代码指标可能包含很多东西,包括分支和循环的数量、函数或方法参数的数量和源代码的行数。许多案例研究表明缺陷容易出现在复杂的区域,比如具有许多分支或循环的区域。有资料表明这些指标与质量相关。仅通过测量源代码指标是很难发现 bug 的,但您可以确定很可能包含 bug 的代码的位置。包含 bug 的几率比较大的源代码称为 “容易出错的代码”。有许多分析开源项目的研究论文,您可以从 Metrics Data Program NASA IV&V FACILITY 的(见 参考资料)可下载指标中了解该关系。

还有一些工具能够检测到源代码中可能访问 null 指针或在数组范围之外寻址的位置。这些工具从源代码估计执行流程。下面列出的 developerWorks 文章(见 参考资料)介绍了一些源代码静态分析工具:

  • "Rational® Software Analyzer"
  • "Static analysis IBM® Rational Software Analyzer: Getting started"

最后,一些最前沿的静态分析工具能够从源代码提取设计模式。识别设计模式的位置和类型能够帮助检查员理解源代码。此外,它还能帮助查找与特定的设计模式相关的潜在缺陷。可以在 参考资料 部分找到这些工具的链接:

  • Design Pattern Recognition 工具
  • DPR
  • DP-Miner

源代码静态分析工具能够帮助您慢慢了解应该将检查力量集中在哪里,从而帮助您确定在准备阶段应该检查哪些区域,以在检查阶段高效地找出存在潜在 bug 的区域。

准备阶段

代码编写约定、规则和指导原则能降低检查难度

代码编写约定又称代码编写指导原则或规则,它们是一组定义编程实践的指导原则。每种编程语言都有其规范。编译器和运行时解释器遵循语言规范进行运作。类似地,代码编写约定的目的是阻止缺陷和让代码便于阅读。不遵循语言规范的代码将无法执行,而不遵循代码编写约定的代码却依然能够执行。

有许多不同的代码编写约定,但它们的目的都是改善代码的可读性和可靠性。约定的可读性目标包括使用断行、将空格当做制表符和空白对待,以及条件语句的格式。约定的扩展性目标涉及到使用已定义的常量而不是显式的数字等。这允许通过更改一个常量的值来改变它的所有实例的值。约定的可靠性目标涉及到避免使用递归函数或 goto 语句,因为它们容易增加代码的复杂性,从而导致出现 bug。语言规范可能支持 goto 语句和递归函数调用,但使用其他方法能够让代码更易于理解。

代码编写约定的种类繁多,包括针对行业应用程序的约定、作为交付条件的约定、普遍适用的约定和在企业内部使用的约定。汽车应用程序中使用的 C 语言源代码的 MISRA-C 约定和 GCC 约定(参见 参考资料)就是众多的编程约定之一。

准备阶段

编译器警告能够提供帮助

大部分编译器都能够就可能导致问题的语句发出警告,即使这些语句并不导致编译错误。与专用的源代码静态分析工具相比,编译器的此项功能比较有限,但值得一试。以开放源码编译器 GCC 为例,您可以通过指定命令行选项 -Wall 来生成详细的警告。

这些警告是针对源代码内部的特定位置(行号)生成的。例如,警告包含已声明有变量但未在任何函数或方法中使用它们的位置、使用未进行初始化的变量的位置以及试图使用非建议库的位置。通过更改源代码消除警告能够减少出现 bug 的几率,并且能够提高可靠性。

缺陷检查、改正和后续观察阶段

检查工具和缺陷跟踪工具

支持源代码检查的软件工具具有浏览源代码、注释源代码和列出注释的功能。图 1 和图 2 显示了 Jupiter 的屏幕截图,它是针对 Eclipse 的协作式代码检查插件。在图 1 中,第 29 行有一条注释 “The accessibility modifier which should be private is public”,并且在界面底部的 Review Editor 选项卡显示了条目的状态。在图 2 的下半部分,Review Table 面板将所有注释收集到一个表中。

除了 Jupiter 之外还有许多其他检查工具,包括 Review Board 和 Rietveld。bug 和问题跟踪系统也为记录和跟踪发现的缺陷提供帮助。如果您在测试阶段使用 BTS 或 ITS,并且在需求设计和代码编写阶段使用文本文件或电子表格应用程序,那么将 “在检查期间发现的缺陷” 添加为一个 bug 类别并尝试使用这些工具。

图 1. 在 Jupiter 代码检查插件中记录问题
屏幕截图显示 Eclipse 中的 Jupiter 插件带有一条代码注释
屏幕截图显示 Eclipse 中的 Jupiter 插件带有一条代码注释
图 2. 在 Jupiter 插件(底部的面板)中显示的已发现缺陷列表
屏幕截图显示 Jupiter 在 Eclipse 环境中对代码问题的分析
屏幕截图显示 Jupiter 在 Eclipse 环境中对代码问题的分析

更加高级的检查

在执行检查之前使用工具集对代码进行预先排查能够减轻检查员的负担。如果没有该步骤,检查员的负担可能过重并抱怨 “我为什么要阅读这里?”,甚至开始开起小差来或把气撒到软件作者身上。充分的准备工作能够避免这种情况。

检查时间可能会延长,这就需要使用协作支持和工作流管理软件。这种软件能够全面地管理检查的结果和进度。

本文介绍的代码检查工具、角色定义、阅读技巧、检查工具和问题跟踪工具的用途并不局限于代码检查。它们还可用于检查项目计划、需求定义、规范、设计文档、测试计划、操作手册和用户手册。

检查是许多企业和开放源码项目的例行实践。高度集成的、基础的、安全性要求比较高的软件都需要经历检查阶段。不过,与其他软件开发活动相比,检查活动的可用信息比较少。我希望本文能够帮助开发和传播更多关于检查的信息。

为了建立一个让代码检查员能够发布代码检查分析的社区,Working Group of International Research Cooperation on Software Inspections 举办了 Software Inspection Workshop 2009。表 3 概述了该研讨会。这次研讨会的目的是让与会者学习到阅读代码的技巧,并倾听 Fraunhofer IESE and Nara Institute of Science and Technology 关于代码检查的研究报告。

表 4 显示了研讨会的安排,图 3 给出了研讨会现场的图片。目前,德国的 Fraunhofer IESE 和日本的 Nara Institute of Science and Technology 正在分析和讨论该研讨会的结果,将来会发布一篇相关的研究论文。

表 4. Software Inspection Workshop 2009 概述
时间2009 年 7 月 2 日
地点Campus innovation center Tokyo (Tamachi, Tokyo)
主办方Working Group of International Research Cooperation on Software Inspections
合办方Nara Institute of Science and Technology, Japan
Fraunhofer IESE, Germany
IBM Japan
表 5. Software Inspection Workshop 2009 安排
大会开始
Kyoko Hattori (IBM Japan)
研讨会和软件检查介绍
Shuji Morisaki (Nara Institute of Science and Technology, Japan), Frank Elberzhager, Marek Jawurek (Fraunhofer IESE, Germany)
通过独立的检查和验证确保质量和阻止缺陷
Hironobu Hosokawa (IBM Japan)
检查材料解释
Frank Elberzhager, Marek Jawurek (Fraunhofer IESE, Germany), Shuji Morisaki (Nara Institute of Science and Technology, Japan)
与会者阅读材料并进行讨论
介绍 Rational Software Analyzer
Koshimizu Yoshiyuki, Atsuhi Kurokawa (IBM Japan)
小组讨论
Moderator: Jun-ichi Niino (Publickey, Japan)
Paneler: Hironobu Hosokawa, Yoshiyuki Koshimizu and Shuji Morisaki
大会结束
图 3. 与会者阅读材料并进行讨论的图片
图 3. 与会者阅读材料并进行讨论的图片
图 3. 与会者阅读材料并进行讨论的图片

致谢

在撰写本文时,研讨会的参与者 Kyoko Hattori、Koh'ichi Miyagawa、Frank Elberzhager、Marek Jawurek、Jun-ichi Niino、Nobuhiro Hosokawa、Yoshiyuki Koshimizu、Atsuhi Kurokawa、Michael D. Barker、Yuichiro Yasuda、Kyohei Fushida 和 Yasutaka Kamei 为我提供了宝贵的支持和合作。本文介绍的一些研究来自于 “The Development of Next Generation IT Infrastructure” 项目。该项目是 StagE Project (Development of Next Generation IT Infrastructure) 的一部分,并得到日本的 Ministry of Education, Culture, Sports, Science and Technology (MEXT) 的支持。此外,本文介绍的一些研究获得 MEXT 提供的 Grants-in-Aid for Scientific Research (B), No. 21700033 补助金。


相关主题

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Open source
ArticleID=479565
ArticleTitle=您使用工具集来检查代码吗?
publish-date=04012010