静态分析工具可以突出更深层次的问题

  • Geoffrey Wiseman
  • 苑永凯

2007 年 12 月 15 日

话题:敏捷语言 & 开发架构文化 & 方法

FindBugsPMDCheckStyle以及IntelliJ IDEA等等提供的静态代码分析(Static code analysis,SCA)工具可以帮助开发团队捕捉到代码中的问题,来保证程序的高质量。但是当 SCA 工具标记了一个问题之后,团队应该如何作出反应呢?Vikas Hazrati 在“静态代码分析仅仅是冰山一角”一文中建议:深入探索。

如果团队对 SCA 标记的问题达成了共识,那么他们会修复这个问题。然而,在很多情况下,被标记的问题可以突出一些更深层次的问题,而且这些问题隐藏较深,也不容易被代码分析工具侦测到:

当我对一个有数百万在线用户的大型系统进行审计的时候,我第一次深入洞察到更深层次的问题。在分析的过程中,我的审计助手(co-auditor)提议检查一下 SCA 工具高亮提示的热点。然后,我们深入到那块代码中并发现了更大的问题。

Vikas 列举了五个由静态分析标记的问题发现代码中更深层次问题的例子。如,当发现一些 servlet 有 3500 行之巨,还包含长达 800 行的方法时:

一种快速的修改方式就是分离方法体来减小方法大小,将一些方法迁移到助手类(helper class)中减小类的大小,这样就解决了类大小和方法大小的违规。

但是,当我们尝试回答“为什么这些 servlet 包含了如此多的代码和巨大的方法?”来深入探索原因的时候,我们意识到所有的业务逻辑都放在了这些 servlet 中。将所有的逻辑放入一个类中严重的违反了单一职责原则。表现逻辑、业务逻辑和数据访问逻辑掺杂在一起导致脆弱的设计,这样很难在不破坏原 有设计的基础上做出变动。各种关系之间没有任何分层和分离。

同样,当发现带有大量参数的方法时:

解决这个问题并让 SCA 工具不再警告的快捷方式就是引入一个对象,将所需的参数封装起来。

但是,当我们深入研究时就发现,这个系统中没有任何抽象。系统中也没有领域对象。当需要在方法调用之间传递数据时,所有的数据都是简单数据,大多是字符 串。这说明系统并没有采用领域驱动设计。在不同的场景下,需要根据需求来重载(overload)这些方法加入额外的参数,这暗示着这个系统对修改开放, 对扩展关闭。每一个小的修改都需要增加新的方法。这违反了开闭原则。

查看英文原文Static Code Analysis can Highlight Deeper Flaws


译者简介:苑永凯,软件设计师,毕业于山东大学。主要关注领域为 Java EE 企业应用、Java EE 中间件技术以及敏捷开发方法实践,微有心得。他的 Blog 为http://blog.csdn.net/ai92,您也可以通过yuanyk@gmail.com与他联系。参与 InfoQ 中文站内容建设,请邮件至china-editorial@infoq.com
敏捷语言 & 开发架构文化 & 方法