静的解析とは何ですか？

静的解析とは？

静的解析とは、アプリケーションを実行することなくソースコードを自動的に解析する手法です。

プログラムの実行中に解析を行う場合は、動的解析と呼ばれます。

静的解析は、主に以下の検出に使用されます。

• セキュリティ脆弱性。
• パフォーマンスの問題。
• 標準への非準拠。
• 古いプログラミング構文の使用。

静的解析ツールはどのように機能するのか？

すべての静的解析ツールに共通する基本的な概念は、ソースコードを検索し、警告や情報に関連付けられた特定のコーディングパターンを特定することです。

「JUnit 5のテストクラスはpublicである必要はない」といった単純なものから、「SQL実行文で信頼できない文字列入力が使用されている」といった複雑なものまで特定できます。

静的解析ツールは、この機能を実装する方法がそれぞれ異なります。

• 抽象構文木（AST）を作成するためのソースコード解析技術、
• テキストの正規表現マッチング、
• 上記を組み合わせたもの。

テキストに対する正規表現マッチングは非常に柔軟でルール作成も容易ですが、誤検知が多くなりがちで、周囲のコードコンテキストを考慮できないという欠点があります。

ASTマッチングはソースコードを単なるテキストファイルではなくプログラムコードとして扱うため、より具体的でコンテキストを考慮したマッチングが可能となり、誤検知の数を減らすことができます。

継続的インテグレーション（CI）における静的解析

静的解析は、継続的インテグレーション（CI）プロセスの中で行われることが多く、コンプライアンス違反のレポートを生成します。これをレビューすることで、コードベースの客観的な状態を継続的に把握できます。

静的解析ツールを特定のコード部分のみを測定し、ルールの一部のみを報告するように設定することで、コード品質の客観的な指標として活用するケースもあります。

客観性が保たれるのは、使用されるルールが時間の経過とともに評価基準を変えないためです。もちろん、どのルールをどのように設定するかは主観的な判断であり、チームや時期によって選択されるルールは異なります。

CIで静的解析を行うことは有用ですが、プログラマーへのフィードバックが遅れる可能性があります。コーディング中にフィードバックが得られず、後からツールを実行した際に結果が判明するためです。また、CIで静的解析を実行するもう一つの副作用として、結果が無視されやすくなるという点も挙げられます。

静的解析の結果をチームがより重視するようにするには、ビルドプロセスでしきい値を設定し、ルール違反の件数などがその値を超えた場合にビルドを失敗させるのが一般的です。

IDEでの静的解析

フィードバックを迅速に得るために、多くのIDEプラグインが用意されています。これらを使えば、オンデマンドで、あるいはコードの変更に合わせて定期的に静的解析ルールを実行できます。

ルール違反はプログラミング中にIDE上で確認できます。また、ルールを無視しにくくするために、違反箇所をエディタ上で下線付きで表示するように設定できる場合も多いです。

私個人としては、特に静的解析ツールがカバーしている新しいライブラリを扱う際に、コーディングを改善する有用な手段だと感じています。誤検知や不要なルールによって「ノイズ」が多くなることもありますが、特定のルールを無視するように設定する手間をかけることで解決できます。

静的解析ルールに基づくコードの修正

ほとんどの静的解析ツールでは、ルールの修正はプログラマー自身に委ねられています。そのため、プログラマーはルール違反の原因を理解し、どのように修正すべきかを判断しなければなりません。

静的解析ツール自体が違反を自動修正する機能を備えているケースは非常に稀です。修正内容はチームや使用技術、合意されたコーディングスタイルに大きく依存するためです。

デフォルトルール

静的解析ツールにデフォルトのルールが備わっていると、ツールの品質に対して過信が生じることがあります。プログラマーが遭遇する可能性のあるすべての問題や、ルールが適用されるべきあらゆる状況を網羅していると思い込んでしまいがちですが、ルールを適用すべき状況は時に微妙で、検知が難しい場合もあります。

静的解析ツールを活用し、ルールや違反について詳しく調べることで、プログラマーが自身のドメイン特有の文脈において問題を検知し、回避するスキルを養うことが期待されています。

ドメイン固有のルールが必要な場合、静的解析ツールには該当するルールが存在しないことがあります。さらに、ツールの設定や拡張が難しいことも少なくありません。

懸念点

これらの「懸念点」は、いずれも克服不可能なものではありません。

• 誤検知
• 修正機能の欠如
• ルールを無視するための設定
• コンテキスト固有のルールの追加

しかし、これらは静的解析ツールの導入を避けるための言い訳として使われることがよくあります。静的解析は非常に有用な手段であるため、これは残念なことです。具体的には、以下のような利点があります。

• ジュニア開発者により良いアプローチを提示する
• 明確なコーディング違反に対して迅速なフィードバックを得る
• プログラマーがこれまで遭遇したことのない不明瞭な問題を特定する
• プログラマーが適切なコーディングアプローチを採用していることを裏付ける（違反が報告されない場合）

IDEベースの静的解析ツール

プロジェクトの個人貢献者として、私はIDE内で実行される静的解析ツールを好んで使用しています。これにより、コードに対するフィードバックを素早く得られるからです。

これは、プロジェクトで実施されているプルリクエストのレビュープロセスやCI統合を補完するものです。

私は、自分の強みとなり、個人のワークフローを改善してくれるツールを探すようにしています。

IDE上で動作するツールは、基本的なGUIや設定方法が共通していることが多いため、どれも同じように見えてしまいがちです。

機能やルールセットが重複しているツールもありますが、最大限のメリットを得るために、私は複数のツールを導入してそれぞれの強みを活かすようにしています。

私がコーディング時に実際に使用している静的解析IDEツールは以下の通りです。

• IntelliJ標準のインスペクション - 一般的なコーディングパターン
• SpotBugs - 一般的なエラー
• SonarLint - 一般的な使用パターン
• CheckStyle - 一般的なスタイルパターン
• Secure Code WarriorのSensei - カスタムルールの作成

これらをすべて使用しているのは、互いに補完し合い、うまく連携してくれるからです。

IntelliJインスペクション

IntelliJをお使いであれば、すでにそのインスペクション機能を利用しているはずです。

これらはIDE上で警告を表示する静的解析ルールです。一部のルールには、問題を解決するためにコードを書き換えるクイックフィックス（QuickFix）オプションも用意されています。

ルールはオン・オフの切り替えが可能で、IDE上で強調表示する際のエラーレベルも選択できます。

IntelliJには優れたインスペクションが数多く用意されています。この記事を書くために一通り目を通したことで、その多さを実感しました。私はIntelliJのインスペクションをデフォルト設定のまま使用していますが、その価値を最大限に引き出すには、一通り目を通して自分のコーディングスタイルに関連するものを見極め、警告レベルを設定してコード内で気づけるようにしておくことをお勧めします。

IntelliJインスペクションの素晴らしい点は、IDEに無料で付属しており、以下の習慣を身につけるのに役立つことです。

• コードを書いている最中にソース内の警告やエラーに気づく
• フラグが立てられたコードにマウスを合わせてルール違反の内容を確認する
• alt+enterキーを使って問題に対するクイックフィックスを適用する

SpotBugs

SpotBugs IntelliJプラグインは、静的解析を使用してコード内のバグを警告してくれます。

SpotBugsはIntelliJの設定からコードをスキャンするように構成でき、実際に使用されるルールは「Detector」タブで確認できます。

私は通常、コードを書き終えてレビューした後にSpotBugsを使用し、「Analyze Project Files Including Test Sources（テストソースを含むプロジェクトファイルの解析）」を実行するようにしています。

これにより、バグやデッドコード、明らかな最適化の余地を見つけることができます。また、指摘された違反について調査を強制されるため、どう対処すべきかを判断する助けにもなります。

SpotBugsは問題を見つけてくれますが、それを解決するためのクイックフィックス機能は提供していません。

SpotBugsは設定が簡単で、IDE内で客観的な「第二の意見」として相談できる便利なツールだと感じています。

SonarLint

SonarLint プラグイン。

SonarLintは、IntelliJの環境設定から、コードの検証に使用するルールを選択するように構成できます。

デフォルトでは、SonarLintはリアルタイムで実行され、現在編集中のコードの問題を表示します。

SonarLintはクイックフィックス機能を提供していませんが、違反レポートに関連付けられたドキュメントは通常明確で、詳細に記述されています。

私は以前、新しいJavaバージョンで利用可能な新機能について、SonarLintが警告してくれる機能が役立つと感じていました。

CheckStyle

The CheckStyle plugin offers a mix of formatting and code-quality rules.

CheckStyleプラグインには、「Sun Checks」と「Google Checks」が同梱されています。

これらの定義は、オンラインで簡単に検索できます。

CheckStyleは、プロジェクト独自のルールセットを作成する時間をかけた場合に最大の価値を発揮します。その場合、IDEプラグインをそのルールセットを使用するように構成し、コードをCIにコミットする前にスキャンを実行できます。

CheckStyleは、違反数がしきい値を超えた場合にCIプロセスでビルドを失敗させるプラグインとして非常によく使用されます。

Sensei

Senseiは、抽象構文木（AST）に基づく静的解析を使用してコードを照合し、クイックフィックスを作成します。これにより、問題のあるコードを非常に具体的に特定できます。

ASTを使用することで、レシピに関連付けられたクイックフィックスは周囲のコードを理解できます。例えば、コードに新しいクラスを追加する場合、そのクラスのインポートは置換ごとにではなく、ソースファイルに一度だけ追加されます。

Senseiは、他のツールでは存在しない、あるいは設定が困難なカスタム照合ルールを簡単に作成できるようにするために開発されました。

設定ファイルを修正するのではなく、すべての設定をGUIで行うことができます。新しいレシピを作成する際、GUIを使えばどのコードがレシピに一致するかを簡単に確認できます。また、クイックフィックスを定義する際には、コードの適用前と適用後の状態を即座に比較できます。これにより、チームや技術、さらには個々のプログラマーに固有の、非常にコンテキストに沿ったレシピを簡単に作成できるようになります。

私はSenseiを他の静的解析ツールと組み合わせて使用しています。例えば、ほとんどの静的解析ツールは問題を見つけることはできますが、修正はしてくれません。Senseiの一般的な使用例は、他のツールの照合検索をSenseiで再現し、クイックフィックスで拡張することです。これには、適用されるカスタム修正がプロジェクトのコーディング基準をすでに満たしているという利点があります。

IntelliJのインテンションセットにすでに存在するSenseiレシピを、自分で作成してしまうことが時々あります。これは、インテンションのレポートが私が作成したコンテキストと完全に一致しない場合や、IntelliJが提供するクイックフィックスが使用したいコードパターンと合わない場合があるためです。

私は既存のツールを完全に置き換えようとするのではなく、それらを補完するようにしています。

Senseiは、一般的なルールのコンテキストに応じたバリエーションを特定する場合にも非常に役立ちます。例えば、静的解析ツールがサポートしていないSQLライブラリを使用している場合でも、静的解析エンジンの一般的なSQLルールが適用できるのであれば、Senseiを使用してそのルールのライブラリ固有のバリエーションを作成できます。

Senseiは、前述の静的解析ツールのように汎用的なレシピを多数備えた状態で提供されるわけではありません。その強みは、独自のコーディングスタイルやユースケースに合わせて設定されたクイックフィックス（QuickFixes）を含む、新しいレシピを簡単に作成できる点にあります。

注：現在、一般的なユースケースを網羅したレシピの公開リポジトリを準備中です。こちらからご覧いただけます。

概要

私は、互いに連携でき、設定可能で、特定の状況に合わせて容易に拡張できるツールを選ぶようにしています。IDEで静的解析ツールを長年使用し、問題の特定や、使用するプログラミング言語やライブラリへの理解を深めるのに役立ててきました。

私は、前述のツールをすべて組み合わせて使用しています。

• IntelliJ Intentionsは、一般的なコードの問題を即座に指摘し、多くの場合、関連するクイックフィックスを提示してくれます。
• SpotBugsは、見落としがちな単純なバグを発見し、パフォーマンスの問題を警告してくれます。
• SonarLintは、知らなかったJavaの機能や、コードをモデル化する別の方法を提案してくれます。
• CheckStyleは、CIで強制される合意済みのコーディングスタイルへの準拠を支援します。
• Senseiは、静的解析ツールで見つかった一般的なシナリオを補完するクイックフィックスの作成や、他のツールでは設定が難しい特定のプロジェクトや技術向けのレシピ作成に役立ちます。

---

Senseiのインストールは、IntelliJの「Preferences \ Plugins」（Mac）または「Settings \ Plugins」（Windows）から「sensei secure code」を検索してください。

一般的なユースケースに対応したサンプルコードとレシピのリポジトリは、Secure Code WarriorのGitHubアカウントにある「sensei-blog-examples」プロジェクトで確認できます。

https://github.com/securecodewarrior/sensei-blog-examples

Senseiについて詳しく見る