静的コード分析に関するジョン・カーマック

「最近プログラマーとして行った最も重要なことは、静的コード分析を積極的に適用することです。 -John Carmack 、AltDevBlogADayで公開された記事に書いています。 「防止された数百の深刻なバグはそれほど重要ではありません。考え方やソフトウェアの信頼性とコード品質に対する私の態度の変化ほど重要ではありません。」



ジョン・カーマックは、彼がキャリアの中で使用しようとしたさまざまなツールと、結果として彼が得た結論について語っています。



当初から、カーマックは、コードの品質はソフトウェア開発において最も重要なものではないと規定し、「この事実の認識は、ある種の道徳的敗北ではありません。 価値はあなたが創造しようとしているものであり、品質はコスト、機能性、およびその他の要因とともに、1つの側面にすぎません。 非常に成功し、尊敬されている多くのゲームがあり、バグや絶えずクラッシュしていました。 そのため、スペースシャトルプログラミングスタイルをゲーム開発に適用することは愚かです。 ただし、品質は重要です。」



Quakeエンジンの開発者は、彼の内部的な動機の1つは彼の技術の達人として、彼は絶えず改善しなければならないということだったので、彼は常に良いコードを書くことを試みたと言います。 カーマックは「ポリシー、標準、品質計画」などの「退屈なタイトルの本」を読み、アルマジロエアロスペースと協力して、セキュリティが重要な要素であるソフトウェア開発のまったく異なる世界を知ることができました。



カーマックの静的コード分析ツールの知識は、10年以上前に始まりました。 その後、Quake 3の開発中に、彼はPC-Lintプログラムを購入して試してみました。 しかし、コマンドラインからの起動と生成されたコメントの束を歩き回る必要性はCarmackをまったく喜ばせませんでした。 「私はあきらめ、すぐにPC-Lintを放棄しました」と彼は書いています。



しかし、将来、コードベースが1桁大きくなり、コードがCからC ++に転送されたため、移行プロセス中に新しいエラーが発生する可能性があるため、再検討する必要がありました。 数年前、カーマックは、静的コード分析ツールが長年にわたってどのように変化したかを見ることにしました。



まず、彼はCoverityデモにサインアップしました。これはライセンスコードがコードの行数に依存する深刻なソフトウェアであるため、id Softwareは5桁の数字に達しました。 このプログラムは最良の側面を示し、すぐに100個のエラーで発見されました。 カーマックは、10年で多くの変化があり、ツールが信号対雑音比の点ではるかに効果的になったことにすぐに気付きました。 すべては大丈夫ですが、高価格はまだ怖がっています。



その後、Microsoft / analyzeライブラリをテストしました。これは現在、360 SDKに付属しています。 以前は、このライブラリはVisual Studioの非常に高価なバージョンの一部でしたが、現在ではすべての360所有者が追加料金なしで利用できます。 「マイクロソフトにとって、Xboxのゲームの品質は、Windowsのプログラムの品質よりも重要であると考えています」とJohn Carmackは冗談を言います。



判明したように、Microsoftのユーティリティは、検出されたエラーの数の点でCoverityよりも優れていることが判明しましたが、多数の誤検知も発生しました。 ジョン・カーマックは数か月間働いて、発見されたバグを徐々に修正しました。最初に彼自身のコード、次に別のシステムコード、そしてゲーム部分。 その効果は非常に大きく、一度に忘れられた非常に重要なエラーと、新しいエラーがありました。 / analyzeオプションをオンにして作業することは、誰にとっても必需品であり、開発プロセス中のバグから効果的に保護します。



MicrosoftのツールはXbox 360のコードにのみ使用されていたため、PCとPS3に何を使用するかについては未解決の疑問が残っていました。 次に、Visual Studioと完全に統合され、便利なデモモードを備えたプログラムPVS-Studioを試しました。 /分析と比較して、PVS-Studioは非常に遅いツールであることが判明しましたが、論理的エラーを含むいくつかの追加の重要なエラーを発見しました-/分析のポイントから完全にクリーンなコードでさえ。 PVS-StudioのWebサイトには、検出できるエラーの種類の正確な例が記載された多数の優れた記事があります。



John Carmackは、IDEとの統合のためにVisual Lintと組み合わせて、古き良きPC-Lintに2度目のチャンスを与えました。 古き良きUnixの伝統によれば、このツールはほとんどすべてのタスク用に設定できますが、実際には非常に使いやすいです。 繰り返しますが、/ analyzeとPVS-Studioの両方をチェックした後もきれいなコードでさえ、新しいエラーが見つかりました。 ただし、警告レベルの最も効果的な設定を見つけるという意味では、PC-Lintを使用するのはかなり困難です。



最終的に、ジョン・カーマックはいくつかの結論を出しました。他の開発者に理解することを勧めます。 まず、コードに多くのエラーがあることを誰もが認めなければなりません。 これは、すべてのプログラマが飲み込む必要がある苦い薬です。 第二に、コードの修正は自動化する必要があります。 コードで自動システムが誤ってトリガーされるのを見るのはいいことですが、自動システムのエラーごとに、約12の人的エラーがあります。 「より良いコードを書く」、ペアで作業するなどのアドバイスは、特に数十人のプログラマーが時間が足りない場合、ここではうまくいきません。



Carmackは、PVS-Studioが各更新後に新しいエラーを検出することにも注目しています。 つまり、コードのエラーを最後まで排除することはできません。 大規模なプロジェクトでは、それらは常に物理的材料の特性の統計的偏差のようになります。 マイナスの影響を最小限に抑えることしかできません。



C / C ++での最大の問題は、少なくとも私たちのコードでは、Carmackによると、NULLポインターと、それに続くprintf行形式エラーです。 古いコードの変更中に、多数の重大なエラーが発生します。



そして最後に、John CarmackはTwitterのDave Revellを引用しています。「静的コード分析を使用すればするほど、コンピューターが一般的にロードされることに驚かされます。」



All Articles