Работать с кодом, который вам непонятен, — все равно, что бродить по болоту. Вы должны попытаться как можно быстрее встать на твердую почву.

— Джон Скит

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

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

коренная причина – основная причина ошибки.

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

Пора надеть наши детективные шляпы, чтобы найти первопричину.

Соберите детали

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

Вот некоторые из вопросов, которые вы должны задать:

  • Легко ли оно воспроизводится?
  • Если да, то каковы точные шаги для его воспроизведения?
  • Сталкивались ли другие с этой проблемой?
  • На каком устройстве и системной информации произошла ошибка?
  • Что изменилось за последнее время? Любые развертывания кода, конфигурация или аппаратные изменения?
  • Что должен делать код, когда он работает успешно?
  • Есть ли какая-либо проверка, обработка ошибок и т. д., которые должны быть запущены?

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

  • Проверьте журналы и программное обеспечение для создания отчетов об ошибках на наличие связанных ошибок и событий, которые произошли примерно в одно и то же время.
  • Погуглите любые сообщения об ошибках. Google, чтобы убедиться, что вы понимаете это, и посмотреть, есть ли у других решения.
  • Проверьте журналы git на наличие последних развертываний, изменений оборудования или конфигурации. Помните о любых недавних изменениях, даже если они кажутся несвязанными.

Воспроизведите проблему

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

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

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

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

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

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

Попросите кого-нибудь еще

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

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

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

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

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