デバッグの基本は「問題の切り分け」です。
あるメソッドに 5 つの処理があったとします。そのメソッドで、予期しない例外 (エラー) が発生したとします。当然これは「バグ」ですから修正 (デバッグ) しなくてはなりません。修正 (デバッグ) するにおいて、まず、何をすべきなのでしょう。
えらそーにわざわざ書くまでもなく、5 つのうち、どの処理が原因なのか特定しますよね? これをせずに全体を眺めていては、時間をムダに費やすことにしかなりません。
特定しないまま他人にすべて丸投げする方がいます。これは、自身のスキルを向上する機会を投げ捨てたことになりますし、時間も非常に勿体無いです。特定すれば、(人に聞くより早く) 自己解決できる問題がゴマンとあるからです。
あるグラウンドで 500 円玉を落としたとします。普通の人ならば、自分が歩いた記憶を頼りに、調べる場所を狭めていくでしょう。記憶を無視して、いつまでも広いグラウンド "全体" から 500 円玉を探す人はいないでしょう。また、他人に「グラウンド全体をとにかく探せ!!」と丸投げする人もいないでしょう。
デバッグするためには、まず問題となっている部分を「切り分け」しましょう。これを特定できるのは他ならぬ、コードを目の前にしている貴方自身です。回線の向こうにいる人が予想して特定するものではありません。
有効なのは、以下のような手段です。(当たり前のことばかりで、恐縮ですが)
- 一時的に怪しい部分をコメントアウトして結果を見る
- デバッガがあるのであれば、ステップ実行を行い途中結果を式ウォッチなどで見る
- デバッガがない場合は、途中結果を何かに出力する
- 複雑な場合は、ミニマムコード (最小限のコード) で組みなおす
- 新規でプロジェクトを作成し直して、コードを貼り付ける (構成が原因かどうかの切り分け)
「こんなこと当たり前だ」と思う方が大半なのは知っています。ですが、それをしない方、気付いていない方が、最近増えているようです。今年度の新人教育でも、数人いたくらいですから...
人間は、日常でも無意識のうちに「切り分け」をしています。その日常でトレーニングしているものを、デバッグに使わないのは勿体ないですよね。