Искусство отладки
20 ноября 2022 г.Как инженеры-программисты, отладка является неотъемлемой частью нашей работы. У вас, как у инженера-программиста, могут быть периоды, когда вы больше озабочены исправлением ошибок, чем разработкой новых функций.
Процесс отладки можно разделить на две категории:
- Активно. На этом этапе вы исследуете все методы исправления ошибки путем изменения кода. Следующие шаги — разработка гипотезы о том, будет ли решение работать, и ее реализация.
- Пассив. Для пассивной отладки мы используем ведение журнала, когда ошибка не может быть воспроизведена, поэтому мы не можем пройти этапы выполнения.
В этой записи блога я поделюсь некоторыми приемами отладки, которые я перенял и теперь стал частью моего процесса отладки.
Важно помнить, что если ошибка существует, даже если вы ее не испытываете, это означает, что с кодом определенно что-то не так. Это может быть логика, проблема с зависимостями или пропущенный пограничный случай.
Вернуться в историю
Сбор всей доступной исторической информации о проблеме — это первый шаг в отладке. Обычно это позволяет определить, является ли проблема постоянной или она никогда не решалась. Это может быть журнал, заметка об ошибке, снимок экрана и, возможно, обмен старыми сообщениями.
SCM также позволяет просматривать все предыдущие модификации файла. Различные расширения Git в среде IDE могут помочь в этом процессе. Если вы вернетесь в прошлое и обнаружите хотя бы мельчайшие признаки, это может иногда натолкнуть вас на мысль, когда вы абсолютно сбиты с толку тем, как происходит ошибка.
Читать Читать Читать
Иногда половину проблем можно решить, просто прочитав код и отследив все функции.
По моему опыту, после обнаружения конечной точки API, где возникла проблема, я ищу связанный с ней метод, а затем пытаюсь визуализировать поток, создавая ментальную модель кода.
После того, как вы поняли код, вы можете добавить точки останова (например, binding.pry в Rails) в код, чтобы проверить свое понимание.
Поговорите с собой
При работе над сложной проблемой разговор вслух с самим собой может иногда выявить белые пятна.
Я пытаюсь записать это так, как посоветовал бы кому-нибудь, оказавшемуся в похожей ситуации, если размышления вслух не помогают.
Просто запишите все, что вы знаете об ошибке, чтобы, когда вы увидите все написанное перед собой, ваш разум начал заполнять пробелы.
Добавить журналы везде
Это один из самых популярных методов отладки. Это предполагает вставку журналов в код в разных местах — в основном до и после каждого вызова функции.
Добавление журналов может помочь вам понять состояние переменной, значение которой изменяется во многих функциях.
Поэкспериментируйте, чтобы воспроизвести ошибку
В результате обнаружения дефекта мы можем сделать вывод, что код недоработан. В огромных кодовых базах важно воспроизводить проблемы, которые появляются только при определенных обстоятельствах.
Чтобы понять набор условий, можно собрать все точки данных при анализе значений базы данных. Попробуйте найти закономерность среди всех пользователей, у которых возникла ошибка. Затем вы можете поэкспериментировать с другим набором условий, чтобы устранить проблему.
Чтобы еще больше помочь в отладке крайних случаев, код может быть значительно изменен, чтобы включить ранние возвраты, условные возвраты и т. д.
Забыть то, что вы знаете о продукте, — важный шаг в попытке воссоздать что-то. Обычно, когда мы работаем над чем-то очень долго, мы знакомы со всеми хитростями и знаем, что сработает, а что нет. Из-за этого воспроизведение жука необъективно. Рассмотрите свой продукт с точки зрения пользователя и придумайте максимально абсурдный сценарий.
Это не всегда большие перемены
Когда вы сталкиваетесь с ошибкой, не всегда думайте, что проблема связана с большим изменением или переписыванием кода. Начните с малого.
Проверяйте нулевые значения, любые проверки перед действием, если еще есть условия.
Когда я начинал, я считал, что потребуются значительные изменения, но со временем я понял, что лучше сначала сосредоточиться на мелких аспектах.
Прочитайте модульные тесты
Вы можете начать с просмотра модульных тестов для этого конкретного фрагмента кода, если вы полностью озадачены различными пограничными ситуациями, которые обрабатывает функция.
Поговорите с владельцем кода
Возможно, вам не всегда придется отлаживать то, над чем вы работали. Когда это происходит, может быть полезно поговорить с кем-то, у кого есть более широкое понимание.
Вы можете передать свои идеи для решения при работе над критическим потоком, если что-то модифицируете, с рабочей группой, чтобы убедиться, что вы не пропустили ни одного пограничного случая.
Подготовьте правильное оповещение & Система мониторинга
Использование таких инструментов, как HoneyBadger и Sentry, поможет вам вести журнал ошибок. Вы можете добавить их во все свои API & важные рабочие процессы.
Помимо предупреждений, у вас может быть система ведения журналов, в которой вы можете отслеживать маршруты, которые вызываются в реальном производстве.
Задокументируйте это
Самый важный шаг — последний: как только вы определили причину проблемы, не забудьте записать ее на будущее.
Наконец, если ни один из вышеперечисленных шагов не помог, сделайте перерыв, вернитесь и начните заново.
PS: Имейте в виду, что отладка — это не волшебство; скорее, это последовательный процесс, который становится лучше по мере того, как вы делаете это чаще.
Первоначально опубликовано здесь
Оригинал