静的分析をバグの発見に使用するのではなく、プロセスに実装します。

この記事を書くきっかけとなったのは、静的解析に関する大量の資料がますます私の注目を集めるようになったことでした。 まず、これ PVS スタジオのブログは、オープンソース プロジェクトでツールによって見つかったエラーのレビューを利用して、Habré で積極的に宣伝しています。 最近 PVS-studio が実装されました Javaのサポートそしてもちろん、IntelliJ IDEA の開発者たち (その組み込みアナライザはおそらく今日の Java にとって最も先進的なものです) 離れられなかった.

このようなレビューを読むと、私たちが魔法のエリクサーについて話しているように感じられます。ボタンを押すと、目の前に欠陥のリストが表示されます。 アナライザーが改良されるにつれて、私たちが何の努力もしなくても、より多くのバグが自動的に発見され、これらのロボットによってスキャンされた製品はますます良くなるようです。

しかし、魔法のエリクサーはありません。 「私たちのロボットが見つけられるものは次のとおりです」のような投稿では通常は語られないこと、つまりアナライザーにできないこと、ソフトウェア配信プロセスにおけるアナライザーの本当の役割と位置づけ、そしてアナライザーを正しく実装する方法について話したいと思います。 。

ラチェット (出典: ウィキペディア).

静的アナライザーでは決してできないこと

実用的な観点から見たソースコード分析とは何ですか? ソース コードを入力および出力として提供すると、短時間 (テストの実行よりもはるかに短い) でシステムに関する情報が取得されます。 基本的かつ数学的に克服できない制限は、この方法ではかなり狭いクラスの情報しか取得できないことです。

静的解析では解決できない問題の最も有名な例は次のとおりです。 シャットダウンの問題: これは、プログラムのソースコードから有限時間内にループするか終了するかを判断できる一般的なアルゴリズムを開発することは不可能であることを証明する定理です。 この定理の拡張は次のとおりです ライスの定理これは、計算可能な関数の自明ではないプロパティについて、任意のプログラムがそのようなプロパティを持つ関数を評価するかどうかを決定することは、アルゴリズム的に解決できない問題であると述べています。 たとえば、分析対象のプログラムが、たとえば整数の XNUMX 乗を計算するアルゴリズムの実装であるかどうかをソース コードから判断できるアナライザーを作成することは不可能です。

したがって、静的アナライザーの機能には克服できない制限があります。 静的アナライザーは、たとえば、null 値を許可する言語での「null ポインター例外」の発生など、あらゆる場合に検出したり、「」の発生を判断したりすることはできません。動的型付け言語では「属性が見つかりません」というメッセージが表示されます。 最も高度な静的アナライザーができることは、ソース コードで考えられるあらゆる問題の中で、誇張ではなく大海の一滴ほどの特殊なケースを強調することだけです。

静的分析はバグを見つけることではありません

上記のことから、静的解析はプログラム内の欠陥の数を減らす手段ではないという結論が得られます。 あえて言えば、プロジェクトに初めて適用すると、コード内の「興味深い」場所が検出されますが、プログラムの品質に影響を与える欠陥はほとんど検出されないでしょう。

アナライザーによって自動的に検出される欠陥の例は印象的ですが、これらの例は大規模なコードベースの大規模なセットをスキャンすることによって検出されたことを忘れてはなりません。 同じ原理により、ハッカーは多数のアカウントに対していくつかの単純なパスワードを試す機会があり、最終的には単純なパスワードを持つアカウントを見つけます。

これは静的解析を使用すべきではないという意味ですか? もちろん違います！ また、まったく同じ理由で、新しいパスワードをチェックするたびに、それが「単純な」パスワードの停止リストに含まれていることを確認する価値があります。

静的分析はバグを見つけるだけではありません

実際、分析によって実際に解決される問題はさらに広範囲にわたります。 結局のところ、一般的に静的分析とは、ソース コードが起動される前に実行される検証のことです。 以下にできることをいくつか示します。

• 最も広い意味でのコーディングスタイルをチェックします。 これには、書式設定のチェック、空の括弧や余分な括弧の使用の有無の確認、メソッドの行数や循環的複雑さなどのメトリクスのしきい値の設定など、コードの可読性や保守性を妨げる可能性のあるあらゆるものが含まれます。 Java では、そのようなツールは Checkstyle、Python では flake8 です。 このクラスのプログラムは通常「リンター」と呼ばれます。
• 解析できるのは実行コードだけではありません。 JSON、YAML、XML、.properties などのリソース ファイルは、有効性を自動的にチェックできます (またそうすべきです!)。 結局のところ、ペアになっていない引用符が原因で JSON 構造が壊れていることを、テスト実行時や実行時よりも自動プル リクエスト検証の早い段階で発見する方がよいでしょうか? 適切なツールが利用可能です。 YAMLlint, JSONLint.
• コンパイル (動的プログラミング言語の場合は解析) も静的分析の一種です。 一般に、コンパイラはソース コードの品質に問題があることを示す警告を生成することができるため、無視すべきではありません。
• コンパイルは、実行可能コードをコンパイルするだけではない場合があります。 たとえば、次の形式のドキュメントがある場合、 アスキードクター、それを HTML/PDF に変換する瞬間に、AsciiDoctor ハンドラー (Mavenプラグイン) 内部リンクの破損などの警告を発行できます。 これは、ドキュメントの変更を伴うプル リクエストを受け入れない十分な理由になります。
• スペルチェックも静的分析の一種です。 ユーティリティ スペル ドキュメントだけでなく、C/C++、Java、Python などのさまざまなプログラミング言語のプログラム ソース コード (コメントやリテラル) のスペル チェックも可能です。 ユーザー インターフェイスやドキュメントのスペル ミスも欠陥です。
• 構成テスト (内容については、「構成テスト」を参照)。 この и この reports) は、pytest などの単体テスト ランタイムで実行されますが、実行中にソース コードを実行しないため、実際には静的分析の一種でもあります。

ご覧のとおり、このリストでのバグの検索は最も重要な役割を果たしません。その他はすべて、無料のオープンソース ツールを使用して行うことができます。

プロジェクトでは次のタイプの静的解析のうちどれを使用する必要がありますか? もちろん、多ければ多いほど良いです！ 主なことはそれを正しく実装することです。これについては後で説明します。

多段階フィルターとしての配信パイプラインとその最初の段階としての静的分析

継続的インテグレーションの古典的な比喩は、ソース コードの変更から運用環境への配信まで、変更が流れるパイプラインです。 このパイプラインの標準的なステージのシーケンスは次のようになります。

1. 静的解析
2. 編集
3. 単体テスト
4. 統合テスト
5. UIテスト
6. 手動チェック

パイプラインの N 番目のステージで拒否された変更は、ステージ N+1 には転送されません。

他の方法ではなく、なぜまさにこの方法なのでしょうか? パイプラインのテスト部分では、テスターはよく知られたテスト ピラミッドを認識します。

テストピラミッド。 ソース： 記事 マーティン・ファウラー。

このピラミッドの最下位にあるのは、記述が簡単で、実行が速く、失敗する傾向のないテストです。 したがって、より多くのコードが存在し、より多くのコードをカバーし、最初に実行される必要があります。 ピラミッドの頂点ではその逆となるため、統合テストと UI テストの数は必要最小限に減らす必要があります。 このチェーン内の担当者は最も高価で、時間がかかり、信頼性が低いリソースであるため、最後尾にいて、前の段階で欠陥が見つからなかった場合にのみ作業を実行します。 ただし、テストに直接関係しない部分のパイプラインの構築にも同じ原則が使用されます。

多段階の水ろ過システムの形で例えてみたいと思います。 汚れた水（欠陥のある水）が入力に供給されますが、出力では、不要な汚染物質がすべて除去されたきれいな水を受け取る必要があります。

多段フィルター。 ソース： ウィキメディア·コモンズ

ご存知のとおり、洗浄フィルターは、後続の各カスケードでより微細な汚染物質を濾過できるように設計されています。 同時に、より粗い精製のカスケードは、より高いスループットとより低いコストをもたらします。 これは、入力品質ゲートがより高速で、開始に必要な労力が少なく、操作自体もより気取らないことを意味します。これが、入力品質ゲートが構築される順序です。 私たちが今理解しているように、最も重大な欠陥のみを取り除くことができる静的分析の役割は、フィルター カスケードの最初の「泥」グリッドの役割です。

「泥フィルター」では水を飲料に適さないのと同じように、静的分析だけでは最終製品の品質は向上しません。 しかし、パイプラインの他の要素と組み合わせると、その重要性は明らかです。 多段フィルターでは、出力段は入力段のすべてを捕捉できる可能性がありますが、入力段を使用せずに精密精製段だけで対応しようとすると、どのような結果が生じるかは明らかです。

「マッド トラップ」の目的は、後続のカスケードで重大な欠陥が発生するのを防ぐことです。 たとえば、コード レビューを行う人は、少なくとも、間違った形式のコードや確立されたコーディング標準への違反 (余分な括弧や深すぎる分岐など) に気を取られてはなりません。 NPE のようなバグは単体テストで検出する必要がありますが、テスト前であってもアナライザーがバグが確実に発生することを示していれば、修正が大幅に迅速化されます。

静的解析を時々使用しても製品の品質が向上せず、重大な欠陥を伴う変更を除外するために常に使用する必要がある理由が明らかになったと思います。 静電気分析装置を使用すると製品の品質が向上するかどうかという質問は、「汚れた池から取られた水をザルに通したら飲料の品質は向上しますか?」と尋ねることとほぼ同じです。

レガシープロジェクトへの実装

重要な実践的な質問: 静的分析を「品質ゲート」として継続的統合プロセスに実装するにはどうすればよいでしょうか? 自動テストの場合、すべてが明白です。一連のテストがあり、そのいずれかが失敗した場合でも、アセンブリが品質ゲートを通過していないと考える十分な理由になります。 静的解析の結果に基づいて同じ方法でゲートをインストールしようとすると失敗します。従来のコードには解析警告が多すぎるため、それらを完全に無視する必要はありませんが、製品の出荷を停止することもできません。アナライザーの警告が含まれているからです。

初めて使用すると、アナライザーはプロジェクトに関して膨大な数の警告を生成しますが、その大部分は製品の適切な機能とは関係ありません。 これらのコメントすべてを一度に修正することは不可能であり、多くは必要ありません。 結局のところ、私たちは静的解析を導入する前から、製品全体が機能することを知っています。

その結果、多くは静的解析を時折使用するか、アセンブリ中にアナライザ レポートが発行されるだけの情報モードでのみ使用することに限定されています。 これは、分析が行われていないことと同じです。すでに多くの警告がある場合、コードを変更するときに別の警告が (どれほど深刻であっても) 発生しても気づかれないからです。

品質ゲートを導入する次の方法が知られています。

• 警告の合計数、または警告の数をコード行数で割った値に制限を設定します。 このようなゲートでは、制限を超えない限り、新しい欠陥を伴う変更が自由に通過できるため、この方法はうまく機能しません。
• 特定の時点で、コード内のすべての古い警告が無視されるように修正され、新しい警告が発生したときにビルドが拒否されます。 この機能は、PVS-studio および一部のオンライン リソース (Codacy など) によって提供されます。 私には PVS スタジオで作業する機会がありませんでした。Codacy での経験から言えば、主な問題は、何が「古い」エラーで何が「新しい」エラーであるかを判断するのはかなり複雑なアルゴリズムであり、常に機能するとは限らないことです。特にファイルが大幅に変更されたり名前が変更されたりした場合は、正しく実行されます。 私の経験では、Codacy はプル リクエスト内の新しい警告を無視することができましたが、同時に、特定の PR のコードの変更に関連しない警告が原因でプル リクエストを通過できませんでした。
• 私の意見では、最も効果的な解決策は、この本で説明されているものです 連続放出 「ラチェット方式」。 基本的な考え方は、静的解析の警告の数は各リリースのプロパティであり、警告の総数を増やさない変更のみが許可されるということです。

ラチェット

これは次のように機能します。

1. 初期段階では、アナライザーによって検出されたコード内の警告のリリース数に関する記録がメタデータに作成されます。 したがって、アップストリームをビルドするとき、リポジトリ マネージャーは単に「リリース 7.0.2」ではなく、「7.0.2 個のチェックスタイル警告を含むリリース 100500」と書きます。 高度なリポジトリ マネージャー (Artifactory など) を使用している場合は、リリースに関するメタデータを簡単に保存できます。
2. 各プル リクエストは、ビルド時に、生成された警告の数と現在のリリースで利用可能な警告の数を比較します。 PR によってこの数値が増加する場合、コードは静的分析の品質ゲートを通過しません。 警告の数が減少するか変化しない場合は合格です。
3. 次のリリースでは、再計算された警告の数がリリース メタデータに再度記録されます。

したがって、少しずつ、しかし着実に（ラチェットが機能するときのように）、警告の数はゼロになる傾向があります。 もちろん、新しい警告を導入して他の人の警告を修正することで、システムをだますことはできます。 長距離では結果が得られるため、これは正常です。警告は、原則として個別にではなく、特定のタイプのグループで一度に修正され、簡単に削除できる警告はすべて非常に迅速に削除されます。

このグラフは、このような「ラチェット」を XNUMX か月間操作した場合の Checkstyle 警告の合計数を示しています。 私たちのオープンソース プロジェクトの XNUMX つ。 警告の数は一桁減りましたが、これは製品開発と並行して自然に起こったことです。

私はこの方法の修正バージョンを使用し、プロジェクト モジュールと分析ツールごとに警告を個別にカウントします。その結果、次のようなビルド メタデータを含む YAML ファイルが作成されます。

celesta-sql:
  checkstyle: 434
  spotbugs: 45
celesta-core:
  checkstyle: 206
  spotbugs: 13
celesta-maven-plugin:
  checkstyle: 19
  spotbugs: 0
celesta-unit:
  checkstyle: 0
  spotbugs: 0

高度な CI システムでは、プラグインやサードパーティ ツールに依存せずに、ラチェットを静的分析ツールに実装できます。 各アナライザーは、分析しやすい単純なテキストまたは XML 形式で独自のレポートを作成します。 残っているのは、CI スクリプトに必要なロジックを記述することだけです。 Jenkins と Artifactory に基づいたオープンソース プロジェクトでこれがどのように実装されているかを確認できます。 ここで または ここで。 どちらの例もライブラリに依存します ラチェットリブ： 方法 countWarnings() 通常の方法で Checkstyle と Spotbugs によって生成されたファイル内の XML タグをカウントします。 compareWarningMaps() は同じラチェットを実装し、いずれかのカテゴリの警告数が増加するとエラーをスローします。

「ラチェット」の興味深い実装は、aspell を使用してコメント、テキスト リテラル、およびドキュメントのスペルを分析するために可能です。 ご存知のとおり、スペル チェックの際、標準辞書にない単語がすべて間違っているわけではなく、ユーザー辞書に追加される可能性があります。 プロジェクトのソース コードの一部にカスタム辞書を作成する場合、スペル品質ゲートは次のように定式化できます: 標準辞書とカスタム辞書を使用して aspell を実行する すべきではない スペルミスは見つかりませんでした。

アナライザーのバージョン修正の重要性について

結論として、注意すべき点は、配信パイプラインに分析を実装する方法に関係なく、アナライザーのバージョンを修正する必要があるということです。 アナライザーの自発的な更新を許可すると、次のプル リクエストを組み立てるときに、コードの変更とは関係なく、新しいアナライザーが単により多くの欠陥を検出できるという事実に関連した新しい欠陥が「ポップアップ」する可能性があります。これにより、プル リクエストを受け入れるプロセスが中断されます。 アナライザーのアップグレードは意識的に行う必要があります。 ただし、各アセンブリ コンポーネントのバージョンをしっかりと固定することは一般に必要な要件であり、別の議論の対象となります。

所見

• 静的分析ではバグは検出されず、単一のアプリケーションの結果として製品の品質が向上することもありません。 品質にプラスの効果をもたらすには、納品プロセス中に継続的に使用する必要があります。
• バグの発見は分析の主なタスクではありません。便利な機能の大部分はオープンソース ツールで利用できます。
• レガシーコードの「ラチェット」を使用して、配信パイプラインの最初の段階で静的分析の結果に基づいた品質ゲートを実装します。

リファレンス

1. 連続放出
2. A. ク​​ドリャフツェフ: プログラム分析: 自分が優れたプログラマーであることを理解する方法 コード分​​析のさまざまな方法 (静的だけではない!) についてレポートします。

出所： habr.com