76-コード分析ツールを利用する

「プログラマが知るべき97のこと」の76個目のエピソードは、コードの静的チェックに関する話です。どんなプログラマであれ、プログラミング中にミスがなくなる事はありません。訓練を積むことでミスを減らすことは出来たとしてもゼロには出来ません。これはバグがゼロ件であるシステムを作ることが出来ないこととも関連しています。出来ることは、ユニットテストや様々な方法を用いてミスを減らすことです。
コード分析ツールはそのようなコーディング上のミスを分析し、潜在的なバグを検知するためのツールです。かつてCPU時間と記憶容量がとても貴重だった時代には、コンパイラが効率よくコンパイルを行う事が優先されていました。コードの潜在的な問題をチェックまでリソースを避けなかったのです。しかし、現在ではコードの分析を自動的に行い、レポートを作成するコストが無視できるレベルになっています。つまり、コード分析ツールを使わない理由はありません。
近年、「静的言語は動的言語に比べてコンパイルの手間がかかる」とか「コンパイルしなければ動かない」と言った批判と共に動的な言語が人気となる流れがありました。Javaはそんな批判にさらされていたわけですが、一方で静的な型チェックやコンパイル時のエラーチェックがソフトウェアの品質を高めているとも言えます。ユニットテストを書く事が自然になると、動的言語ではチェックしなければならないような類のテストが静的言語では「コンパイルが通ること」でテストできる事に気付きます。最終的には適用する解決領域とプログラマの好みとなりますが、静的言語が一方的に効率が悪いとされた時代は過ぎたのではないかと感じます。
静的な解析は静的言語である方が得意です。Javaでは、コード分析ツールに相当する部分は概ねコンパイラが備えています。良い意味でも悪い意味でも、コンパイルが通ればそれなりに動くのがJavaプログラムです。さらに、有名なツールにはFindBugsとCheckStyleがあります。どちらも古くからあるツールですが、潜在的なバグや問題をチェックする事が出来ます。自動的に実行するようにIDEやCIサーバを設定しておくことで手間もかかりません。他にもカバレッジ測定ツールやコードの複雑性（メトリクス）の測定ツールなどたくさんのツールもあります。それが共通して提供している事は、ソフトウェアが特定のテストを通っているという安心感です。たくさんのツールを使いこなすには経験が必要ですが、１つづつ導入していけばそれほど難しくありませんので、1プロジェクトに１つ新しいコード分析ツールを導入してはどうでしょう？

プログラマが知るべき97のこと