Автор: Ханиша Арора (Hanisha Arora)
Оригинал статьи
Перевод: Ольга Алифанова

Баги появляются, съедают всё ваше время и заставляют вас сомневаться в себе, убеждая, что проблема в вас. Это не так.

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

Вот несколько приёмов отладки, которые помогали мне в такие моменты:

1. Перестаньте винить код: вместо этого исследуйте свои предположения

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

Остановитесь. Запишите 3 собственных предположения. Затем проверьте, действительно ли это так. Большинство багов умирают здесь.

2. Используйте print statements везде и всюду

Да, логи — это хорошо. Но иногда вам нужно тупое и прямое сообщение, показывающее голую правду.

Забудьте об «элегантных» логах. Вместо этого напишите: console.log('IT GOT HERE', value, otherValue);

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

Если вы гадаете — начните выводить значения на печать.

3. Используйте приём «проверьте, что изменилось»

Вчера код работал. Сегодня — нет.

Что изменилось?

• Слияние?
• Обновление пакета?
• Кто-то «просто переименовал» поле?

Используйте git diff. Используйте git blame. Используйте сообщения вашей команды. Баги появляются, когда вы считаете, что изменение, которое только что внесли, «безобидное».

4. Намеренно ломайте

Иногда самый быстрый способ отладки — сделать проблему ещё хуже.

• Что произойдёт, если вы удалите всю функцию?
• Что, если вы сделаете входные данные явно неправильными?
• Что, если вы временно захардкодите значение?

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

5. Объясняйте баг кому угодно, даже резиновой уточке

Объяснение бага кому-то другому, даже резиновой уточке, часто помогает вам самим обнаружить решение.

Лучше всего делать это письменно, например в сообщении или записи в блоге. На середине объяснения вы поймёте, где именно ошиблись.

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

6. Сообщения об ошибках иногда лгут, но stack traces говорят правду

Сообщение об ошибке может сказать, что проблема находится в fileA.js, строка 134. Но настоящий виновник находится на 10 шагов раньше.

Начните со stack trace. Мысленно восстановите цепочку вызовов. Используйте точки останова или трассировки, чтобы пройти тот же путь.

Правда находится в пути, а не в финальной реплике.

7. Воспроизведение убивает баги насмерть

Если вы не можете его воспроизвести, вы не можете его исправить. И точка.

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

Как только вы воспроизвели его хотя бы один раз, баг уже направляется на кладбище.

8. Логи — хорошие карты и плохие романы

Не тоните в логах. Научитесь:

• Фильтровать по correlation ID.
• Искать ключевые слова ошибок с помощью grep.
• Логировать временные метки, чтобы обнаруживать проблемы с таймингом.

Ещё лучше — устанавливайте оповещения для шаблонов ошибок и путей с высокой задержкой. Лог — не ваш дневник. Это ваша система наблюдения.

9. Проверяйте компоненты, с которыми взаимодействует ваш код

Это ваш баг? Возможно.

Но сначала рассмотрите следующее:

• Странно ли ведёт себя API выше по коридору?
• Не кэширует ли сервер базы данных устаревшие данные?
• Не отдаёт ли система доставки контента устаревший JavaScript?

Отладка теперь выходит за границы отдельных систем. Изолируйте системы. Подтверждайте предположения. Не играйте в одиночку, вы можете разделить нагрузку.

10. Делайте перерывы на отдых по-взрослому

Тот баг, который вы не можете ущучить после трёх часов работы над ним, будет с шансами прикончен за 10 минут после обеда.

Отойдите от него. Поворчите другу. Уставьтесь в пустоту.

Отладка — это не просто размышления. Это переосмысление, а вашему мозгу нужно пространство для этого.

Бонус: ваш начальник не впечатлён, когда вы говорите: «Я это исправил».

На самом деле он хочет знать:

• Что сломалось
• Почему это сломалось
• Как мы предотвратим это в следующий раз

Пишите postmortems. Добавляйте комментарии. Создавайте тест-кейс. Вот так выглядит отладка на уровне босса.

Всё ещё застряли? Придумывайте собственные приёмы.

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

• Копирование состояния в playground
• Развёртывание нового dev-окружения
• Вопрос своему будущему «я» в комментариях к коду о том, какого чёрта вообще должна была делать эта логика

Что бы ни работало — записывайте это. Делитесь этим. Учите этому других. Именно так вы становитесь лучше в отладке — не просто быстрее, а умнее.

Заключение

• Не доверяйте своим предположениям, оспаривайте их.
• Логи — ваш помощник, а не ваш спаситель.
• Ломайте, наблюдайте и упрощайте.
• Если застряли — отойдите.

Дополнительная информация

• Поиск багов быстрее: более умный способ отладки ошибок интеграции, Arun Vishwanathan
• Тестирование приложений, написанных с помощью ИИ: практические советы для тестировщиков ПО, Rafaela Azevedo
• Я мыслю, следовательно, я тестирую: важность мышления для тестировщиков, Ady Stokes
• Исправление бага против исправления функциональности, Hanisha Arora

Что думаете ВЫ?

Есть комментарии или мысли? Поделитесь ими в комментариях. Если хотите, используйте приведённые ниже идеи как отправную точку для размышлений и обсуждения.

Вопросы для обсуждения

• Какой полезный приём отладки, которому вы научились, отсутствует в этом списке?
• Вам когда-нибудь приходилось часами гоняться за багом, чтобы в итоге понять, что он возник из-за ложного предположения? Как вы это обнаружили?
• Как вы решаете, когда нужно отойти и сделать перерыв, а когда продолжать искать решение?
• Какой ваш лучший «момент с резиновой уточкой»: когда объяснение бага внезапно сделало решение очевидным?

Что можно сделать

• Попробуйте метод резиновой уточки: Письменно объясните баг (реальный или воображаемый) самому себе или проговорите его с другом, который не разбирается в технических вопросах. Обратите внимание, в какой момент начинает появляться ясность.
• Намеренно что-нибудь сломайте: Выберите работающую функцию и намеренно сломайте её. Измените входные данные, захардкодьте неправильные значения или удалите части функции. Наблюдайте, как ваша система выходит из строя – это учит вас тому, где искать, когда появляются настоящие баги.
• Измерьте собственное замедление: Если хотите получить данные, начните с малого. Отслеживайте, сколько времени проходит между обнаружением бага и его фактическим закрытием. Затем посмотрите, сколько из этого времени уходит на ожидание, переделки или переключение контекста. Вы, вероятно, обнаружите, что в замедлении виновато вовсе не тестирование. То же самое можно сделать и для вашей команды, чтобы измерить замедление работы команды.
• Подключите к этому руководителей: Организуйте короткую беседу или командную сессию, чтобы поделиться своими приёмами отладки — что работает, что не работает и где теряется время. Согласование терминологии и приоритетов может превратить отладку из фоновой рутины в быстрое исправление.

Обсудить в форуме