仮説、ログ、二分探索

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

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

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

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

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