このメモは、主にチームがPVS-Studioコードアナライザーを使用するプロジェクトマネージャーおよびテクニカルマネージャーを対象としています。 このツールには、コマンドで静的アナライザーを使用する効果を追跡する機能があります。 これで、数千ドルで購入したアナライザーが実際に目に見える利益をもたらすことを、数字で上司に証明できます。 しかし、この記事はROIに関するものではないので、心配しないでください。
それでは、静的分析ツールは高価であるという事実以外に何が問題なのでしょうか？ ツールを入手したチームが、その助けによってエラーが修正されることを自慢できるとは限りません。 そして、私たちは私たちのツールの効果的な使用に興味を持っている他の誰よりも多くいます。 クライアントが単にライセンスを購入し、それを棚に置いただけでは満足しません。 結局、顧客の半数以上が来年にライセンスを更新します。 したがって、私たちのタスクは、ライセンスを更新することを決定した人にツールを使用することの有効性を示すことです。
そのため、PVS-Studio 5.27では、プロジェクト検証中にアナライザーによって検出されたエラーの数のグラフを作成することが可能になりました。 この機能の背後にある考え方は非常に簡単です。
- PVS-Studioが生成するすべてのエラーを修正する場合は、時間が経つにつれてスケジュールがゼロになるはずです。
- あなたが古い間違いに我慢する準備ができているが、すべての新しい間違いを支配する準備ができているなら、あなたのスケジュールはあまり大きくならないはずです。
- それ以外の場合、開発者は単にPVS-Studioを使用しません。 残念ながら、私たち（ライセンスの更新は受けられません）とあなた（ライセンスでお金を無駄にしました）の両方です。
コード全体がチェックされるたびに（[ソリューションの確認]コマンド）、アナライザーは小さなXMLファイルを保存し、メッセージの数は％AppData％\ Roaming \ PVS-Studio \ Statisticsフォルダーに記録されます。 PVS-Studioメニューには、分析統計コマンドがあり、統計表示設定ダイアログが開きます。 時間間隔を選択し、興味のあるアナライザーとメッセージの重要性を選択します。 次に、「Excelで表示」ボタンを使用して、マシンにインストールされているMicrosoft Excelが開き、目的のスケジュールが作成されます。
この対話について長い間話すことは意味がありません。すべてはドキュメントに記載されています。 したがって、可能な状況を例で詳しく見てみましょう。
実装後、すべてのエラー（古いものと新しいものの両方）が修正されると、スケジュールはどのようになりますか？
最初の例を考えてみましょう。 同社はPVS-Studioを購入し、実装を開始しました。 一般分析（GA）クラスのエラーに注目してみましょう。スターターにとっては、最も重要で平均的な重要度のみです。 最初の起動時に、PVS-Studioは約1800のメッセージを表示します。 最初に、開発者は最も明らかな誤検知に対処します。 たとえば、マクロで抑制して無効にします。 より簡単で正確なエラー。 時間の経過とともに、メッセージングの速度は少し遅くなります。 そのため、グラフは直線ではなく、アーチ形になっています。エラーはますます少なくなり、最終的には0になります。PVS-Studioエラーに取り組んでいるチームのこのモードを説明するグラフがあります。
図1-最初に、軽微なエラーが修正された後、さらに複雑になり、最後に最も複雑なエラーが残ります。
すべて、すべてのアナライザー操作が解決され、エラーは0が発行されます。 リラックスすることは可能ですか？ いや 実際、リラックスしてアナライザーをさらにオフにすると（新しいエラーを修正しないでください。時間が経つとエラーの数が増え始めます。そのようなグラフの例を図2に示します。
図2-すべてのエラーが最初に修正された後、開発者はリラックスし、アナライザーメッセージへの応答を停止しました。
メッセージの数の増加を示すこのグラフを参照してください？ これは、操作の数をゼロにしたため、開発者が新しいコードのエラーの修正を停止したという事実によるものです。 幸いなことに、プロジェクトマネージャーは間に合い、エラーが修正されなかったことに気付きました。 そのため、プロジェクトのチームと話をした後、再びエラーがなくなりました。 そして、多くが毎日維持されました。
スケジュールに基づいたチームの結果に関する誤った結論の例
さて、図3のグラフはどうですか？
図3-二重解釈のグラフの例。
一見したところ、チームはこぼれたと言っても過言ではなく、エラーの数は増え続けています。 そして非常に強く-その期間の2700から3700まで。 しかし、この結論は、プロジェクトにまったく精通していない人が作成することができます。 人々が何をしているかを知っているなら、それは明らかになります。 大量の新しいコードがプロジェクトに追加されました（新しいプロジェクトファイルは一般的なソリューション.slnに接続されていました）。 そして、そのようなスケジュールには何の問題もありません。 結局、プロジェクトの数はさらに安定し、チームが時間通りに修正し始めてもエラーはそれほど増えません。
このグラフは、統計データを「解釈」することが不可能であるという事実の一例として与えられています。また、チームが何をしているかを理解する必要もあります。
ステップはどこから来ますか？
多くの場合、均一な操作でのグラフの正しいビューは、図4のようなステップに似ています。
図4-ステップチャート
このような段階的なスケジュールは、エラー修正チームの統一された作業を意味するため、最も正確です。 エラーの数が減らない場合に、ステップがどこから来るのかを推測しましたか？ もちろんこれは週末です。
「新規のみ」エラーのグラフは何ですか？
その前に、チームがコードアナライザーが出力するすべてのエラーの修正に取り組んだ例がありました。 しかし、「 質量誤差抑制 」機能の本質は次のとおりです。「さて、古いコードへのPVS-Studioメッセージがたくさんあることはわかっています。 しかし、私たちは彼に目を閉じ、新しいコードでのみエラーを修正したいと考えています。」 この場合、エラーチャートはどのようになりますか？ 図5はこの質問に答えます。
図5-新しいコードのみのエラー数のグラフ。
一見、グラフは混oticとしているように見えますが、それがコードアナライザーを使用した通常のワークフローの外観です。 どういう意味ですか？ Y軸に沿ったスケールに注意してください最大値は8-これは、1日に追加されたエラー（アナライザー操作）の最大数です。 それはたくさんだと言う？ しかし、50人の開発者と900万行のコードで構成されるチームについて話している場合、これは非常に良い結果であることに同意する必要があります。 しかし、さらに重要なことは、これらは翌日に修正されます。
「スケジュールが完璧」になるようにPVS-Studioを使用する適切なシナリオは何ですか？
したがって、「間違った」グラフがどのように見え、「正しい」グラフがどのように見えるかを理解しました。 しかし、PVS-Studioエラーグラフを「正しく」するには、開発プロセスをどのように構築する必要がありますか？ プロジェクトマネージャーまたはテクニカルマネージャーは何を整理すべきですか？最も効果的な結果につながる手順は次のとおりです。
- ビルドサーバーでPVS-Studioを使用して毎日のコード検証を設定します。 これにより、エラー修正プロセスを制御し、簡単に視覚化できる履歴を蓄積できます。
- すべての開発者にPVS-Studioをインストールし、 インクリメンタル分析モードを有効にします。 このモードでは、PVS-Studioは開発者が自分のマシンで修正するファイルを監視します。 そして、コンパイルが成功すると、自動的にチェックします。 エラーが見つかった場合は、もちろん表示されます。 このモードの利点は、開発者が明示的にアナライザーを実行する必要がないことです。 そして、彼からのメッセージを見て、彼はすぐにコードを修正できます。 この場合、エラーのあるコードはバージョン管理システムに入りません。
- それでも、誤ったコードがバージョン管理システムに該当する場合、夜間チェック中に検出されます。 開発者が午前中に夜間に起動した結果のレポートを確認することは非常に重要です。 その後、彼らは間違いを修正できます。 PVS-Studioは、.html形式で見つかったエラーを含むレポートファイルを自動的に生成し、関係者に送信できます。