仮説、ログ、二分探索

AIが原因を提示したら、ただ受け入れてはいけません。安く検証しましょう。 最も安いテストは、たいていログ行です。

AIに一時的なログを追加させましょう。

「何も変える前に、14行目の直前で user の値を表示する console.log (または print) を追加して、本当にundefinedなのか確認できるようにして。」

実行して、その出力を貼り戻します。これで理論ではなく 証拠 が手に入りました。user がundefinedかもしれません — 仮説が確認できます。あるいは問題なく、本当の犯人は一段上にあるのかもしれません。どちらにせよ、あなたは前進しています。調査中はログを惜しまず仕込みましょう。変数の値、そして それがどの変数で、ログがどこにあるのかを示すラベルまで。undefined を出す素の console.log(user) は、console.log("user at validate.js:14 =", user) よりはるかに役に立ちません。そしてバグが直ったら一時的なログを抜き取るのを忘れずに — 残されたデバッグノイズは、それ自体が小さな散らかりです。

長いプロセスのどこかにバグが潜んでいて、どこか分からないときは、二分探索 を使います。怪しい領域を半分に切ります。中間点にログを追加します。

考え方はこうです。各チェックが残りの半分を捨てるので、巨大な探索空間が一気に縮みます。ここではバグがステップ1とステップ8のあいだのどこかに潜んでいて — 3回のチェックで追い詰めます:

   段階:  1  2  3  4  5  6  7  8      バグはこの中のどこか
          ░░░░░░░░░░░░░░░░░░░░░░

   確認 1 ── 4にログ ── OK ──▶  バグは4の後、1–4捨て
                                  ░░░░░░░░░░░  (5 6 7 8 残り)

   確認 2 ── 6にログ ── BAD ─▶  バグは6以下、7–8捨て
                                  ░░░░░  (5 6 残り)

   確認 3 ── 5にログ ── OK ──▶  バグは段階6   ✔ 発見

   8段階 → 3回確認。  1000段階 → 約10回確認。

そこでは値は正しく見えましたか? ならバグはその 後ろ にあります — その半分を探します。すでにおかしく見えましたか? バグは 前 にあります — その半分を探します。各ステップで探索空間が半分になるので、1000行の経路でも約10回のチェックで絞り込めます。AIにはっきりこう伝えましょう。「これを二分探索したい — ログを仕込むべき中間点はどこ?」 同じ技法はコードだけでなく履歴にも効きます。ある機能が先週は動いたのに今日壊れたなら、コミットを二分探索して、バグを持ち込んだ正確な変更を見つけましょう。