Гипотезы, логирование и двоичный поиск
Как только AI предложит причину, не принимайте её просто так. Проверьте её дёшево. Самая дешёвая проверка обычно — строка лога.
Попросите AI добавить временное логирование:
«Прежде чем что-либо менять, добавь
console.log(илиuserпрямо перед строкой 14, чтобы мы могли увидеть, действительно ли оно undefined.»
Запустите, вставьте вывод обратно. Теперь у вас есть улика, а не теория. Может быть, user действительно undefined — это подтверждает гипотезу. Может быть, с ним всё в порядке, и настоящий виновник находится на уровень выше. В любом случае вы продвинулись вперёд. Логируйте щедро, пока ведёте расследование: значение переменной, и метку, которая говорит, какая это переменная и где находится лог. Голый console.log(user), печатающий undefined, куда менее полезен, чем console.log("user at validate.js:14 =", user). И не забудьте вытащить временные логи обратно, как только баг исправлен, — оставшийся отладочный шум сам по себе небольшой беспорядок.
Когда баг живёт где-то внутри длинного процесса и вы не можете определить где, используйте двоичный поиск. Разрежьте подозрительную область пополам: добавьте лог в середине. Выглядело ли значение там корректным? Тогда баг после этой точки — ищите в той половине. Выглядело ли оно уже неправильным? Баг до — ищите в той половине. Каждый шаг сокращает пространство поиска вдвое, так что даже путь в тысячу строк сужается примерно за десять проверок. Скажите AI явно: «Помоги мне разбить это пополам — где середина, в которую мне поставить лог?» Та же техника работает не только на коде, но и на истории: если функция работала на прошлой неделе и сломалась сегодня, разбейте пополам ваши коммиты, чтобы найти точное изменение, которое внесло баг.