FindBugs(source), PMD(source), CheckStyle(source), IntelliJ IDEA(source)と言った静的コード解析 (Static code analysis:SCA) ツールは、開発者チームにとって、問題を見つけ出し、高いクオリティを保つ助けになる。しかしSCAツールが問題を指摘した際、チームはどう対処すべきなのだろうか？Vikas Hazrati氏の「静的コード解析は、単に氷山の一角にすぎない(source)」と言う記事は次のように示唆している。さらに深い部分を見よ、と。
もし、指摘された問題についてチームで合意が得られた場合、彼らは問題をフィックスするだろう。しかし多くの場合、その指摘された問題は、より根の深い不具合 - 見えづらく、コード解析ツールが簡単には検知できない - を浮き彫りにしているかもしれない。
巨大なシステム - 数百万人の人々に、オンラインで利用される - の監査を行っているときに、私はこうした洞察をじかに得ました。解析を行っている最中に、私と一緒に監査を行っている人物が、SCAツールによりハイライトされたホットスポットを探そう、と提案しました。そして私たちはそうした箇所のコードにダイブし、より大きな問題を見つけ出したのです。
Vikas氏は、静的解析によって指摘された問題が、より深いコード上の問題の発見につながった例を5つあげた。たとえば、3500行と800行のメソッドからなるサーブレットが存在した時のことだ。
この問題に対する手っ取り早い修正方法は、メソッドを分割して、いくつかのメソッドをクラス外のヘルパークラスに移動することで、メソッドサイズを削減することでした。クラスサイズとメソッドサイズ違反に対処するためです。
しかし、"なぜサーブレットがこれほど多くの行と、こんなに大きなメソッドを持ってるんだ？"と言う質問に関する答えを突き詰めたとき、全てのビジネスロジックがサーブレット内に存在していたことに気がついたのです。一つのクラスに全てのロジックが存在しており、「一つのクラスには一つの責務」と言う原理に対する大きな違反がありました。プレゼンテーションロジック、ビジネスロジック、そしてデータアクセスロジックが全て混在していたため、それを壊すことなく変更するのは困難な、壊れやすいデザインになっていました。そこには階層化も、関心事の分離も存在しませんでした。
同様に、多くの引数を持つメソッドを見つけたときは、
これを解決し、SCAツールをハッピーにする簡単な方法は、オブジェクトを作成し、そのオブジェクトに必要なパラメータを格納することでした。
しかし、コードを深く読んでみると、システムが抽象化を全く行っていないことに気付きました。システムのどこにもドメインオブジェクトがありませんでした。メソッド呼び出しの間でデータが渡される必要が生じると、そのほとんどはプリミティブなデータ - 多くは文字列 - として渡されていたのです。そこには、ドメイン駆動デザインへのフォーカスが全くありませんでした。シチュエーションが異なるごとに必要になったと思われる、余分な引数毎にメソッドはオーバーロードされていました。このことから言えるのは、そのシステムは「修正に対しては開いており、拡張に対して閉じている」と言うことでした。どんな小さな変更のためにでも、新しいメソッドを書く必要が生じました。これは、Open-Closed Principleに違反していたのです。
原文はこちらです：http://www.infoq.com/news/2007/12/static-code-analysis-finds-flaws