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

怎么通过非死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