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

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

Без понимания проблемы

Разработчик видит в отчёте об ошибках, что одна из связей проекта пуста и этим ломает экран с настройками проекта.

Разработчик не вникает в проблему, а добавляет if, чтобы экран настроек пропускал пункт с проблемой.

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

Расследование показывает, что проблема глубже, а отсутствующие записи — просто симптом. Оказывается, дело в коде, который создаёт проекты по шаблону: из‑за ошибки некоторые связи в проектах создаются пустыми. За две недели проблемный код успел создать около двухсот битых проектов, с которыми клиенты не могут нормально работать.

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

Так исправление бага замаскировало проблему и ухудшило ситуацию.

Без понимания, как должно быть

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

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

Потратив на алгоритм день, я решил всё‑таки разобраться, как правильно обрабатывать такие подписки. Оказалось, надо было не списывать за каждый пропущенный месяц, а просто списать за следующий и продлить — пятиминутное дело.

В общем виде алгоритм исправления ошибок выглядит так:

Повторить ↔ Изолировать ↔ Исправить ↔ Порефлексировать

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

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

Когда причина обнаружена, остаётся устранить баг и порефлексировать: что пошло не так, почему, как сделать так, чтобы в будущем таких багов не было.

О каждом из этих шагов я расскажу отдельно в следующих советах.

Ещё по теме

P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.

Веб‑разработка
Отправить
Поделиться
Запинить

Рекомендуем другие советы