こんな相談を受けることがあります。
「ボタンを押しても画面遷移しません」
「値がおかしいです」
「処理が動きません」
ここまでは説明できます。
でも、
「その値はどこから来たの？」
「誰がその値をセットしているの？」
「画面はどうやって切り替えているの？」
と聞くと、
急に説明できなくなることがあります。
実はこれ、
デバッグが苦手なのではありません。
何を調べれば良いのか整理できていない状態です。
デバッグで迷子になる人の特徴
問題が発生すると、
すぐにソースを開いてブレークポイントを貼ります。
でも、
・何を確認したいのか
・どこまで調べる必要があるのか
・次にどこを調べるのか
が決まっていません。
そのため、
たくさん調べたのに前に進みません。
まずは調査範囲を決める
調査を始める前に、
まず決めるべきことがあります。
それは、
👉 どこからどこまでを調べるのか
です。
問題が発生している場所は、
比較的分かりやすいです。
例えば、
・画面に表示される値がおかしい
・ボタンを押しても反応しない
・画面遷移しない
などです。
でも大事なのは、
👉 どこから調べ始めるのか
です。
ここが決まっていないと、
関係の薄い場所にブレークポイントを置いたり、
必要以上に広い範囲を調べたりしてしまいます。
実際、
相談を受けていて
「実際に動かして見せて」
と言うと、
とんでもない場所にブレークポイントを置いていることがあります。
画面遷移しない問題なのに、
画面遷移とは関係の薄い初期化処理や、
共通処理まで追いかけている。
もちろん調べること自体は悪くありません。
でも、
調査範囲を広げすぎると、
情報は増えても原因には近づきません。
まずは、
・問題が起きている場所
・その直前で関係していそうな処理
・その処理に影響を与えている入力や条件
に絞りましょう。
次に「調査の地図」を作る
調査範囲が決まったら、
次は確認する順番を整理します。
例えば、
「ボタンを押しても画面遷移しない」
なら、
画面遷移の調査地図
① ボタン押下処理は呼ばれているか
② 遷移条件を満たしているか
③ 次画面生成処理は呼ばれているか
④ 画面切替処理は呼ばれているか
⑤ 途中でエラーになっていないか
そして、
①がOKなら②
②がOKなら③
というように順番に確認します。
値がおかしい場合も同じです。
値の調査地図
① 値の発生源はどこか
② 発生源の値は正しいか
③ 途中で変更されていないか
④ 別の変数に入れ替わっていないか
⑤ 表示時に違う値を見ていないか
こうやって確認ポイントを書き出してから調査します。
すると、
どこにブレークポイントを置けば良いかも自然と見えてきます。
地図は最初から完璧じゃなくていい
ここで勘違いしてほしくないのは、
最初から完璧な地図を書く必要はないということです。
漏れや抜けがあって当然です。
むしろ、
自分なりに考えてみることが大切です。
先輩に相談すると、
「①と②の間に確認ポイントがあるよ」
「そこはこの処理が呼ばれているよ」
「このコードはこういう意図で書かれているよ」
と教えてもらえます。
でも、
地図がない状態で
「分かりません」
だけだと、
どこから話せば良いか分かりません。
良い相談と丸投げの違い
例えば、
「画面遷移しません。どう直せばいいですか？」
だけでは、
何が分からないのか分かりません。
一方で、
「ボタン押下処理までは確認できました」
「遷移条件も問題ありませんでした」
「次画面生成処理をしていそうな箇所は見つけました」
「でもこのコードの意図が分かりません」
「ここを教えてください」
ならどうでしょう。
かなり話がしやすくなります。
先輩からしても、
どこで困っているのかが分かるので、
フォローしやすくなります。
まとめ
デバッグとは、
ブレークポイントを貼ることではありません。
まず、
・調査範囲を決める
・調査の地図を作る
・順番に確認する
これが大切です。
完璧でなくても良いので、
まずは自分なりの地図を書いてみましょう。
そして、
自力で調べられるところまで調べる。
分からないところを聞く。
そうすると、
デバッグは驚くほど進めやすくなります。
そして実はこの考え方、
プログラムだけではありません。
仕事でも日常生活でも、
問題が起きたら
原因候補を考え、
順番に確認していく。
そんな見方を少しずつ意識していると、
いつの間にか
「何を調べれば良いのか」
が見えるようになってくると思います。
関連記事
調査範囲や地図が作れたら
・ソースは読めるのに処理が追えないのはなぜ？
・ブレークポイント置いたのに原因が見つからない人へ