Это хорошая привычка работать в режиме отладки?

Question

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

Плюсы отладчика

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

Минусы отладчика

• Повышение производительности может замедлить итерации
• (Правка) Tunnel Vision : отладка симптома может отвлечь вас от определения причины, когда сбой происходит спустя много времени после дефекта или далеко от него
• Он может «помочь» вам, инициализируя переменные или иным образом маскируя ошибки, что впоследствии может привести к неожиданностям
• И наоборот, есть странная ошибка, что только возникает в конфигурации отладки; отслеживание этого может быть пустой тратой усилий (хотя, это часто указывает на более глубокую, более тонкую проблему, которую стоит стоит исправить)

Конечно, они общие - они сильно различаются в зависимости от языка, окружающей среды и ситуации - но каковы другие соображения?

Answer 1

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

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

Тем не менее, я запускаю отладчик только в двух обстоятельствах:

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

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

Я думаю, что это ошибка, а не то, чтобы всегда иметь отладчик наготове или даже запускать код всегда подотладчик, но для запуска DEBUG BUILD.Вы уже указали на худшую из проблем с этим.Распределение памяти, как правило, происходит по-разному, неинициализированные данные заполняются разными значениями и т. Д. Если вы впервые запускаете сборку релиза за несколько недель до того, как QA получит его (или, в сумасшедшем магазине, до того, как вы начнете отправлять)) вы можете столкнуться с миром серьезной боли.

Я только один раз видел ошибку, которая проявлялась только в отладочной сборке.Несколько человек утверждали, что это не важно, потому что это не то, что мы отправляем, но я все равно посмотрел на это и обнаружил ДЕЙСТВИТЕЛЬНО плохую проблему.

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

Я обнаружил, что написание printf намного лучше, чем отладка в python.Это просто потому, что это проще, и вам нужно перекомпилировать.Наблюдать за переменными даже с помощью pydev в eclipse - это больно. Одна из причин состоит в том, что я всегда «отлаживал» код, который занимал всего несколько десятков строк кода.Я использую отладчик.Различия в том, что в C есть указатели и массивы, и вы хотите наблюдать за структурами, и непросто написать простой printf, чтобы увидеть, работает ли ваш код сериализации правильно.

Answer 6

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

Когда я занимался программированием на C ++ / MFC, я ставил ASSERTS повсюду (или Tracing, как вы это описали) и обнаруживал много ошибок и находил много неправильных предположений в процессе.

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

Answer 7

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

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

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