チームのやる気を失わずに静的コード アナライザーをレガシー プロジェクトに実装する方法

静的コード アナライザーを試すのは簡単です。 しかし、これを実装するには、特に大規模で古いプロジェクトの開発ではスキルが必要です。 やり方を誤ると、アナライザーは作業を追加し、開発を遅らせ、チームのやる気を失わせる可能性があります。 開発プロセスへの静的分析の統合に適切にアプローチし、CI/CD の一部として静的分析の使用を開始する方法について簡単に説明します。

導入

最近、私の注意が出版物に引き寄せられました。チームに負担をかけずに静的解析を始める"。一方で、これは知っておく価値のある良い記事です。一方で、多くの機能を備えたプロジェクトで静的分析を苦痛なく実装する方法については、まだ完全な答えを提供していないように思えます。この記事には、技術的負債を受け入れて新しいコードのみに取り組むことができると記載されていますが、この技術的負債を後でどうするかについては答えがありません。

私たちの PVS-Studio チームは、このトピックに関する見解を提供します。 そもそも、静的コード アナライザーの実装の問題がどのように発生するのか、この問題を克服する方法、そして技術的負債を苦労せずに徐々に取り除く方法を見てみましょう。

問題

通常、静的アナライザーを起動してどのように動作するかを確認するのは難しくありません。1]。 コード内に興味深いエラーや恐ろしい潜在的な脆弱性が見つかる可能性があります。 何かを修正することもできますが、多くのプログラマーは諦めてしまいます。

すべての静的アナライザーは誤検知を生成します。 これは静的コード分析手法の特徴であり、これについては何もできません。 一般的なケースでは、ライスの定理によって確認されているように、これは解決不可能な問題です [2]。 機械学習アルゴリズムも役に立ちません [3]。 たとえ、このコードまたはあのコードが間違っているかどうかを常に判断できない場合でも、プログラムにそれを期待すべきではありません :)。

静的アナライザーがすでに構成されている場合、誤検知は問題になりません。

• 無関係なルールセットを無効にします。
• 一部の無関係な診断は無効になっています。
• C または C++ について話している場合、マクロは、そのようなマクロが使用されるすべての場所で無用な警告が表示される特定の構成要素を含むようにマークアップされます。
• 独自の関数は、システム関数と同様のアクションを実行するようにマークされています (独自のアナログ memcpy または printf）[4];
• 誤検知はコメントを使用して具体的に無効にします。
• などなど。

この場合、誤検知率は約 10 ～ 15% と低いことが予想されます [5]。 言い換えれば、アナライザーの警告の 9 件中 10 件は、コード内の実際の問題、または少なくとも「強力なコード」を示します。 同意します。このシナリオは非常に快適であり、アナライザーはプログラマーの本当の友達です。

実際、大規模なプロジェクトでは、当初のイメージはまったく異なります。 アナライザーは、レガシー コードに対して数百または数千の警告を発行します。 これらの警告のどれが関連しており、どれがそうでないかをすぐに理解することは不可能です。 この場合、主要な作業が数日または数週間停止することになるため、座ってこれらすべての警告に対処し始めるのは非合理的です。 通常、チームにはそのようなシナリオを受け入れる余裕はありません。 変更履歴を台無しにする膨大な数の差分も存在します。 また、コード内の非常に多くの断片を迅速に大量に編集すると、必然的に新たなタイプミスやエラーが発生します。

そして最も重要なことは、警告との戦いにおいてそのような偉業はほとんど意味がありません。 プロジェクトは長年にわたって正常に実行されてきたため、プロジェクト内の重大なエラーのほとんどはすでに修正されていることに同意します。 はい、これらの修正は非常に高価で、デバッグが必要で、バグなどについてユーザーから否定的なフィードバックを受けていました。 静的アナライザーは、コーディング段階でこれらのエラーの多くを迅速かつ安価に修正するのに役立ちます。 しかし現時点では、何らかの形でこれらのエラーは修正されており、アナライザーは主に古いコード内の重大ではないエラーを検出します。 このコードは使用されない可能性があり、使用されることは非常にまれであり、コード内のエラーが目立った結果につながることはありません。 おそらくボタンの影の色が間違っている可能性がありますが、これは製品の使用を妨げるものではありません。

もちろん、小さな間違いであっても間違いは間違いです。 そして、間違いによって本当の脆弱性が隠れてしまうことがあります。 しかし、すべてを放棄して、ほとんど現れない欠陥に対処するために数日または数週間を費やすのは疑わしい考えのように思えます。

プログラマーは、古い動作コードに関するこれらの警告を見て、見て、見て...そして彼らはこう考えます。静的解析なしで済むのです。 新しい便利な機能をいくつか書いてみましょう。

彼らなりのやり方で、彼らは正しいのです。 彼らは、まずこれらの警告をすべて何らかの方法で取り除く必要があると考えています。 そうして初めて、コード アナライザーを定期的に使用するメリットが得られるようになります。 そうしないと、新しい警告が古い警告に埋もれてしまい、誰も注意を払わなくなります。

これはコンパイラの警告と同じ類似点です。 コンパイラ警告の数を 0 に保つことを推奨するのには理由がないわけではありません。警告が 1000 件ある場合、1001 件になると誰もそれに注意を払わなくなり、この最新の警告をどこで探せばよいのかも明確ではありません。

この話で最悪なのは、現時点で上からの誰かが静的コード分析の使用を強制した場合です。 これはチームのやる気を失わせるだけです。彼らの観点からは、さらに官僚的な複雑さが邪魔になるだけだからです。 誰もアナライザーのレポートを見ることはなく、すべての使用は「紙の上」でのみ行われます。 それらの。 形式的には、分析は DevOps プロセスに組み込まれていますが、実際にはこれは誰にも利益をもたらしません。 カンファレンス参加者からブースで詳しい話を聞きました。 このような経験により、プログラマーは、永久ではないにしても、長期間にわたって静的解析ツールを使用する意欲を失う可能性があります。

技術的負債の導入と解消

実際、大規模で古いプロジェクトであっても、静的解析を導入することは、何も難しいことや怖いことではありません。

CI / CD

さらに、アナライザーを継続的な開発プロセスの一部としてすぐに組み込むことができます。 たとえば、PVS-Studio ディストリビューションには、必要な形式でレポートを簡単に表示するためのユーティリティと、コードの問題のあるセクションを作成した開発者への通知が含まれています。 CI/CD システムから PVS-Studio を起動することに興味がある方は、対応するコマンドをよく理解しておくことをお勧めします。 セクション ドキュメントと一連の記事:

• PVS-Studio がクラウドに移行: Azure Devops
• PVS-Studio がクラウドへ: Travis CI
• PVS-Studio がクラウドへ: GitLab CI/CD
• PVS-Studio がクラウドに移行: CircleCI

しかし、コード分析ツールの実装の最初の段階で大量の誤検知が発生するという問題に戻りましょう。

既存の技術的負債を修正し、新たな警告に対処する

最新の商用静的アナライザーでは、新しいコードまたは変更されたコードに表示される新しい警告のみを調査できます。 このメカニズムの実装は異なりますが、本質は同じです。 PVS-Studio 静的アナライザーでは、この機能は次のように実装されます。

静的分析の使用をすぐに開始するには、PVS-Studio ユーザーが警告を大量に抑制するメカニズムを使用することをお勧めします [6]。 一般的な考え方は次のとおりです。 ユーザーがアナライザーを起動すると、多くの警告が表示されました。 長年にわたって開発されてきたプロジェクトは存続し、開発され、収益を上げているため、レポートには重大な欠陥を示す警告があまり含まれない可能性が高くなります。 言い換えれば、重大なバグは、より高価な方法を使用するか、顧客からのフィードバックのおかげで、何らかの形ですでに修正されています。 したがって、アナライザーが現在検出しているものはすべて技術的負債とみなされる可能性があり、すぐに除去しようとするのは非現実的です。

PVS-Studio に、これらの警告を現時点では無関係であるとみなすように指示することができます (技術的負債は後で保存してください)。そうすれば、警告は表示されなくなります。 アナライザーは、まだ関心のないエラーに関する情報を保存する特別なファイルを作成します。 そして、PVS-Studio は新規または変更されたコードに対してのみ警告を発行するようになりました。 さらに、これらはすべて巧妙に実装されています。 たとえば、ソース コード ファイルの先頭に空の行が追加された場合、アナライザーは実際には何も変更されていないと認識し、沈黙を続けます。 このマークアップ ファイルはバージョン管理システムに入れることができます。 ファイルは大きいですが、頻繁に保存しても意味がないので問題ありません。

これで、すべてのプログラマーには、新規または変更されたコードにのみ関連する警告が表示されるようになります。 したがって、彼らが言うように、翌日からアナライザーを使い始めることができます。 そして、後で技術的負債に戻り、徐々にエラーを修正し、アナライザーを構成することができます。

これで、大規模な古いプロジェクトにおけるアナライザーの実装に関する最初の問題は解決されました。 次に、技術的負債をどうするかを考えてみましょう。

バグ修正とリファクタリング

最も単純かつ自然なことは、大規模に抑制されたアナライザーの警告を分析する時間を確保し、徐々に対処することです。 コード内のエラーを修正する必要がある箇所や、コードに問題がないことをアナライザーに伝えるためにリファクタリングする必要がある箇所があります。 簡単な例:

if (a = b)

ほとんどの C++ コンパイラとアナライザは、実際に書きたかった可能性が高いため、そのようなコードについて不満を抱いています。 (a == b)。 しかし、暗黙の合意があり、これは通常ドキュメントに記載されています。追加の括弧がある場合は、プログラマーが意図的にそのようなコードを作成したと見なされ、誓う必要はありません。 たとえば、診断に関する PVS-Studio ドキュメントでは、 V559 (CWE-481) 次の行は正しく安全であるとみなされることが明確に書かれています。

if ((a = b))

もう一つの例。 この C++ コードでは忘れられていますか? 破る かどうか？

case A:
  foo();
case B:
  bar();
  break;

PVS-Studio アナライザーはここで警告を発行します。 V796 (CWE-484)。 これはエラーではない可能性があります。その場合は、属性を追加してパーサーにヒントを与える必要があります。 [[フォールスルー]] または例えば __attribute__((フォールスルー)):

case A:
  foo();
  [[fallthrough]];
case B:
  bar();
  break;

このようなコード変更ではバグは修正されないと言えます。 はい、これは真実ですが、これには XNUMX つの便利な効果があります。 まず、アナライザー レポートによって誤検知が排除されます。 第 XNUMX に、コードの保守に携わる人々にとってコードがより理解しやすくなります。 そして、これはとても重要です！ これだけでも、コードをより明確にして保守しやすくするために、小規模なリファクタリングを実行する価値があります。 アナライザーは「ブレーク」が必要かどうかを理解できないため、他のプログラマーにとってもわかりません。

バグ修正やリファクタリングに加えて、明らかに誤ったアナライザー警告を特に抑制することができます。 一部の無関係な診断は無効にすることができます。 たとえば、誰かが警告は無意味だと考えています V６０ float/double 値の比較について。 そして、それらを重要で研究する価値があると分類する人もいます[7]。 どの警告が関連していると見なされ、どの警告が関連していないと判断されるかは、開発チームの判断に任されています。

誤ったアラートを抑制する他の方法もあります。 たとえば、マクロ マークアップについては前述しました。 これらすべてについては、ドキュメントで詳しく説明されています。 最も重要なことは、段階的かつ体系的に誤検知に対処することに取り組んでいれば、誤検知には何も問題がないことを理解することです。 興味のない警告の大部分は構成後に消え、実際に慎重な調査とコードの一部の変更が必要な箇所だけが残ります。

また、問題が発生した場合には、クライアントが PVS-Studio をセットアップするのを常に支援します。 さらに、私たち自身が誤った警告を排除し、エラーを修正したケースもありました。8]。 念のため、この拡張協力オプションも可能であることを言及しておきます:)。

ラチェット方式

静的アナライザーの警告を排除することでコードの品質を徐々に向上させる、別の興味深いアプローチがあります。 要するに、警告の数は減少するしかないということです。

静的アナライザーによって発行された警告の数が記録されます。 品質ゲートは、操作数を増やさないコードのみを入力できるように構成されています。 その結果、アナライザーを調整してエラーを修正することによって、アラームの数を徐々に減らすプロセスが始まります。

たとえ少し不正をしたい人が、新しいコードの警告を削除するのではなく、古いサードパーティのコードを改善することによって品質ゲートを通過することに決めたとしても、これは怖いことではありません。 それでも、ラチェットは一方向に回転し、欠陥の数は徐々に減少します。 たとえ自分自身の新たな欠陥を修正したくないとしても、隣接するコードの何かを改善する必要があります。 ある時点で、警告の数を減らす簡単な方法は終了し、実際のバグが修正される時点が来ます。

この方法論は、Ivan Ponomarev による非常に興味深い記事で詳しく説明されています。静的分析をバグの発見に使用するのではなく、プロセスに実装します。」は、コードの品質の向上に興味があるすべての人に読むことをお勧めします。

この記事の著者は、このトピックに関するレポートも作成しています。継続的な静的解析".

まとめ

この記事を読んだ読者が静的解析ツールをもっと受け入れ、開発プロセスに導入したいと思うようになることを願っています。 ご質問がございましたら、いつでもお待ちしております アドバイス 当社の静的アナライザー PVS-Studio のユーザーであり、その実装を支援します。

静的解析が本当に便利で有用であるかどうかについては、他にも典型的な疑問があります。 私は、出版物「開発プロセスに PVS-Studio 静的コード アナライザーを導入する理由」で、これらの疑問のほとんどを払拭しようと努めました。9].

ご清聴ありがとうございました、ぜひお越しください ダウンロード PVS-Studio アナライザーを試してください。

追加のリンク

1. アンドレイ・カルポフ。 PVS-Studio アナライザーが C および C++ コードに対して生成する興味深い警告をすぐに確認するにはどうすればよいですか?
2. ウィキペディア。 ライスの定理.
3. アンドレイ・カルポフ、ヴィクトリア・ハニエワ。 プログラムソースコードの静的解析における機械学習の使用.
4. PVS スタジオ。 ドキュメンテーション。 追加の診断設定.
5. アンドレイ・カルポフ。 EFL コア ライブラリの例を使用した PVS-Studio アナライザーの特性、10 ～ 15% の誤検知.
6. PVS スタジオ。 ドキュメンテーション。 アナライザーメッセージの大量抑制.
7. イワン・アンドリヤシン。 X 線血管内手術の教育用シミュレーターのプロジェクトで静的解析をテストした方法について.
8. パベル・エレメーエフ、スヴャトスラフ・ラズミスロフ。 PVS-Studio チームが Unreal Engine コードをどのように改善したか.
9. アンドレイ・カルポフ。 静的コード アナライザー PVS-Studio を開発プロセスに導入する理由.

この記事を英語圏の読者と共有したい場合は、翻訳リンクを使用してください: Andrey Karpov。 レガシープロジェクトに静的コードアナライザーを導入し、チームの意欲を失わないようにする方法.

出所： habr.com