デバッグのガイドライン
更新 : 2007 年 11 月
以下のガイドラインでは、コードをデバッグするためのさまざまなテクニックを紹介しています。
必ず行うこと
デバッグ ツールの使い方を身に付ける。
デバッグ ツールについて理解し、正しい使い方を身に付けておく必要があります。詳細については、「Visual Studio でのデバッグ」を参照してください。
シンボルがアーカイブされている場所を知っておく。
すべての製品のシンボルは、必ずシンボル サーバーにアーカイブしてください。後は、シンボル サーバーの場所を確認するだけで済みます。詳細については、MSDN ライブラリの「How to Use the Microsoft Symbol Server」を参照してください。
プロセスをハングさせるバグを調査、解決する。
ユーザーにとって、アプリケーションが応答しなくなる (ハングする) ことは、クラッシュすることと同じぐらい厄介な現象です。どちらの場合も、ユーザーはそれまでの作業を失い、作業を最初からやり直さなければなりません。これまで、ハングは、クラッシュと比べ、調査と解決がより困難であると考えられてきました。現在では、より高い確率でプロセス ハングを調査、解決できるようになっています。最新のツールとテクニックを使用して、これらの問題を解決できます。詳細については、MSDN ライブラリの「How to Troubleshoot Program Faults with Dr. Watson」を参照してください。
ミニダンプを使ったデバッグを身に付ける。
テスト担当者や顧客の大半は、コードがクラッシュしても、デバッガを使ってプロセスにアタッチすることはできません。問題の再現が困難な場合、ミニダンプだけが手掛かりとなります。そのため、ミニダンプを使ったデバッグ手法を身に付けることが必須の条件となります。詳細については、MSDN ライブラリの「Minidump Files」を参照してください。
破損したスタックを復元する方法を身に付ける。
破損したスタックを復元することは、たとえ面倒でも、避けて通ることはできません。実際の現場で発生する障害の多くでは、スタックがほぼ解読不可能な状態まで破損してしまうためです。詳細については、MSDN ライブラリの「Troubleshooting Common Problems with Applications: Debugging in the Real World」を参照してください。
避けるべきこと
テストですべてのバグが見つかると過信する。
テストですべてのバグを見つけることはできません。それは不可能なことです。コードは複雑にできているからです。テストで仮にすべてのバグが見つかったとしても、それらすべてを修正する時間はありません。最も重要なことは、始めからバグが混入しないように製品をデザインすることです。後になってバグを修正する手間をなくすことが大切です。作成するコードの品質に、各自が責任を持つ必要があります。テスト チームの役割は、コードの品質を検証することです。開発者が犯したミスの修正を、テスト担当者に頼らないでください。
お勧めすること
マルチスレッド アプリケーションのデバッグ方法を身に付ける。
プログラムに複数のスレッドを使用した場合、以前には見られなかったような障害が発生する場合があります。シングルスレッド環境でアプリケーションをデバッグするために求められるすべてのことは、スレッドが増えるにつれ重要度を増してきます。たとえば、エラーを常に発生時点でキャッチできるとは限りません。通常、エラーは後になって別のスレッドでキャッチされます。この場合、エラーは別のスレッドで発生し、また、別のスタック上に存在しているため、呼び出し履歴をさかのぼって、問題を見つけることはできません。したがって、できるだけ、そのようなエラーを発生させないように努めることが何よりも重要となります。
リモート デバッグの手法を身に付ける。
リモート デバッグは、他のコンピュータで発生した問題を自分のコンピュータからデバッグする場合に使用します。コードの特定のセグメントが自分のコンピュータでは正常に動作するにもかかわらず、別のシステム上ではクラッシュしてしまうような場合に、開発者がよく使用する手法です。わざわざ他のコンピュータに出向いてデバッグするよりも、他のシステム上で動作するコードをリモートからデバッグできた方が効率的です。詳細については、「リモート デバッグのセットアップ」を参照してください。
ライブ サーバーにおけるデバッグ手法を身に付ける。
顧客がアクセスしているライブ サーバー上でコードをデバッグする場合、通常とは異なるデバッグ手法が必要となります。Web 用に作成されるコードが増えるにつれ、この手法を用いる機会も増加しています。詳細については、MSDN ライブラリの「Troubleshooting Common Problems with Applications: Debugging in the Real World」を参照してください。
すべてのバグ修正にコメントを残す。
バグを修正する際、コードにバージョン番号、バグ ID、および、修正担当者がわかるような名称をコメントとして残すようにします。こうすることにより、後でそのコードを見た第三者が、修正に関する質問をしたいときに、だれに問い合わせればよいかがわかります。
すべてのバグ修正をレビューする。
すべての修正についてコード レビューを実施する必要があります。自分以外の少なくとも 1 人の担当者に、コードをチェックしてもらうようにしてください。
小さなバグ修正はチェックイン前に検証する。
同じバグを 2 回修正することは避けます。特に小さなバグについては、ビルドを使用して、バグ修正が正しく行われているかを検証します。
テスト リリース ドキュメントを通じてすべてのバグ修正を報告する。
テスト チームと連携し、すべてのバグ修正をテスト リリース ドキュメント (TRD) にまとめ、電子メールでテスト チームに送信するようにします。
シンボル サーバーを使用して、製品のシンボルを索引化およびアーカイブする。
シンボル サーバーで製品のシンボルを索引化およびアーカイブすることにより、顧客のシステムを含め、任意のシステムから迅速かつ簡単にデバッグを実行できます。
できれば避けること
他の開発者のバグを本人に通知せずに修正する。
他の開発者のバグを調査し、修正しようと努めること自体は良い心がけです。コードをよりよく理解できる上、他の開発者にとっても、ミスを二重に防ぐことができるというメリットがあります。ただし、他の開発者の問題を修正する場合は、コード作成者本人にそのことを伝えてからチェックインする必要があります。
同じ環境で同じバージョンをテストすることなく "再現不可" としてバグを解決する。
バグの見つかった製品バージョンと同じバージョンにロールバックした上で問題を解決する必要があります。現行バージョンの製品で問題が発生しなかったからといって、バグが修正されたと判断しないでください。必ずしも、それが正しいとは限りません。コードが変更され、偶然バグが見えにくくなっているだけの可能性もあります。問題が再現するまでバグを調査すれば、問題の根本的な原因を突き止め、それを修正することで、どのコンピュータでもバグが再発しないように対策を講じることができます。