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

Мое правило №1 при отладке: Никому не верь.

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

Теперь единственный вопрос, который я задаю: «Как проявляется эта ошибка?»

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

Тогда я начну с чистого листа, без предположений.

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

Начните сначала с самого последнего кадра и тщательно проанализируйте эту строку кода. Многие строки кода выполняют более одной задачи и имеют дело с более чем одним фрагментом данных. Подтвердите свои предположения о коде и состоянии данных в этот момент с помощью отладчика (или операторов printf;)) и сравните их с тем, как, по вашему мнению, он должен работать.

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

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

Примеры: «Код в модуле CardProcessor беспорядочный, и, поскольку я знаю, что он использовался в какой-то момент, когда я нажимаю кнопку, он должен быть там». «Причина этого в том, что запись на диск идет медленно, поэтому файлы должны быть записаны именно туда, в пакете FileWriter».

Опасность здесь заключается в том, чтобы тратить время на неправильный путь. Как узнать, какие теории верны, а какие нет?

Знайте свои инструменты. Для решения подобных проблем люди часто игнорируют ценные инструменты. Вам нужны инструменты, чтобы получить данные для создания хороших теорий. Если вы отлаживаете C / C ++, вы должны знать, как прикрепить GDB к файлу ядра. Если вы отлаживаете проблему с производительностью запроса, спросите кого-нибудь, как работает анализатор запросов к базе данных. Если рендеринг в браузере медленный или вы думаете, что у вас утечка памяти, используйте инструменты chrome dev для профилирования.

Если очевидно, что у вас мало достоверных данных о причине проблемы, вам следует сначала подумать о том, как получить эти данные , прежде чем сформулировать теории о первопричине проблемы. Иногда инструментальные средства могут помочь, иногда необходимо добавить ведение журнала. Опять же, первое место, где нужно начать добавлять ведение журнала и инструментарий, - это то, где возникает ошибка (например, если медлительность возникает при переходе на страницу / foo, сначала профилируйте).

Будьте готовы отбросить теорию. Часто разработчики настолько зацикливаются на том, что они считают проблемой - они потратили часы и часы на то, чтобы идти по пути отладки, они должны приближаться. Чтобы этого избежать, старайтесь, чтобы ваши теории были как можно более узкими и проверяемыми. Начните с наиболее вероятного первого и методически проверяйте теорию и устраняйте по ходу дела. Потратив более 30 минут на решение проблемы, спросите себя: действительно ли я уверен, что именно здесь ошибка?

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

Хакерский полдень - это то, с чего хакеры начинают свои дни. Мы часть семьи @AMI. Сейчас мы принимаем заявки и рады обсуждать рекламные и спонсорские возможности.

Чтобы узнать больше, прочтите нашу страницу о нас, поставьте лайк / напишите нам в Facebook или просто tweet / DM @HackerNoon.

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