静的解析

『Google のソフトウェアエンジニアリング』第20章を読んで理解した内容を、自分の言葉で書き直したもの。本文の引用ではない。節番号は原典を引き直すときの手がかり。

何のために使うか

プログラムを実行せずに潜在的な問題を見つける仕組み。バグ検出だけの道具ではない。

技術的に正しくても使われなければ意味がない。この章の主張はほぼここに集約される。

判定基準を、ツール側の正誤ではなく開発者の行動に置く。

だから、誤検出率が低いツールだけをデプロイする。フィードバックを能動的に集め、それに基づいて実際に手を入れる。これがユーザーの信頼の確立とツールの改善の好循環を作る。

解析自体がどれだけ成果を挙げているかも追跡し続ける。

書籍が挙げている実例が分かりやすい。プロジェクトごとのカスタマイズ機能を全部取り除いたところ、 すぐに「うっとうしい解析結果」への苦情が来た。

有用なシグナルが少なく、役に立つことが稀な解析は、結局無効化される。だから信頼できる結果だけを出すことで信頼の土台を作る方を先にやる。

数十億行のコードベースにスケールすること
編集されたファイル・行についてだけ結果を出すこと
新しく出てきた警告に的を絞ること

既存コード全体の警告を一度に見せない。費用対効果のトレードオフとして設計する。

価値がある
理解できる
行動可能で、修正が容易である

独立したツールとして置かず、普段の流れの中に入れる。 ありふれた問題を自動で目立たせることで、レビュアーの時間を節約できる。

埋め込み先	やること
コードレビュー	変更行についての結果を表示。「役に立たない」ボタンで理由を回収する
修正提案	スタイルの問題は自動修正する。人間のレビュアーの時間の使い道として適切ではない
コンパイラ	チェック結果を警告ではなくエラーとして扱い、ビルドを壊す
エディタ	編集中・閲覧中に出す。ただし解析は1秒未満、理想は100ミリ秒未満

自動的に修正できるものは、すべて自動的に修正されるべき。