Стандартные методы отладки

Question

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

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

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

Другие парни пытались сделать это совершенно по-другому.

Итак, просто интересно, что сработало для вас, ребята? И что бы вы сказали, что ваш процесс предназначен для отладки, если бы вам пришлось формализовать его словами?

Кстати, мы до сих пор не нашли нашу проблему =)

Answer 1

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

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

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

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

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

Answer 2

Подумайте о приобретении книги Дэвида Дж. Аганса " Отладка ". Подзаголовок: «9 обязательных правил для нахождения даже самых неуловимых проблем с программным и аппаратным обеспечением». Его список правил отладки - доступен в виде постера на веб-сайте (а также есть ссылка на книгу):

• Понять систему
• Сделать это не удалось
• Перестань думать и смотри
• Разделяй и властвуй
• Измените одну вещь за раз
• Вести контрольный журнал
• Проверьте штекер
• Получить свежий вид
• Если вы не исправили это, оно не исправлено

Последний пункт особенно актуален в индустрии программного обеспечения.

Answer 3

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

Answer 4

Я выбрал те из Интернета или какую-то книгу, которую не могу вспомнить (это может было CodingHorror ...)

Отладка 101:

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

Психологические методы:

• отладка резиновой утки
• Не спекулируйте
• Не спешите обвинять инструменты
• Понять и проблему, и решение
• Сделай перерыв
• Рассмотрим несколько причин

Методы предотвращения ошибок:

• Контролируйте свои собственные привычки впрыскивания неисправностей
• Раннее внедрение средств отладки
• Слабая связь и скрытие информации
• Написать регрессионный тест для предотвращения повторного появления

Технические методы:

• Заявления инертной трассировки
• Обратитесь к файлам журналов сторонних продуктов
• Поиск в интернете трассировки стека
• Вводить проект по контракту
• Протрите Шифер Чисто
• Прерывистые ошибки
• Explot Localility
• Внедрение фиктивных реализаций и подклассов
• Перекомпилировать / Перекомпоновать
• Граничные условия для зондов и особые случаи
• Проверка зависимостей версии (третье лицо)
• Проверить код, который недавно изменился
• Не верьте сообщению об ошибке
• Графические ошибки

Answer 5

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

Настройка сценария быстрого воспроизведения, позволяющего эффективно использовать ваше время для проверки любой выбранной вами гипотезы.

Создание инструментов для быстрого сброса среды для сравнения.

Создание и воспроизведение ошибки с ведением журнала на максимальном уровне.

Проверка системных журналов на наличие чего-либо тревожного.

Глядя на даты и временные отметки файлов, чтобы понять, может ли быть проблема недавним введением.

Просмотр исходного хранилища на предмет недавних действий в соответствующих модулях.

Применять дедуктивные рассуждения и применять принципы Бритва Оккама .

Будьте готовы сделать шаг назад и отдохнуть от проблемы.

Answer 6

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

Большинство проблем многопоточной синхронизации очень легко решаются с помощью этого подхода.

Также вам необходимо хорошо понимать используемый вами отладчик и его функции. Я работаю над приложениями Windows и обнаружил, что windbg чрезвычайно полезен для поиска ошибок.

Answer 7

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

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

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

• динамическое выделение памяти
• переполнение стека
• неинициализированная переменная
• логическая ошибка

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

Фактическая механика отладки чаще всего:

1. у меня есть автоматический тест, который демонстрирует проблему?
   • , если нет, добавить тест, который не проходит
2. изменить код, чтобы тест прошел
3. убедитесь, что все остальные тесты еще проходят
4. проверить изменения

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

Answer 8

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

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

Конечно, очень важно не просто пробовать вещи. Это увеличивает ваше отчаяние, потому что это никогда не работает. Я бы предпочел сделать 50 пробежек, чтобы собрать информацию об ошибке, а не делать дикие колебания и надеяться, что это сработает.

Answer 9

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

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

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

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

Иногда нелегко выделить фрагмент кода, поэтому в этих случаях я использую разные методы в зависимости от сложности проблемы. В большинстве случаев предположения о данных, кажется, приходят и кусают меня, поэтому я пытаюсь добавить много утверждений в код, чтобы убедиться, что мои предположения верны. Я также отключаю код с помощью #ifdef, пока ошибка не исчезнет. Устранение зависимостей от других модулей и т. Д. Вроде как медленно кружит в баге, как стервятник ..

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

Answer 10

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

Если я смогу выявить повторяющуюся ошибку, я обычно стараюсь изолировать задействованные компоненты, пока не найду проблему. Часто я трачу немного времени на исключение дел, чтобы утверждать однозначно: проблема не в компоненте X (или процессе Y и т. Д.).