チーム開発における静的コード分析の定期的な使用

9月頃にIntel Parallel Studio 2011に含まれるAdvisorという名前のIntelからの静的アナライザーのリリースを見越して、静的コード分析の技術とそのアプリケーションについて一般的に話すことは有益です。 ロシアでの経験によれば、静的解析はあまり使用されないという事実です。これは、明らかに複雑なソフトウェアプロジェクトがそれほど多くないためです。 したがって、それが何であり、誰に役立つかについての短いテキストは、私がそれが役に立つことを願っています。 さて、PVS-Studioアナライザーの作成者以外にこのテキストを実行する必要があるのは誰ですか？ :-)

注釈

静的コード分析技術は、成熟したソフトウェア開発プロセスを持つ企業で使用されています。 ただし、開発プロセスにおけるコード分析ツールのアプリケーションと実装のレベルは異なる場合があります。 「随時」のアナライザーの手動起動から開始するか、微妙なエラーを検索するときに開始し、バージョン管理システムに新しいソースコードを追加するときに毎日の自動起動または起動で終了します。



この記事では、チーム開発で静的コード分析のテクノロジーを使用するさまざまなレベルについて説明し、プロセスをあるレベルから別のレベルに「転送」する方法を示します。 例として、この記事では著者が開発したPVS-Studioコードアナライザーを使用します。

はじめに

静的コードアナライザーは、ソースコード内のソフトウェアエラーを見つけるためのツールです。 このようなツールを使用すると、テストや使用の段階ではなく、開発段階でのソフトウェアエラーの検出を回避できます。



ただし、企業はそのようなツールから常に利益を得ることができるとは限りません。 この理由は非常に異なります。 一部のプロジェクトは、コードアナライザーの実装に経済的に適していないだけであり、一部のプロジェクトは、効果が顕著になるほど大きくありません。 したがって、静的コード分析を開発プロセスに導入する前に、いつ静的コード分析が役立つのか、そうでないのかを理解する必要があります。



著者の経験に基づいて（独自の静的コードアナライザーの開発、販売促進、販売に関与）、開発プロセスでこのようなツールを実装する際に従うべき主な考慮事項を定式化します。

静的コード分析とは何ですか？

静的コード分析は、ソースコードを解析し、その中の既知のエラーのパターン（テンプレート）を検索することにより、プログラム内のエラーを見つけるための技術です。 このテクノロジーは、静的コードアナライザーと呼ばれる特別なツールによって実装されます。



「静的」という語は、実行のためにプログラムを実行せずにコードが解析されることを意味します。 実行中にプログラムを分析するツールは、動的コードアナライザーと呼ばれます。



最も有名な静的アナライザーは、Gimpel Software、Klocwork、Coverityによって製造されています。 人気のある動的アナライザーは、Intel（Intel Parallel Inspector）およびMicro Focus（DevPartner Bounds Checker）によって作成されています。 また、記事の著者が携わっている開発とプロモーションについては、専用の静的コードアナライザーPVS-Studioに言及する必要があります。



静的アナライザーの動作の結果は、ファイル名と特定の行を含むコードで検出された潜在的な問題のリストです。 言い換えると、これはエラーのリストであり、コンパイラが生成するエラーと非常に似ています。 ここでは、「潜在的な問題」という用語は偶然使用されません。 残念ながら、静的アナライザーは、コード内のこの潜在的なエラーが実際の問題であるかどうかを断言することはできません。 これを知ることができるのはプログラマだけです。 したがって、悲しいかな（そしてこれは避けられない）、コードアナライザーは誤検知を与えます。



静的コード分析用のツールは、サポートされているプログラミング言語の種類（Java、C＃、C、C ++）、診断された問題（汎用アナライザー、または64ビットまたは並列プログラムの開発用など）によって分類されます。

静的コード分析に関連するプロジェクト

静的コード分析は、すべてのプロジェクトではなく、中規模および大規模プロジェクトでのみ使用することをお勧めします。 小/中/大プロジェクトとして何を検討するかについての議論は明らかにこの記事の範囲を超えていますが、私たちの経験から、30人月を超えるプロジェクトで静的分析を使用することを検討することをお勧めします。 ソフトウェアプロジェクトが指定されたサイズよりも小さい場合は、静的分析を使用する代わりに、プロジェクトに資格のある複数の開発者がいれば十分です。 2〜4人の資格のある従業員のチームがこのようなプロジェクトを完全に引き出し、プログラムの観点から定性的にそれを行うことができます。 しかし、より多くの人がプロジェクトに取り組んでいる場合、またはプロジェクトが6か月以上続く場合は、「エラーなしで作成するだけでよい」と考えれば十分です。

静的コードアナライザーの使用のバリエーション（シナリオ）

開発チームが静的コード分析を使用する必要がある状況を考慮してください。 ここでは、静的分析が開発プロセス中にのみ表示される場合、ケースが意図的に考慮されます-静的分析が長い間実装され使用されている場合、実装の問題を議論する意味がないためです。



したがって、5人のチームが64ビットコンピューターで動作するソフトウェアプロジェクトのコードの転送に関与しているとします。 また、プロジェクトコードはC / C ++で記述されていると仮定します。 この例では、PVS-Studioコードアナライザーを使用するために、そのような前提条件が作成されていることを事前に言います。 開発者は、主なコンパイルエラーを修正し、アプリケーション、配布キットを組み立てました。 彼らはテストを開始し、プログラムには非常に不可解なエラーがあり、それがプログラムの64ビットバージョンにのみ現れることを発見しました。 開発者はGoogleにアクセスし、「++問題のある64ビットプラットフォーム」を紹介し、最初のページの850万件の結果から、記事「64ビットプラットフォームでのC ++コードの移植に関する20の問題」（ロシア語版では「20トラップC ++コードを64ビットプラットフォームに移植する））、64ビットバージョンのプログラムを開発するときにC / C ++アプリケーションで何が起こるかを学習し、これまでに目に見えないさまざまな問題が発生します。 そこで彼らは、これらの問題を見つけて修正できるPVS-Studioツールがあることを学びます。 次に、開発者はツールをダウンロードし、評価版を見て、それが自分に合っている場合、ライセンスを購入し、ツールを使用してコード内のエラーを見つけて修正し、プログラムをエラーなしにします。 その後、開発者は、64ビットバージョンのプログラムを作成する作業を完了したと見なし、アナライザーの使用を拒否します。



これに近い別のシナリオ。 Javaアプリケーションの開発中に、5人の開発者のチームがサードパーティモジュールの1つでエラーに遭遇しました。 残念ながら、「目」でコードのエラーを見つけることはできませんでした。開発者はJava用のコードアナライザーの試用版をダウンロードし、このサードパーティモジュールでエラーを見つけて修正しましたが、ツールのライセンスを購入しませんでした-プロジェクト予算制限 エラーが修正され、アプリケーションがリリースされ、ツールのライセンスに違反することはありません。 すべてが正常なように見えますが、静的アナライザーを使用するこのオプションは正しいとは言えません。



3番目のユースケース。 開発者はVisual Studio Team Foundation Serverの使用に切り替えました。このバージョンでは、バージョン管理システムに追加されたファイルのコード分析を実行できます。 数週間後、新しいコードを追加するとゲームに「ファイルを追加できるようにアナライザーを説得する」ようになったため、開発者はコードチェックをオフにしました。



これら3つのユースケースはすべて、静的解析を使用する良いケースではありません。 これは、最初の2つのケースではアナライザーがコード内の実際のエラーを見つけるのに役立ち、3番目のケースではプログラマーのコードは明らかに率直に悪いという事実にもかかわらずです。 これらの失敗の理由は何ですか？

静的コードアナライザーの完全使用を妨げるもの

静的解析を使用する上記の3つのオプションが成功例ではない理由を示します。



チームが（64ビットコードの問題を検索するために説明したケースのように）特殊なコードアナライザーを使用する場合、問題が見つかって修正されたと思われる後、ツールを放棄することは非常に魅力的です。 実際、ソフトウェア製品の64ビットバージョンがリリースされた場合、特別なツールをさらに使用しても意味がないように思われるかもしれません。 しかし、これはそうではありません。 このようなアナライザーの使用を拒否すると、新しいコードで既に（数か月後）既にコードアナライザーを使用して検出できるエラーが発生します。 つまり、アプリケーションの64ビットバージョンが存在し、（一度）デバッグされたが、新しいコードには64ビットアプリケーションに固有のエラーが含まれる場合があります。 最初のユースケースの結論は、主な作業が終了した後、このタイプの新しいソフトウェアエラーの出現につながる、特殊なコードアナライザーの拒否です。



説明した2番目のケースでは、プロジェクトで検出が困難なエラーの存在が明らかになった場合にのみ、チームは専用ツールを使用することにしました。 そして、これらのエラーを修正した後、チームはツールを放棄しました。 このアプローチの問題は、検出が困難なエラーが遅かれ早かれプロジェクトに表示されることです。 しかし、おそらく、最初は、開発者やテスターではなく、ユーザーに表示されるようになるでしょう。 2番目のユースケースの結論は最初の結論と一致します。ツールを拒否すると、間違いなく検出が困難なエラーが発生します。



3番目のユースケースでは、バージョン管理システムに新しいコードを追加するのが困難であるため、コードを追加するときに静的分析を中止することが決定された場合、問題は一般的に静的アナライザーではなく、コマンドのレベルが不十分であることになります。 第一に、チームはツールを設定できなかったため、そのメッセージは有用でした。 そして、第二に、アナライザーが多くの診断メッセージを発行したため、コードは明らかにあまり良くありませんでした。



そのため、作業中に静的コード分析ツールを常に使用することを妨げる主な問題を定式化します。

1. コード分​​析ツールの価格が高いため、小規模（主に予算内）プロジェクトでこれらのツールを使用することはできません。 静的解析が技術的ではなく経済的な理由で適切でないプロジェクトがあることを理解する必要があります。
2. コード分​​析ツールは多くの誤検知をもたらします。 残念ながら、どのコードアナライザーも誤検知を引き起こし、多くの場合それを引き起こします。 ここでの理由は、そのようなツールの哲学にあります。 1つの本物を見逃すよりも、10から100の誤ったメッセージを伝える方が良いです。 一部のアナライザーが誤検知をほとんど生成しないことを期待する価値はありません。 誤検知を処理する機能を何らかの形でサポートするツールを選択することをお勧めします。 たとえば、当社のPVS-Studioアナライザーには、「誤警報としてマーク」機能が含まれています。 その助けを借りて、アナライザーの誤検知をコード内で直接マークできます。 つまり、アナライザーがそのような行でこのようなメッセージを生成しないことを示します。
3. 開発環境への不十分な統合。 コード分​​析用のツールが開発環境にスムーズに「シームレスに」統合されていない場合、定期的に使用される可能性は低くなります。
4. コマンドラインを使用した自動起動の欠如。 これにより、毎日のビルド中など、プロジェクトコード全体を定期的に分析することはできません。
5. バージョン管理システムとの統合の欠如。 前述の例では、バージョン管理システムに新しいコードを追加するときに新しいコードをチェックすることは、そのようなツールを使用することの拒否の役割を果たしましたが、そのような統合の可能性は非常に役立ちます。
6. コードアナライザーの設定が複雑すぎる、またはその逆。

ここでの解決策は、静的コード分析の技術を使用したい企業と、これらの技術を提供する企業との相互作用です。 つまり、「楽器を購入して使用する」というカテゴリの関係は、「ソリューションを購入して実装し、それを使用するだけ」というカテゴリに渡されます。 好むと好まざるとにかかわらず、ほとんどの場合、「プログラムアナライザー」を購入してそれを使用して利益を得ることはできません。 社内の開発プロセスを「強化」し、静的分析のソリューションプロバイダーとともに、継続的な通常のチーム開発プロセスで提供するツールを実装する必要があります。



CoverityやKlocworkなどの静的分析のマーケットリーダーは、このスキームに従って機能します。 これには、おそらく、完全に明確な外部症状はありません。 これらの企業は、少なくともある種の試用版をサイトから入手するのはそれほど簡単ではありません。 そして、セールスマネージャーがクライアントに関する最大限の情報を見つけるまで、「費用はいくらですか」という質問に対する答えを得ることができません。

おわりに

会社で静的コード分析の使用を計画している場合は、次のことを考慮してください。

1. 静的コード分析の実装は、開発プロセス全体に影響します。
2. 静的アナライザーは、サプライヤとの対話なしで購入して使用できる小さなユーティリティまたはWindowsの通常のコピーではありません。 アナライザーの開発者と密接に通信する必要があるという事実を常に期待し、ツールの実装手順には時間と労力がかかります。
3. 静的アナライザーは、チームのソフトウェア開発の全体的な文化を強化しますが、それはチーム自体がこの増加に対応できる場合のみです。 つまり、これは相互のプロセスです。
4. 静的コードアナライザーを使用して開発文化を改善することは、費用のかかるプロセスです。 そのための準備をし、これには相当な投資が必要になることを理解する必要があります。