Infer:非死book Java静态分析工具初探

jopen 9年前

 

怎么通过非死book的Infer来改善你的Java开发工作流程?

如果你保持对技术问题的持续关注(我假定你是这样的,如果你正在读这篇博客的话),你可能听到非死book开放了一个新的工具:Infer。因为它来自非死book,大家自然都比较好奇,所以我很想看看该工具是什么东西?对Java开发者来说,能扮演什么角色?

非死book Infer是什么?

在使用之前,第一步当然是了解该工具是什么,能做什么。Infer是非死book最近开源的一个静态分析工具。是为iOS和Android 设计的,它用于在app发布之前,发现其中的bug。非死book的工程师将Infer作为内部工具,应用在非死book和Instagram等 app上,所以它能够很好的应用在大规模的移动环境中。

粗略的讲,Infer的工作方式是在编译期扫描你的代码,预先发现bug和错误。从编译过程中抓取信息后,就对该信息进行分析查找潜在的bug。如果有任何的发现,它就会向终端发送报告,并将问题记录在一个目录文件里。最典型的bug的例子就是查找空指针异常和资源泄露。

Infer的安装需要Python 2.7及Mac OS X或Linux。可以直接通过javac或构建工具如Maven或Gradle来运行。在实践中可以类似这样:

在这个例子中,我们能看到Infer怎么识别一个简单的空引用,并输出相关的解决信息,当问题解决并保存后,该类就能成功通过检查了。Infer完整的源代码可以在Github上找到。

增量 vs 非增量

Infer可以采用增量或非增量的方式运行。两者之间的不同点在于Infer是否删除已存在的结果目录。例如,在构建一个系统的时候,你可能想采用增量的方式运行,而执行单条编译命令时采用分增量的方式。如果要使用增量模式,只需增加–incremental标志。

Infer的局限性,Infer面临着和其他静态分析工具同样的问题。它存在错误的警告和bug丢失的问题,这个问题与你的应用如何编码,如何与第三方的库交互都有关系。另一个局限是存在检查范围的问题,因为它不能以动态的方式来进行测试。此外,对某些类型的bug检测还存在技术性限制,例如,迄今为止,Infer还不能测试数组越界或类型转换异常等问题。

这对Java开发者来说意味着什么呢?

Infer是为手机应用设计的,但是对普通的Java程序也能非常好的工作。它可以从构建工具(如Maven)开始运行,但是不一定完全符合你的工作流程。当然,问题在于是否值得用。

该问题的答案归结为你对静态分析工具的态度。Infer明显既不是第一个Java静态分析工具(例如,FindBugs是其中比较流行的一个),也不是第一个开源的这类工具。它仅仅是来自于非死book的一个工具,但是,这可能给你带来固定的想法。既然是非死book建立的,用于大量的apps,Infer自然被马上大规模使用了。

Infer还面临一些Java语言自身的限制。它不能处理Java的并发工具(Concurrency Utilities)或特性,比如计算。这些问题同样困扰着在其它静态分析工具,但是这点确实需要谨记。

工作流中的应用

静态分析工具通常在开发阶段使用。它们的本质是一个测试工具,是作为开发过程或CI/CD工作流中的一个步骤。它们不能代替调试器,因为它们工作的时候代码已经编译完成。它们也不能代替生产环境中的错误追踪器,因为整个主机的bug,只有当代码在生产环境暴露后,动态输入刚好命中时才会产生。但是在这两个环境之间存在一个空间,在这个地方,像Infer的工具是非常有用的。

例如,你可以将Infer做为一个开发环境(IDE)与生产环境(Takipi)中间的步骤。Infer在这种情景下,能帮助你在上线之前预先发现那些明显的bug。这能给你的用户防止一些问题,至少减少你Takipi面板上的问题,如果你使用Jenkins作为持续开发模型,你可以在每个版本发布的时候运行Infer,然后查看抛出的红色标记。

结论

当一个像非死book一样的公司开源一个使用的很好的Java工具时,是值得我们去看一下的。Infer不是特意为Java设计的,但是它能对Java app做静态代码分析。虽然存在一些固有的局限性,但是也有很多优秀功能,还有一些特性需在将来进行确认。如果你使用了它,请在评论里让我们知道你的看法。

使用正确的工具是成功的关键,在你的代码发布的生产环境之前,确保所有的代码都被覆盖到了,查看 警告工具章节 获取生产环境工具的权威指南。

原文链接: takipi 翻译:ImportNew.com -paddx