Как отлаживать код: системный пошаговый подход

Главное правило отладки

Баг почти всегда находится быстрее, когда вы действуете по процессу, а не правите код наугад. Рабочий цикл из четырёх шагов:

1. Воспроизвести — добиться, чтобы ошибка появлялась стабильно.
2. Изолировать — сузить область, где она возникает.
3. Выдвинуть гипотезу — одну конкретную причину.
4. Проверить — подтвердить или опровергнуть фактами, а не ощущениями.

Если гипотеза не подтвердилась — возвращаетесь к шагу 2 с новыми данными.

Шаг 1. Воспроизвести

Без воспроизведения вы не узнаете, исправили ли баг. Соберите:

• точные шаги, входные данные и окружение (браузер, ОС, версия приложения);
• полный текст ошибки и stack trace — читайте его снизу вверх до первой строки вашего кода;
• что ожидалось и что произошло на самом деле.

Цель — минимальный пример: как можно меньше шагов и данных, при которых баг всё ещё есть. Идеально — превратить его в автотест, который сейчас падает.

Шаг 2. Изолировать

Сужайте круг поиска:

• Бинарный поиск по коду: поставьте проверку посередине пути данных. Значение уже неверное? Ищите выше. Верное? Ниже.
• Бинарный поиск по истории: если раньше работало, git bisect найдёт коммит, который всё сломал.

git bisect start
git bisect bad            # текущая версия сломана
git bisect good <hash>    # эта версия работала
# проверяете каждую предложенную версию и отмечаете good/bad
git bisect reset

• Убирайте лишнее: отключите кэш, расширения, часть данных, сторонние сервисы — пока баг не исчезнет. Последнее убранное и есть подозреваемый.

Шаг 3. Гипотеза

Сформулируйте её одной фразой: «Цена приходит строкой, поэтому + склеивает, а не складывает». Хорошая гипотеза проверяема и указывает, какое наблюдение её опровергнет. Записывайте проверенные гипотезы — это экономит время, если отладка затянется.

Шаг 4. Проверить инструментами

Брейкпоинты

Отладчик в IDE или браузере останавливает программу на нужной строке, и вы видите все переменные в этот момент.

• Условные брейкпоинты срабатывают только при условии, например order.id === 42, — незаменимы в циклах.
• Step over / step into / step out — идите по коду построчно, заходя в функции только когда нужно.
• Call stack показывает, как программа сюда попала.

Watch expressions

Добавьте в панель наблюдения выражения вроде items.length или user?.role: они пересчитываются на каждом шаге, и вы видите момент, когда значение становится неправильным.

Логирование

Логи незаменимы там, где отладчик не подключить: продакшен, асинхронные процессы, проблемы со временем.

• Логируйте контекст: идентификаторы, входные значения, ветку условия.
• Используйте уровни: debug, info, warn, error.
• Не пишите в логи пароли, токены и персональные данные.
• Временные console.log и print удаляйте после фикса.

Метод утёнка

Объясните код построчно — коллеге, резиновой уточке или в текстовой заметке. Проговаривая, что «должно» происходить, вы часто сами замечаете место, где реальность расходится с ожиданием.

После исправления

• Убедитесь, что исходный сценарий больше не воспроизводится.
• Добавьте регрессионный тест, чтобы баг не вернулся.
• Поищите похожие места: та же ошибка могла быть скопирована.
• Исправляйте причину, а не симптом: try/catch, который просто глушит ошибку, — не фикс.

Частые ошибки

• Менять несколько вещей сразу — непонятно, что помогло.
• Доверять предположениям вместо проверки значений.
• Игнорировать первое сообщение об ошибке и смотреть только на последнее.
• Отлаживать часами без перерыва: короткая пауза нередко помогает увидеть очевидное.