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

由 FindBugs 、 PMD 、 CheckStyle 以及 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 。