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

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

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

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

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

同样，当发现带有大量参数的方法时：

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

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