原因候補が広い時は、最初から順番に読むより、中間地点を確認して問題がある側だけを残す方が速く絞れます。これが二分探索デバッグです。
今回やること
二分探索が使えるのは、次の3つがそろう時です。
- 同じ手順で問題を再現できる
- 候補を前半・後半に分けられる
- 各地点を「問題あり」か「問題なし」に安定して分類できる
結果が毎回変わるなら、先にデータ・キャッシュ・外部APIなどの条件を固定します。
処理の途中で値を確認する
次の経路で、保存結果だけが期待と違うとします。
入力 → 変換A → 変換B → API → DB
最初に中間の「変換Bの出力」を確認します。
- すでに違う値なら、入力から変換Bまでが候補
- 正しい値なら、APIからDBまでが候補
残った範囲でも同じように中間を見ます。観測する値は、件数だけでなく代表IDや型も一緒に残すと、別の問題を同じ原因と誤解しにくくなります。
Gitの履歴を絞る
以前は動いていた版と、現在壊れている版が分かるなら、git bisectを使えます。作業ツリーの変更を先にコミットまたは退避してから実行してください。
git bisect start
git bisect bad # 現在の壊れた版
git bisect good <良かったコミット>
Gitが示した中間コミットを、同じデータ・同じ手順で確認します。
git bisect good # 問題なしだった時
git bisect bad # 問題ありだった時
git bisect reset # 終了して元のブランチへ戻る
途中のコミットがビルドできない時は、良し悪しを推測せず git bisect skip を使います。skipが多いと、原因の候補を一つに決められないことがあります。
成功確認
課題保存が遅くなった調査なら、「固定の課題で2秒以下ならgood、5秒以上ならbad」のように判定を決めます。候補が一つになったら、前後の版をもう一度測り、該当変更を外すと問題が消えるか確認します。
git bisectが示すのは最初にbadと分類されたコミットです。修正内容を示すわけではないため、その差分を読み、回帰テストを追加して初めて調査完了です。
よくあるつまずき
体感でgoodとbadを決める
性能は測定値、機能は固定の期待結果で判定します。閾値付近で揺れるなら複数回測り、中央値で決めるか、判定を保留して測定方法を直します。
複数の原因が混ざっている
ある変更で壊れ、後の変更で偶然直るような履歴では単純な二分探索は成立しません。再現条件を一つに絞るか、処理経路ごとに調査します。
練習
検索画面で「表示件数だけが0になる」問題を考えます。入力、絞り込み、API応答、表示用変換のうち、最初に確認する中間地点を一つ選び、正しい場合と間違っている場合で次に調べる範囲を書いてください。
