回答:
何も想定しない
「ああ、私はこのコードが何をしているのか知っている、それでいい」と言うのは魅力的です。しないでください。すべての仮定をテストし、すべてを慎重にステップスルーします。
他の人が言ったように-何も仮定しないでください。これは、コードを記述した場合に特に当てはまります。他のコードをデバッグする場合、コードが初めての場合やコーダーを信頼していないため、速度が低下する可能性が高くなります。あなた自身のコードをデバッグするとき、あなたがそれを正しく書いたと仮定するのは簡単すぎるので、遅くしてください！
デバッグの実際のプロセスの場合：
最初にデバッガーを使用するよりも、ユニットテストとログを最初に追加する方が効率的です。また、単体テストを使用して将来のバグを発生させないという追加の利点が得られ、ロギングは将来のセッションのデバッグに役立ちます。
コードの小さなチャンクをステップオーバーする前に、結果を正確に判断できるかどうかを確認してください。これは何も仮定しないことで飛ぶ傾向がありますが（私はBTWに賛成票を投じました）、経験を積むにつれて、どこを見るかを絞り込むのに役立ちます。
これは些細に聞こえるかもしれませんが、デバッガのニュアンスとホットキーを学びます。デバッガーの速度が遅いため、ステップ実行時に頭が不思議に思うことがあります。マシンに遅れずについていくことができ、マウスを動かしていない場合は、それが役立ちます。
デバッグ中にコードを変更できる場合：
のような：
bool isLessThan5 = a < 5;
bool isGreaterThan10 = a > 10;
if ( isLessThan5 || isGreaterThan10 )
{
// more code here
}
の代わりに：
if ( a < 5 || a > 10 )
{
// more code here
}
何らかの理由で、すべてをデバッグできない場合は、同僚と「ゴムダック」することを学んでください。時には説明する行為が光を放ちます。（わかりました、これは質問のテーマに正確に当てはまらないかもしれませんが、言及するのに十分であると思います）
過去22年間の大半を他の人が書いたコードの保守に費やしたことに基づく2つのこと。
書く傾向があるバグの種類を理解する。
たとえば、私は非常に細心のコーダーなので、コードがコンパイルされると、通常は些細なバグがなくなります。したがって、私のバグは、スレッドのデッドロックのような奇妙で複雑なものになる傾向があります。反対に、ほとんどの些細なバグを書いている友人がいます。C++ forループの最後にセミコロンがあります。そのため、次の行は一度だけ実行されます。
他の人があなたと同じ種類のバグを書いていると思い込まないでください。
バグが私の一種の非常に微妙な奇妙なものであると仮定して、大きなデバッグ銃を引き出すのに時間を無駄にしたことが何回あるかわかりません。セミコロン？" その数年後、私はまず、他の人のコードを見るときに、ささいな、ささいな果物を探しに行きます。
ツールを知ってください。たとえば、Visual Studioのデバッガーには、ブレークポイントのようなTracePointsと呼ばれるすばらしい機能がありますが、コードを停止する代わりに、デバッグ出力にトレースステートメントを挿入します。
デバッガーの使用方法に関する本を読んだり、クラスを受講することを強くお勧めします。いくつかのクラスを受講し、デバッガーとしての私の有効性に大きな違いをもたらしたJohn Robbinsの本をいくつか読みました。
Andreas Zellerによる非常に貴重な本「プログラムが失敗する理由：体系的なデバッグのガイド」をご覧ください。多くの技術、理論、ツールを紹介します。そのうちのいくつかは最先端の研究です。
この本のスライドはオンラインで入手できますが、本自体は読みやすいと思います。
この本は、デバッグを開始するのに役立ち、デバッグについてより科学的に考えるのに役立ちますが、実践に代わるものではありません。パフォーマンスの大幅な改善が見られるまで、10年間の記述とデバッグが必要になる場合があります。私は、30年にわたってUnix向けのプログラミングを行ってきたシニア開発者が、数分であいまいなマルチスレッドまたは並列バグを見つけるのをSunに驚かせたことを今でも覚えています。経験が重要です！