自分を優れたプログラマーと見なしている場合、レベルを平均以上に評価しているとしましょう。この記事を読まないでください。 この記事は、ソフトウェアプロジェクトマネージャーを対象としています。 彼らと一緒に、静的コード分析の方法論に関連する、重要ではあるがプログラマーにとって退屈な問題について議論したいと思います。
導入によって、少なくとも一部のプログラマーが本を読むことを恐れることを願っています。 おそらく、誰かが原則から読み続けましたが、まあ、これは彼らの自発的な選択です。 プログラマーにとって不快なことについて話します。
当社は、C、C ++、およびC＃プログラムのコードのエラーを検索するように設計されたPVS-Studioアナライザーを開発しています。 アイデアは簡単です。アナライザーを定期的に実行し、疑わしいと思われるコードのセクションを調べます。 一般的に、自動コードレビューの特定の類似物。
高品質のコードが低品質よりも優れていることは、マネージャーにとってもプログラマーにとっても明らかです。 また、プログラムで発生するグリッチが少ないほど良いことも明らかです。
次に最も興味深いものが始まります。 誰もが高品質のコードの重要性を認識していますが、一部のプログラマーは、静的コード分析を使用するように求められると単にsimplyります。 彼らは彼らのプロフェッショナリズムを疑い、in辱されたようであり、彼らは彼らの否定的な批判のすべての武器で答えようと急いでいるようです。 長年にわたって、おおよそ次の内容の膨大な数の世間知らずのレビューを聞いてきました。
- 「これはマクドナルドのツールであり、専門家は私たちのチームで働いています。エラーが発生した場合、それらはスレッドの同期にのみ関連付けられます」
- 「平均以上の専門家のみを採用するため、静的コード分析は使用しません」
そのような議論の時にプロジェクトマネージャーが近くにいたとしたら、多くのプログラマーが彼からクリックして誇りを得ると思います。 各リーダーは、数日間ミスを検索した方法を思い出すことができますが、それは後にある種の馬鹿げたタイプミスであることが判明しました。 または、マネージャーが懐疑的になり始める可能性があります。すべてが大丈夫な場合、アプリケーションが時々クラッシュし続けるのはなぜですか？ マネージャーは、プログラマーがプロジェクトの開発プロセスと新たな問題について考えるほどバラ色ではありません。
図1.プログラマーはしばしば楽観的すぎて、すべてがうまくいくと確信しています。
したがって、私はマネージャーに秘密を明らかにしたいのですが、実際にはもちろん秘密ではありません。 プログラマーは、レベルの再評価に問題があります。 これは、記事「 Programmers 'Above Average' 」（ en ）によく書かれています。 一節を引用するには：
プログラマーとしてのレベルをどのように評価しますか（平均以下、平均、平均以上）？
さまざまなグループの心理調査によると、プログラマの約90％が「平均以上」と答えています。
明らかに、これは真実ではありえません。 100人のグループでは、50が常に高くなり、50が平均を下回ります。 この効果は、優越性の錯覚として知られています。 多くの分野で説明されていますが、聞いたことがあるとしても、 おそらく「平均以上」と答えることでしょう 。
これは、プログラマーが新しいテクノロジーと方法論を習得するのを妨げる問題です。 私たちの場合、静的コード分析に対する前向きな姿勢を妨げます。 プログラマーにとって、あるプログラムがより良いコードの書き方を教えてくれることを理解するのは不快です。 そして、アナライザーが理想的なコードで愚かなエラーを検出し、それらを公開するのは本当に不快です。 あなたの弱点や欠点に気づき、受け入れるには、多くの意志と知恵が必要です。 楽器や技術全般について否定的なレビューを行い、快適で閉じた世界にとどまる方がずっと簡単です。
PVS-Studioアナライザーは 、Qt、MSBuild、LLVM、GCC、GDB、Chromiumなどのプロジェクトのコードでエラーを検出します。 これらのプロジェクトの開発者は、平均以下に評価することはできません。 ただし、これは、より多くの新しいプログラマーが自分のコードが高品質であり、コード分析が彼らに関係がないと答えることを妨げるものではありません。 そのような場合、私は尋ねることが好きです：すべてがそのようなすべてのそのような専門家の周りでとても良いので、誰がこれらの11,000の間違いをしたのですか？ もちろん、この質問は修辞的であり、答えは期待できません。
私はマネージャーが私が得ていることを理解していると思います。 静的分析は、中規模および大規模プロジェクトの開発において非常に重要かつ有用です。 多くのエラーに対処するのに役立ち、開発プロセス全体の品質を制御できます。 定期的なチェックにより、たとえば誰かが気にしないが、仕事の外見を作成する必要があるため、誰かがやめようとするという事実に関連するエラーの数の異常な増加をタイムリーに特定できます。 もちろん、私はこの状況を思いつきましたが、プロジェクトがどれほど優れているかを評価できるツールがあれば非常に便利であり、アナライザーの警告の数はこのための最良の指標の1つです。
ところで、このテーマについて興味深いことをお話しします。 最近、同僚がCryEngine V.プロジェクトをチェックしました。 同僚は高い警告さえ見ませんでした、彼らがたくさんいます。 そして、最近Crytekに問題が発生し、一部のプログラマーが3か月間給料を受け取っていないことが突然わかりました。 会社の不健康な状況は、コードの品質に影響を与えました。 このような明確な関係を見るのは面白かったです。
一般に、プログラマーに静的コード分析の使用を強制することを恥ずかしがらないでください。 PVS-Studioでなくても、少なくともCppcheckであっても （簡単なチェックを実行しますが、無料です）。 それはすでにかなりの量になるでしょう。 もちろん、プログラマは気まぐれである可能性があるため、堅実さを示す価値があります。
多くの場合、プログラマーはアナライザーの操作に時間がかかり、誤った警告を強制的に表示するという事実を引用しています。
ここで私は皮肉から自分自身を抑えることはできません：はい、はい...誤検知の数を減らすためにアナライザーを構成するために1日費やすことはたくさんです。 座って1週間の間違いを探すために、これはちょうどいいです、これは正常です。
証拠 ：検出の失敗に約50時間かかり、アナライザーの1回の起動でエラーが検出され、1時間以内に修正されました。
ところで、古いコードでエラーを見つけることから始める必要がない場合、静的アナライザーを開発プロセスに統合するのは非常に簡単です。 PVS-Studioは、新規または変更されたコードに関連するエラーのみを表示できます（ アナライザーメッセージの大量抑制を参照）。
プログラマーが静的アナライザーを必要としない理由について異議を唱えるのは懐疑的です。 彼らは本当に彼を必要としないかもしれません。 プロジェクトには彼が必要です。 これは、たとえば単体テストと同じ方法論の1つです。これにより、プログラムの信頼性を高め、それにより、メンテナンスのコストを削減できます。 エラーが発見されるのは早ければ早いほど良いです。 静的アナライザーはエラーを早期に検出できます。 コードに現れるとすぐに。
図2.一部のプログラマーは静的分析を誤って使用していることに注意してください。
もう一つの重要なポイント。 一部のプログラマーは、テスト実行中にエラーがほとんど検出されなかったと主張する場合があるため、コードアナライザーの実装は実用的ではありません。 混乱させないでください。 もちろん、デバッグされたコードと動作中のコードにはほとんどエラーがありません。そうでなければ、プログラムは動作しません。 ただし、トラブルシューティングは非常に高価になる可能性があります。 多くの場合、コードアナライザーを1回実行するだけで、多くのユーザーからの苦情やデバッガーでのプログラマーの瞑想の時間は簡単に消えることがあります。 静的分析の全体的なポイントと利点は、1回限りの起動ではなく、定期的な使用です。
何回か私は、一部のプログラマーがリリースに備えて静的アナライザーを実行していると聞きました。 誰かがこれを行い、これが正常であると主張する場合、彼は不適切です。 これは、静的アナライザーを使用する間違った方法です。 これは、リリース前にコンパイラの警告をオンにして、残りの時間はプロジェクトで作業し、それらを完全に無効にすることと同じです。
ご清聴ありがとうございました。 一般的な静的解析方法論、特にPVS-Studioアナライザーに興味のある方は、 ぜひご連絡ください 。 プロジェクトの確認、アナライザーの構成、および発行された警告への対処方法を紹介します。
この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：Andrey Karpov。 プロジェクトマネージャー向けの静的分析に関する投稿。プログラマーにはお勧めしません