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

Считайте овладение книгой "Отладкой" David J Agans. Подзаголовок является "9 Необходимыми Правилами для Нахождения Даже Самых Неуловимых проблем Программного и аппаратного обеспечения". Его список отладки правил — доступный в форме плаката на веб-сайте (и существует ссылка для книги, также):

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

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

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

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

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

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

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

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

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

Создание и репродуцирование ошибки с входом, превращенным на максимальный уровень.

Исследование системы регистрирует для чего-либо аварийную сигнализацию.

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

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

Примените дедуктивное обоснование и примените принципы Бритвы Ockham.

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

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

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

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

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

Отладка 101:

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

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

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

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

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

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

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

Мой метод отладки отличается, вероятно, потому что я - все еще новичок.

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

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

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

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

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

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

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

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

• если нет, добавьте тест, который не прошел

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

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

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

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

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

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

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

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

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