静态分析工具使用调研

作者:胡婉莉

      作为静态分析工具的开发人员,如何提高自己产品的竞争力一直是我们关心的问题。发表于ICSE 2013的文章Why Don’t Software Developers Use Static Analysis Tools to Find Bugs给了我一些启示。
      该文章以调查分析的形式,通过向20个软件开发人员的采访,得出一些结论。文章中对每一个被采访者提了三个问题,被采访者结合自身经历通过回答问题,给出了不少有用的建议。
      第一个问题:为什么使用或者为什么不用
      在这个问题上有人都觉得静态分析工具是很有用的,但是大量误报和缺陷报出的方式的不友好在一定程度上影响了人们的使用。误报的问题暂且不说。文中的被采访者针对缺陷报出的方式提出了大量的有价值的建议。
      首先在界面输出方面,有人建议对输出的结果进行分层分类,使结果更加清晰明了。也有人建议缺陷优先级的提示以及增加暂时忽略功能,即用户看见这个bug了,但是现在不想改,就可以点击暂时忽略,忽略这个或者这类bug。其次在用户配置方面,有人觉得配置项过于复杂,而且无法在一个团队内共享配置项。这些问题降低了用户体验感,是值得改进的问题。有人建议可以提供云分享功能,使开发者可以共享和交流。最后在结果解释方面,有人建议给出缺陷的相关路径,同时规则的描述需要简介详细,需要包含是什么缺陷、为什么会发生、如何改正等信息。
      第二个问题:现有工具适应开发流程的情况何如?
      在这个问题上受访者则普遍认为不好。主要是因为现有的静态分析工具普遍较慢,这会拖慢整个开发流程。而且现有工具普遍对大工程的支持也不够好,有时甚至会崩溃。这也极大的降低了效率。同时大多数人觉得在工具以后台运行,或者嵌入式、编译器集成的方式运行要更加方便一些。因为这样不用切出原本的开发环境。
      第三个问题:开发者对于工具改进的建议
      针对这个问题大家给出了许多建议,例如:建议使用颜色来区分缺陷的危险程度和针对开发流程的,建议检测分两次,第一次是实时的,方便开发人员的及时修改,当然这对检测速度是有要求的,第二次是开发完之后的宏观检测。
      许多受访者提到了快速修改,即自动修改功能,我觉得这也是非常有价值的建议,可以作为我们的工具的下一步的发展方向。针对快速修改又有诸多建议,例如:最简单的是给出修改样例以供用户参考,还有对修改前和修改后的代码分栏对比显示以便用户选择是否修改,也有人建议修改预览然后选项弹出是否修改。当然快速修改虽然听起来很好,但做起来难,所以也有人持否定态度,主要还是在修改的准确度上。
      总结起来文中受访者提出的建议几乎都是在用户体验感方面的。的确,这是用户最直接接触的东西,远比我们想象的更加重要,但是也是我们比起工具的误报、漏报等更容易改善的地方,值得我们重视。