はじめに
・ブレークポイントを置いているのに原因が分からない
・処理を追っているだけで終わる
・気付いたら大量のブレークポイントが増えている
👉 こんな経験ありませんか？
新人の頃や、新しい現場に入ったばかりの頃によくある話です。
実際に私も、
・新人の方
・新しく現場に入った方
のデバッグを見る機会があります。
その中でよく見かけるのが、
👉 ブレークポイントをたくさん置いている
状態です。
でも話を聞いてみると、
👉 ブレークポイントの使い方が悪いわけではない
ことがほとんどです。
多くの場合、
👉 「何を知りたいのか」が整理できていない
まま調査を始めています。
その結果、
処理は見ているのに原因に辿り着けない
という状態になります。
パターン① 処理の流れが分からない
新人や新しい現場で最も多いパターンです。
例えば、
・このボタンを押したらどこが動くのか分からない
・どの順番で処理が流れているのか分からない
・どのクラスを通るのか分からない
すると、
知っている場所へ片っ端からブレークポイントを置き始めます。
・View
・ViewModel
・Service
・API呼び出し
などです。
目的は、
👉 原因調査
ではありません。
👉 処理の流れを知りたい
のです。
これは悪いことではありません。
ただし、
最近のシステムは
・イベント
・非同期処理
・通知処理
などが多く、
ブレークポイントだけで流れを理解しようとすると、
逆に迷子になりやすくなります。
まずは、
・処理の入口
・どこへ繋がるか
・どこで分岐するか
を理解することが重要です。
もし、
👉 処理の流れ自体が分からない
場合は、まず以下の記事がおすすめです。
パターン② 何が問題なのか分からない
これも非常に多いです。
例えば、
👉 画面に名前が表示されない
という現象が起きたとします。
ここで、
とりあえず処理を最初から追い始める人がいます。
でも、
まず考えるべきなのは、
👉 何が問題なのか
です。
例えば、
原因候補としては、
① 値が取得できていない
② 値は取得できているが画面へ渡せていない
③ 条件分岐で表示処理に入っていない
④ そもそも表示処理が呼ばれていない
などが考えられます。
まずは、
👉 原因候補を洗い出す
ことが大切です。
その上で、
①を確認する
②を確認する
③を確認する
④を確認する
という順番で潰していきます。
ここまで整理できれば、
ブレークポイントを置く場所も自然と決まります。
例えば、
①なら値取得箇所
②なら値設定箇所
③なら条件分岐箇所
④なら処理の入口
を確認すればよいからです。
つまり、
👉 ブレークポイントを置く前に
👉 何を確認したいのか
を決める必要があります。
もし、
👉 どこが値取得箇所なのか分からない
👉 処理の入口が分からない
という場合は、
まず処理の流れを理解するところから始めてみてください。
パターン③ 原因の場所を勘違いしている
例えば、
NullReferenceException が発生した。
すると、
エラーになった場所ばかり見てしまいます。
でも実際には、
もっと前の処理で値が設定されていなかった。
というケースもよくあります。
つまり、
症状が出た場所
≠
原因が発生した場所
です。
特に、
・null
・データ不整合
・画面表示異常
などは、
かなり前の処理が原因になっていることも少なくありません。
この場合は、
「どこでエラーになったか」
ではなく、
「どこで原因が作られたか」
を追う必要があります。
つまり、
👉 その値が作られた場所
👉 その値が変更された場所
を確認する必要があります。
そして、
そこへブレークポイントを置いて確認します。
もし、
👉 その値がどこで作られたか分からない
👉 どこで変更されたか分からない
場合は、
まず処理の流れを整理するところから始めてみてください。
解決しなかった場合はどうする？
原因候補を考えた。
検証した。
それでも分からない。
そんな時は相談しましょう。
ただし、
「分かりません」
だけではなく、
例えば、
・値取得失敗を疑った
→ 問題なし
・条件分岐を疑った
→ 問題なし
・表示処理未実行を疑った
→ 問題なし
でも現象は発生している
という形で伝えると、
先輩も状況を理解しやすくなります。
相談の質も大きく変わります。
まとめ
ブレークポイントを置いているのに原因が見つからない人は、
次のどれかに当てはまることが多いです。
① 処理の流れが分からない
② 何が問題なのか分からない
③ 原因の場所を勘違いしている
そして、
多くの場合、
問題はブレークポイントではありません。
原因候補を考える前に、
検証を始めてしまっていることです。
ブレークポイントは、
先に置くものではありません。
👉 原因候補を考えた結果として
👉 確認したい場所へ置くものです。
まずは、
・何が起きているのか
・原因として何が考えられるのか
を整理してから調査してみてください。
それだけで、
デバッグの効率は大きく変わります。
おわりに
今回紹介した考え方は、
デバッグだけの話ではありません。
仕事をしていると、
問題や予想外の事態は必ず発生します。
そんな時も、
やることは同じです。
現象を確認する
↓
原因候補を考える
↓
検証する
この流れは、
デバッグでも、
改善活動でも、
トラブル対応でも変わりません。
ブレークポイントの置き方よりも、
まずはこの考え方を身につけることが大切だと思います。
もし、
「こんなパターンでもハマった」
などがあれば、ぜひ教えてください。
今後の記事で取り上げていきます。