コードインスペクション

近年コードインスペクションはだいぶ一般的になってきたと思います。

コードインスペクションといってもここでは静的解析について書きます。

JavaでいうとOSSならFindBugs, CheckStyle, PMDが、商用ならJTestがメジャーだと思います。

厳密に言うとFindBugsはバイトコード解析だし、JTestは静的解析以外にも動的解析ができますが、その辺りはおいとく。

僕はかれこれ３年以上自社の商用製品としてJavaのコードインスペクション（静的解析）を扱ってきました。

宣伝ぽくなるのでツール名は挙げませんけど、上記のツール類に比べていくつかメリットがあると思ってます。もちろんデメリットもあります。--);

価格面はそんなに高くないと思いますが、デメリットの最たるものは最新プラットフォームへの対応が遅かったことです。実際Java6対応したのも最近だし。--);

まあこの辺はJava6対応したいまとなっては大丈夫だと思います。Java7はまだ出てないし、出たとしてもJava5のときほど移行が進むとは思えないため。

前置きが長くなりましたが、メリットは運用について比較的？考えられていることです。

ここでさらに前置きになりますがｗ

インスペクションを運用するに当たって問題になるのは指摘が出過ぎることです。
これはインスペクションに使うルール数にもよりますが、おそらくどのツールを使おうが指摘を０にすることは現実的ではありません。使うルールを０にすればできるけどそれは意味がないｗ

指摘をどう抑止（無視）するかがポイントになってくるのかなと思ってます。やっと本第に来たｗ

弊社のツールの場合いくつかその方法を提供しています。ざっと説明すると以下の３つになります。

１．特定のソースパターンを抑止する

設定ファイルに無視するソースパターンを書いておくことにより、指摘を抑止できます。自動生成ソースに対する指摘を抑止したり、自動生成ソースの一部分を修正した場合にその部分だけ指摘したり、「〜Form.java」だったら〜ルールの指摘は抑止するといったことが可能です。

２．ソースに特殊なコメントを入れて指摘を抑止する

ピンポイントに指摘を抑止したい場合はこれです。ただしソースにツールに特化したコメントを入れることに手間と抵抗を感じるかもしれません。

３．母体ソースの指摘を抑止する

あらかじめ母体ソースを登録しておくと、母体ソース部分の指摘を抑止しエンハンスした部分だけを指摘対象とすることができます。

正直にいってインスペクションでここまでやる必要があるのかはなんとも言えませんが、プロジェクトの状況によっては有効なのかなと。

さらにいうと（これは対応してないけど）開発者が自分でいじったソースの差分だけ指摘してほしいなんていうこともあり得るわけです。
つまり複数人で１つのソースをいじっている場合に他人のコミットによる指摘は見たくないという状況です。

ここまでくると分散バージョン管理と連携しないとどうにもならないと思いますが、OSS開発を除くと需要があるとはちょっと思えないなあと感じています。

そんなに工数がかからない対応案は考えてあるのでやるかもしれないけど。