静的コード分析の本当の利点は何ですか?


18

pc-lintQACなどのツールを使用して、コードベースで静的コード分析を実行できます。

私の経験では、静的解析はしばしば大量のノイズ、つまり実際のバグではないが特定のルールセットのルールの1つに違反するものに関する警告を生成します。特定のルールを無効にする(ルールセットで有効にするか、コード内の特別なコメントを使用する)ことは、本当に面倒なプロセスです。

静的コード分析の本当の利点は何ですか?

回答:


17

Coverity Preventと呼ばれる商用の静的コード分析システムを使用している場所で働いていたのですが、すごいことでした!本当に洗練されていて、インテリジェントです。

オープンソースとプロプライエタリの両方のCおよびC ++コードを約18 GB投じました。コードパスをトレースし、人間を永遠に追跡する微妙なバグをすばやく見つけました。また、通常ハイゼンバグとなるものを正確に特定することもできました。

コードベースに対して数日ごとに実行され、素晴らしい機能は、「これは実際にはバグではない」と伝えることができ、将来的にはそれを覚えていることです。

落とし穴は、コベリティは本当に高価です。彼らはコストを公表していませんが、商業プロジェクトの場合、年間数十万ドルで始まると感じています。しかしおそらく、開発者やQAスタッフを大量に雇う必要がなくなるので、経営陣全体としては良い買い物だと思ったようです。

その経験があったので、静的コード分析を非常に好意的に見ています。


2
コベリティはkLOCによって請求されます。
ポールネイサン

1
kLOCまたはチームサイズ
-StingyJack


7

新しい言語で始めるときは、コーチがいるといいです。それが静的分析ツールの考え方です。私はたくさんのjavascriptを書きますが、最初はいくつかの悪い習慣を取りました。これは主に以前の言語からいくつかのものを転送していたためです。Javascriptは非常に柔軟なので、ほとんど何でも逃げることができますが、特定のパターンについてjslintに警告していた場合、後で再学習するのではなく、最初からより良いコーディングパターンを選んだでしょう。


6

静的アナライザーは、基本的に機械支援のコードレビューです。定期的なテストでは見落とされる可能性のある疑わしい領域を指摘します。

たとえば、著者は本当にこの条件付きで割り当てを行うつもりでしたか?

if (x = 1) {
    ...
}

または、おそらく新人が語彙のキャストを混同します:

char* number = "123";
int converted = number;

確かに静的アナライザーは微調整が必​​要です。さらに、リビジョン管理、Wiki、バグトラッカー、プリティプリンター、その他のツールにもいくつかのセットアップが必要です。プロジェクトが大きくなればなるほど、初期労働に対する報酬は大きくなります。


5

コンサルタントの観点から見ると、すべての静的分析ツールにはノイズがありますが、すべての静的アナライザーが同等に作成されるわけではありません。Coverity、Klocwork、Grammatechなどの静的分析ツールには、より正確な結果を生成する優れた分析手法があります。チューニングと微調整を行うと、通常、より良い結果が得られます(結局、静的アナライザーは、小さな医療機器からネットワークオペレーティングシステムまで、さまざまな種類のコードで実行できる必要があります)。「ノイズ」の定義は、修正に値するレポートを構成する基準にも依存します。スペクトルの一端では、一部の開発者は、修正しないすべてのレポートを「false」とマークします(修正する時間がない貧弱に記述されたコードでも)、もう一方の端では、

これらのツールの中には、より集中的な分析に焦点を当てたものと、デスクトップに焦点を当てたものがありますが、3つすべてが両方をサポートする機能を備えています。@Bobが言及したように、彼らはお金がかかります。


4

私の前の会社では、Parasoftの静的アナライザーを使用しました。また、チーム内では、コンパイル前にランタイムバグの少なくとも60%が検出されたと考えられていました。


2

ソフトウェアコードの手動レビューを実行することで、ツールなしで静的分析を実行することもできます。これは、多くの場合、コード品質を改善する最も費用対効果の高い方法です。

2番目の最良のオプションは、1つ以上のハイエンドの静的解析ツール(前述のCoverityやKLOCworkなど)に投資することです。たとえば、これらのツールはリントよりもはるかに詳細な分析を実行するため、信号対雑音比ははるかに優れています。

ノイズレベルが高いため、3番目のオプションとしてlintを使用することを検討します。既存のプロジェクトに糸くずを適用するのは大変な作業です。

一般に、静的プログラムの分析はここ数年で大きく進歩しました。現在の静的分析ツールは、深い手続き間分析を実行することができ、たとえば、手続きの事前条件と事後条件を自動的に識別することができます。これは、後のコードレビューでも非常に役立ちます。


1

偽陽性率が高いため、コンパイルごとに静的分析ツール(lintやFindBugsなど)を使用しないでください。

むしろ、バグを見つけてそれを理解できない場合に相談するのは良い健全性チェックです。その場合、誤検知を楽しませることができ、エラーの可能性のある原因をすでに絞り込むことができます。たとえば、モジュールを実行しなくてもバグを再現する場合、FindBugsが言っていることは無視できます。これは、コードの一部を見て、1つのことを言っていると考える場合に特に役立ちますが、コンパイラーはそれを文字どおりに読み取ります(Java equalsでの代わりにクラスの型を受け取るメソッドがある場合などObject)。

開発プロセスの一部として静的分析ツールを使用することもできます。開発者がコードレビューを取得したら、その上でFindBugsも実行する必要があります。要するに、便利ですが、コンパイラやテキストエディタほど頻繁には使用しません。


1
私はそれに反対するでしょう。これは逸話であり、古いプロジェクトやより大きなプロジェクトではさらに悪いことになると思いますが、ノイズを整理することはそれほど悪くはありませんでした。私はPC-lintをセットアップして、多くの誤検知を引き起こす多くのトリガーを無視し、より頻繁に実行します(そして、完全に実行する頻度を減らします)。長く待つほど、悪化します!
フレデリック
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.