今年年初 Klocwork 发布了一款桌面产品—— Klocwork Insight ， 这样每个开发人员都可以应用它的自动源码分析的特性。Insight 分别有基于 C++ 和 Java 的两个版本。目前行业现状是，大家都习惯于把源码分析放在 系统构建阶段的签入步骤之后进行。如今 Insight 把这一过程提前到构建和开发周期中的实现环节。从 Java 的角度来看，Insight 可以以多种方式进行集成：
……Insight 支持包括 1.6 在内的所有 Java 版本，而且不仅如此，它还增强了对各种流行的 Java 框架的支持，如 Google Web Toolkit、AWT、Hibernate、JavaMail、J2EE 和 J2ME。它还支持 Eclipse、IBM Rational Application Developer、Intellij IDEA、and JBuilder 2007 IDEs 和 ANT 及 Maven 构建系统……
之前，Klocwork 由于宣称发现开源项目存在大量缺陷成为新闻焦点，而这些缺限即使是早先国土安全部的研究也没有发现。
InfoQ 最近与 Klocwork 的首席技术官 (CTO)Gwyn Fisher 就其产品进行了讨论。讨论的第一个主题是如何决定重点分析条目：
我们大量的研究工作都是以客户代码中实际发生的错误为基础进行的。开发缺限自动检测解决方案的现实情况是：你必须在“代码正确却被认定有错（误报）”和“代码错误却未被识别（漏报）”这两种情况之间达到一种动态平衡，用户使用产品的真实体验为我们指明了这种平衡点所在和努力方 向。最终我们是侧重于误报还是漏报则要根据使用报告（我们应用 3D 可视化技术定期对其进行极为细致地研究和分析）中体现出的形式而定。
Fisher 补充说：要指出哪一类分析模块对于开发人员最困难不是一件容易的事。不过，缓冲区溢出是比较引人注意的一种类型，仅仅提供上溢 / 下溢可能发生的场景数目，以及可以区分真正的溢出和正常运行的程序的微妙之处，就能给出问题代码库的主要语义了。Fisher 总结说，开发人员可能非常“确信”存储在配置数据或者从输入设备读入的值不会超出给定范围，因此由这些数据引起理论上的溢出就比较困难，即使它们实际上存在缺陷。 InfoQ 提出的第二个问题是对于普通开发人员，Klocwork Insight 的联机桌面分析特性会带来何种收益：
[GF] 试着这样做：不起作用的代码不要签入，这很简单。联机桌面允许开发人员在签入之前进行本地代码分析，并且可以保证具有和集成构建分析相同的准确性和上下文环境。 通过一个例子我们可以更清楚地描述这个问题。假定有个开发人员，我们估且称他为 Jim，他工作在一种典型的消费者模式 下，就是说他的工作依赖于同一办公间里另外一位开发人员。当通过分析认定 Jim 的程序正确时，一方面我们要告诉他代码写得不错，另外一方面我们要了解他调 用的代码怎样工作，这样我们就可以确认他的代码与他调用的代码之间的交互关系也是正确的。
没有分布式上下文环境，分析引擎不能断定 null 对象传给 foo() 方法是否会引发问题；也不能分辨 foo() 方法是否能返回一个可用的对象。但是有了这个上下文环境，所有这些灰色区域就可用实际的分析取而代之。引擎可以知道 foo() 的内部机制，即使你的本地根本就没有这段程序，如果你打算做什么愚蠢的事情，那么它会像在集成构建分析过程中做到的那样来提醒你。
分析精确性中的这种等效性在几个方面获得了回报，其中生产率是最为明显的。但是如果你考虑公司实现代码分析面对的文化阻碍，那它就更 具吸引力了。典型的，一般公司都会将代码分析作为审计工具整合进集成构建过程，重视报告并将之视为交互点。这要求必须建立如下工作流程之一：强制要求开发人员暂停手头工作，访问报告程序，以查找个人所犯错误；或者由上级通过 e-mail 给每个人发送错误通知。
不过，还是把进行准确、快速和有效地分析代码的权力放到开发人员手中吧，摒弃那种“问责怪圈”，集中精力让开发者从起步时就创建出高品质、高安全性的代码。
就此 InfoQ 希望 Fisher 先生能比较一下 Klocwork 和流行开源工具 FindBugs：
FindBugs 是一款很优秀的工具，我非常欣赏 Bill Pugh 为此所做的出色的工作以及无偿分享其产品。大多数人第一次接触的 Java 代码分析工具都会是他的产品，总的来说对市场是有利的。我们同 FindBugs 的不同之处在于分析的深度，可发现缺限的数量和种类。特别是，FindBugs 偏重于一种内部程序缺限，就是通过在一个特定方法内跟踪控制流和数据流来分析错误（实际上如果开发者能够注释他们的代码以详述预期的行为，他们就可以扩展这种分析，不过这就有点欺骗的意思了 ;P）。Klocwork 的分析是在程序间进行的，这意味着我们可以发现跨类、跨包甚至跨模块边界方法调用的缺限。这种“程序整体”分析就是商业静态分析所能做的事情。
最后，InfoQ 请 Fisher 先生比较一下在编写 Klocwork C++ 分析工具和更新的 Java 分析工具时的体会。他解释说，在 Klocwork 的观点来看，写一个好的代码分析工具的基础在于编译器。对于 Java，他们起初很乐观的打算分析调试模式下的字节代码，因此不需要再写一个编译器。然而这种方法后来被证明不是那么有效。除了编译器外，编写 Java 版本的最为重要的投资是关于检验程序库，因为要确保为市场提供一个与现存产品（C++ 版本）同样完美的引擎。目前，Klocwork 支持的每种语言所含有的检验程序几乎一样多（大概每种语言有 175 个）。
查看英文原文： Klocwork Insight Brings Code Analysis to the Desktop
评论