Один вопрос для дебага: маленькая мысленная проверка, которая спасает от охоты за «не тем» багом

Вы смотрите на упавший тест или сломанную фичу. Открываете редактор, расставляете логи, запускаете дебаггер, иногда спрашиваете совета у AI‑ассистента. Десять, двадцать, сорок минут спустя вы по пояс увязли во вложенных вызовах и stack trace’ах — и внезапно осознаёте, что всё это время копали вообще не там.

Проблема была не в этом сервисе. Не в этой функции. Не в этом файле.

Вы гонялись за не тем багом.

Это происходит не потому, что вам не хватает инструментов или скиллов, а потому, что вы пропустили один крошечный мысленный шаг: ни разу не остановились и не спросили себя, имеет ли смысл ваша текущая теория о том, где баг.

Этот пост — о том, как выработать одну маленькую привычку: задавать себе один вопрос до (и во время) дебага. Он резко сокращает потери времени и помогает быстрее выходить на настоящую первопричину.

Суть привычки: один короткий вопрос

Прежде чем добавлять логи, ставить breakpoints или спрашивать помощь у AI, остановитесь на пару секунд и спросите:

«Какие у меня есть доказательства, что баг именно здесь, а не где‑то ещё?»

Вот и всё.

Этот маленький вопрос — защита от отладки, основанной на голых предположениях. Вместо того чтобы слепо верить первой догадке, вы вынуждены:

• Сделать свою текущую гипотезу явной
• Проверить, согласуется ли она с тем, что вы уже знаете
• Решить, действительно ли стоит углубляться именно здесь

Формулировку можно подстроить под себя:

• «Если моя теория верна, что ещё я должен увидеть?»
• «Что быстро покажет, что моя теория неверна?»
• «Какие компоненты в принципе могут вызывать такое поведение?»

Слова не святы. Смысл в том, чтобы прервать слепое копание быстрой и осознанной проверкой своей ментальной модели.

Почему разработчики тратят время на «не тот» баг

Большая часть бесполезного дебага следует простому сценарию:

1. Что‑то сломалось.
2. Вы почти мгновенно формируете дешёвую гипотезу: наверное, это кеш.
3. Начинаете ковыряться там, куда ткнула интуиция.
4. Продолжаете добавлять детали (больше логов, глубже breakpoints), ни разу не усомнившись в исходном предположении.

Это приятно, потому что создаёт ощущение прогресса. Вы печатаете, смотрите, исследуете код. Но усилия — это не прогресс. Если базовое предположение неверно, вы просто украшаяте не тот туннель.

Корень проблемы — непоставленные под вопрос допущения:

• «Скорее всего, это фронтенд» (потому что последними меняли именно его).
• «Наверняка дело в этой функции» (потому что похожий баг уже был тут раньше).
• «Это, наверное, гонка данных» (потому что конкурентность пугает всех).

Привычка с одним вопросом разрезает всё это. Она заставляет спросить: Почему я в это верю? и Что я ожидал бы увидеть, если это правда?

Чёткая ментальная модель — ваш первый инструмент отладки

Этот вопрос работает только если у вас есть какая‑то ментальная модель поведения системы. Она не обязана быть идеальной, но должна быть достаточно конкретной, чтобы можно было ответить:

«Какие части системы в принципе могут порождать такой баг?»

Полезная ментальная модель включает:

• Ключевые компоненты (сервисы, модули, слои)
• Поток данных (как вход превращается в выход)
• Поток управления (кто кого вызывает и когда)
• Границы и контракты (что каждый компонент гарантирует)

Имея это в голове, вы можете отсечь огромные куски лишних деталей:

• Если баг проявляется до того, как уходит сетевой запрос, удалённый API не виноват.
• Если выходные данные стабильно неверны одним и тем же образом, то flaky‑сеть менее вероятна, чем детерминированная ошибка трансформации.
• Если логи показывают, что в функцию заходит правильные данные, а выходят уже неправильные, зона поиска резко сужается.

Ментальная модель позволяет сказать: «Чтобы проявился этот симптом, что‑то на этом пути должно вести себя неправильно». И вот тогда привычка с одним вопросом начинает работать по‑настоящему эффективно.

Первопричина vs симптом: целимся в правильную цель

Задача отладки — найти настоящую первопричину, а не просто заклеить симптом.

• Симптом: «Пользователь видит нулевой итог в корзине».
• Обходной путь: «Если total равен нулю, пересчитать на фронтенде».
• Первопричина: «Расчёт скидки уходит в underflow и обрезается до нуля при определённом наложении купонов».

Ваш один вопрос должен явно проверять, объясняет ли текущая теория корень, а не только внешний эффект.

Спросите:

• «Если моя гипотеза верна, объясняет ли она все наблюдаемые симптомы?»
• «Если я это починю, предотвратит ли это появление бага в другой форме?»

Если ответ «может быть» или «частично», вы, возможно, лечите симптом.

Сдвигая себя к размышлению о более глубокой причине, вы избегаете хрупких костылей и помогаете себе в будущем (и команде), стабилизируя систему вместо того, чтобы клеить обои поверх трещин.

Отладка как последовательность экспериментов

Эффективная отладка — это не стихийные раскопки, а серия экспериментов.

Каждый эксперимент строится вокруг гипотезы:

«Я думаю, баг с пагинацией в backend‑запросе, а не в отображении на фронтенде.»

Ваш один вопрос запускает два продолжения:

1. «Если моя теория верна, что ещё я должен увидеть?»

   • Например: дубликаты строк в логах ещё до того, как данные попадут на фронтенд.
   • Или: API уже возвращает неправильный totalPages.

2. «Что быстро покажет, что моя теория неверна?»

   • Например: один запрос к API, где backend‑данные корректные, а отображение в UI неправильное.

Теперь логи и breakpoints становятся прицельными:

• Вы один раз логируете «сырой» ответ API, а не весь рендеринг дерева.
• Ставите breakpoint там, где данные переходят границу между backend и frontend.

Если эксперимент опровергает теорию — это не провал, а прогресс. Вы закрыли один путь и уточнили свою ментальную модель.

Инструменты по делу: гипотезо‑ориентированный дебаг

Дебаггеры, профайлеры, логи, трассировка, AI‑ассистенты — мощные инструменты, но это усилители: они усиливают тот процесс, который у вас уже есть.

• При слепом использовании они усиливают случайное блуждание.
• При работе с чёткой гипотезой — точечное обучение.

Перед тем как открыть дебаггер или задать вопрос AI, ответьте себе:

1. Какова моя текущая гипотеза?
   «Баг в маппинге данных из внешнего API во внутреннюю модель.»

2. Какое конкретное наблюдение подтвердит или опровергнет её?
   «Если я посмотрю на смэппленную модель сразу после парсинга и она уже неверна — баг в маппинге; если здесь всё ок, а дальше ломается — баг где‑то ниже по потоку.»

3. Где самое узкое место в коде, где я могу это проверить?
   «Сразу после возврата из функции маппинга.»

Теперь у сессии с дебаггером есть миссия: проверить форму объекта именно там. Вы больше не «шагаете по строкам» в надежде, что что‑то покажется подозрительным; вы подтверждаете или убиваете конкретную теорию.

Тот же паттерн можно использовать с AI:

• Плохо: «Почему мой код не работает?»
• Лучше: «Я думаю, баг в логике маппинга, потому что ответ API выглядит корректно, а UI показывает неправильные значения. Какой тест или наблюдение быстрее всего подтвердит или опровергнет это?»

Привычка с одним вопросом по умолчанию толкает вас в этот «лучший» режим.

Как сделать привычку автоматической

Такая маленькая привычка сильна только если вы используете её каждый раз. Несколько способов закрепить её:

1. Добавьте pre‑debug чек‑лист в свой рабочий процесс:

   • «Какой точный симптом?»
   • «Какова моя текущая гипотеза?»
   • «Какие у меня есть доказательства, что баг именно здесь, а не где‑то ещё?»

2. Записывайте это в редакторе или таск‑трекере:

   • Вверху заметки по дебагу: Гипотеза: …
   • Ниже: Факты/сигналы в пользу этой версии: …

3. Произносите вслух во время парного программирования или ревью:

   • «Мы добавляем логи здесь, потому что считаем, что именно тут данные портятся. Есть ли у нас хоть какие‑то доказательства, что этот участок вообще замешан?»

4. Используйте как триггер тайм‑аута:

   • Если вы буксуете 15 минут, остановитесь и спросите:
     «Если моя теория неверна, как бы я вообще это заметил?»

Со временем это становится автоматическим: начинать отладку странно, если вы ещё не сформулировали, что именно проверяете.

Небольшой пример

Допустим, приходит баг‑репорт:

«Иногда итог по счёту считается неправильно при применении нескольких скидок.»

Первая мысль: наверное, виноват новый discount‑service. Вместо того чтобы сразу лезть в его кишки, вы включаете привычку.

• Гипотеза: сервис скидок возвращает неправильные суммы.
• Вопрос: Какие у меня есть доказательства, что баг именно здесь, а не где‑то ещё?

Пока что? Никаких.

Вы придумываете быстрый тест:

• Логируете «сырые» позиции счёта и ответ discount‑сервиса.
• Сравниваете с заведомо правильным ручным расчётом.

Если залогированные суммы скидок корректны, изначальная теория мертва. Тогда рассматриваете другие варианты:

• Налоговые расчёты
• Округление
• Конвертация валют

Вы обновляете гипотезу, придумываете следующий небольшой эксперимент и повторяете цикл. Вместо того чтобы час копаться в сервисе скидок, вы за несколько минут «убиваете» эту версию и двигаетесь дальше.

Вывод: меньше копать, больше думать

Большая часть боли отладки возникает не из‑за нехватки инструментов, а из‑за того, что мы слишком долго копаем не там.

Одна простая, повторяемая привычка может это изменить:

До и во время отладки спрашивайте: «Какие у меня есть доказательства, что баг именно здесь, а не где‑то ещё?»

Добавьте к этому ясную ментальную модель системы и фокус на первопричинах — и ваши логи, breakpoints и AI‑инструменты станут намного эффективнее.

Вы не перестанете ошибаться насчёт того, где живут баги — это неизбежно. Но вы перестанете ошибаться часами подряд.

В следующий раз, когда потянетесь к дебаггеру, сделайте паузу на две секунды и задайте этот вопрос. Эта крошечная проверка может освободить вам остаток дня.