Какая польза от использования отладчика?

101

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

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

Можно ли управлять комплексом без отладчика? Желательно ли это? Какие преимущества можно получить, используя « экстрасенсорную отладку» ?

Джонатан
источник
19
Привет, Джонатан, я пересмотрел твой вопрос, чтобы избежать ловушек разглагольствования и оставить вопрос открытым: я думаю - как сформулировано сейчас - это достаточно приличный, отвечающий на вопрос.
Пример: рассмотрим код a = 6/3. Вместо того, чтобы вводить опечатку, вы набрали a = 6/2.. Теперь вы ищете на уровне мнемоники. Инструкции ADD, JMP, а затем вы обнаружите, что вместо 2 была одна дополнительная итерация, и вы понимаете, что у делителя есть неправильная опечатка. Теперь вы можете сделать вывод, насколько нелепо всегда использовать отладчик.
EAGER_STUDENT

Ответы:

153

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

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

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

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

оборота
источник
27
+1 Я считаю «программирование угадыванием» загруженной фразой. Там нет замены для мышления. ОП не объясняет, насколько эффективным является «угадывание». Я сомневаюсь, что это чисто догадки (то есть спагетти на стене), а скорее использование дедуктивных рассуждений. Отладчики имеют свое место, но они не панацея для дедуктивного мышления и простого понимания кода.
Билл
8
@DJClayworth Это не совсем точно: иногда попытка использовать отладчик - плохой выбор, даже если в вашем распоряжении хороший отладчик: в конечном итоге вы теряете много времени, не добившись многого. Один случай, который сразу приходит мне в голову, - это решение проблем параллелизма; другие отлаживают рекурсивные алгоритмы с высокими коэффициентами ветвления, некоторые алгоритмы динамического программирования и процедуры обслуживания аппаратных прерываний. Конечно, глупо не использовать отладчик, когда он вам действительно нужен, но решение, когда вы начинаете нуждаться в отладчике, является весьма индивидуальным выбором.
dasblinkenlight
9
+1 хотя я нахожу отладчик бесценным для некоторых типов ошибок (особенно в более сложных алгоритмах), на самом деле ничто не заменит просто хорошего понимания кода
Крис Браун
7
@DJClayworth Я сознательно пошел на более сильное утверждение, чем «несколько раз, когда лучше не использовать отладчик»: мое краткое знакомство с конкурентным программированием научило меня тому, что инстинктивное использование отладчика - не самое эффективное поведение для меня . В эти дни я начинаю с (1) быстрого перечитывания кода и (2) изучения трассировки отладки (при ее наличии) перед (3) поиском отладчика. Во многих случаях третий шаг не нужен, потому что я определяю проблему на шагах (1) или (2), пишу модульный тест, который воспроизводит проблему, и кодирую исправление, и все это без использования отладчика.
dasblinkenlight
10
Я думаю, что вы на самом деле имеете в виду, что программист должен иметь последовательность отладки , вместо того, чтобы нажимать волшебную кнопку «найти ошибку». Отладчик - чрезвычайно мощный инструмент, но вы не запускаете бензопилу, чтобы обрезать живые изгороди.
Спенсер Рэтбун
41

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

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

AProgrammer
источник
35

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

Я склонен следовать совету отладки: 9 обязательных правил для нахождения даже самых неуловимых проблем с программным и аппаратным обеспечением (Дэвид Аганс), и этот подпадает под прямое руководство «Брось думать и смотреть»

JohnFx
источник
12
Я не согласен, хотя я не буду понижать голос. Как говорит Делнан, если вы можете понять, что делает код, может быть быстрее определить, что он делает неправильно, чем пройтись по отладчику и попытаться найти, когда он работает неправильно. Тем не менее, разработчик, который отказывается использовать отладчик, когда они не могут определить проблему при чтении кода, делает большую ошибку.
@ Марк плюс дополнительный бонус за неправильную диагностику проблемы и подключение нового дефекта.
Кит Брингс
11
@ Марк Баннистер - я понимаю, что вы говорите. Позвольте мне изменить это, чтобы, если вы искали проблему в коде более 15 минут, отказаться от использования отладчика и не быть упрямым.
JohnFx
9
Я думаю, что хороший программист не должен зависеть от отладчика. Это не должно удерживать его от немедленного использования (если
таковое
1
@ Марк, если вы не работаете с очень маленькой базой кода, я думаю, что невозможно понять каждую строку кода. 95% моих текущих ошибок решаются так, как вы описываете, но самые хитрые - то, где вам нужен отладчик.
wobbily_col
31

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

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

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

JQA
источник
18
+1 «Большинство ошибок вызвано предположениями» - очень мудрые слова
ZJR
15
Я предполагаю, что все ошибки вызваны предположениями. (Видите, что я там делал? = P)
dan_waterworth
4
@ZJR: Вот почему assertтак здорово. Проверьте свои предположения. Проверяйте их часто.
Zan Lynx
@dan_waterworth: Не правда. С одной стороны, это может быть опечатка.
Томас Эдинг
13

Ваше лучшее руководство по практике отладки - книга Стива Макконнела Code Complete . В главе 23 подробно описывается отладка, и я хочу выделить несколько моментов из нее.

  1. Понимание проблемы важно, и использование отладчика не заменяет ее.
  2. Гадание - плохой подход к отладке. Если ваши коллеги действительно используют догадки, а не думают о проблеме, то они делают плохую работу. Догадывание означает вставлять в код произвольные операторы печати и надеяться найти что-то полезное.
  3. Если ваши коллеги искренне не знают, как использовать отладчик (вместо того, чтобы не использовать его), тогда да, они некомпетентны, как кто-то, кто не знает синтаксиса языка, который они должны использовать.
DJClayworth
источник
2
Хотя я согласен с вами в большинстве ваших постов, я считаю, что некомпетентность несправедлива. Разрабатывать можно без использования отладчика, это просто неэффективно. Некоторые люди узнают об отладчиках раньше других!
ChrisFletcher
Я бы не стал разбрасываться словами «некомпетентный». Я знаю кого-то, кто полностью отлаживает печатные заявления, и никто другой не приблизится к тому, чтобы сделать вклад, который он делает.
Майк Данлавей
2
@MikeDunlavey Знает ли этот человек , как использовать отладчик, и решил не использовать его? Хорошо. Если они не знают, то я поддерживаю свое заявление.
DJClayworth
2
Встаньте, как хотите, может легко наступить момент, когда это прилагательное может быть применено к вам. Тогда вы поймете - это школьные вещи.
Майк Данлавей
9

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

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

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

FrustratedWithFormsDesigner
источник
8

Я удивлен, что в обсуждении этой темы не упоминается «юнит-тестирование».

Поскольку я занимаюсь разработкой на основе тестов, я не трачу много времени на отладчик. 10 лет назад я покорно обходил отладчик:

  1. После написания фрагмента кода, чтобы убедиться, что он работает и
  2. Когда я получил сообщение об ошибке, чтобы попытаться диагностировать проблему

После 10 лет тестовой разработки я обнаружил, что я, как программист, гораздо более продуктивен, если:

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

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

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

Джефф Гровер
источник
+1 Часто быстрее добавить оператор печати и повторно запустить тест, а затем использовать отладчик.
Уинстон Эверт
@ winston - часто быстрее запустить отладчик, чем писать несколько операторов печати, пока вы не найдете местоположение проблемного кода. Все это зависит. Простые проблемы обычно решаются быстрее, чем вы описываете, но сложные проблемы - то, где вам нужен отладчик. Возможность использовать оба способа лучше, чем строго придерживаться любого абсолютного принципа.
wobbily_col
7

Лично я стараюсь свести к минимуму использование отладчика с помощью:

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

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

thSoft
источник
6

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

Кевин Хсу
источник
5

Отладка - это очень полезный инструмент для проверки состояния объектов и переменных в вашем коде во время выполнения.

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

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

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

В отличие от полезности отладчиков в вышеупомянутых примерах, я нахожу это трудным и несколько бесполезным для использования, когда задействованы многопоточность (то есть параллелизм, асинхронная обработка). Это может помочь, но легко потерять ориентацию в многопоточном тумане, когда точки останова отладчика попадают в один поток в точке A и совершенно отдельный поток в точке B. Разработчик вынужден выдвигать новую точку останова ». мыслительный процесс "на вершине" стека "его мозга и ориентироваться на код в точке новой точки останова. После того, как релевантность точки останова B уменьшается, разработчик затем переключается обратно на первую точку останова и должен вспомнить, что он / она высматривал до запуска точки останова B. Я знаю, что это может быть запутанным объяснением,

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

В заключение, по моему честному мнению:

  • Отладка при использовании параллелизма = повышенная тенденция терять фокус "отладочного мышления"

а также

  • в любое другое время = увеличенная производительность отладки, потому что ваше внимание не прерывается неожиданными остановками (неожиданными из-за условий гонки).
TrueLifeCoder
источник
2
+1 за постановку вопроса об отладке в параллельных средах, где полезность традиционных отладчиков часто уменьшается почти до нуля.
dasblinkenlight
4

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

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

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

pcalcao
источник
4

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

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

Недостаток, как правило, занимает гораздо больше времени.

user977645
источник
4

Хм, это зависит от человека. Лично я сам не использую отладчики. Когда я программирую микроконтроллеры, я в основном использую светодиоды или записываю данные в EEPROM для «отладки» кода на нем. Я не использую JTAG.

Когда я программирую программное обеспечение для ПК или серверов, я склонен использовать журналирование и много консольного вывода. Для языков стиля C я использую директивы препроцессора, а в Java я использовал уровни журналов.

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

Полемон
источник
4

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

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

Различные инструменты / платформы предпочитают разные методы отладки (отладчик, ведение журнала, модульные тесты и т. Д.). Пока разработчики знакомы с некоторыми методами для своей платформы / инструмента, в дополнение к простой проверке кода, они могут опытный разработчик, но если у них есть только одна хитрость, когда дело доходит до отладки, то они в конечном итоге столкнутся с ошибкой, которую не могут найти или исправить.

Джим Маккит
источник
4

Много ответов, но не упоминание о Гейзенбаге ?!?!

Heisenbugs происходят потому, что обычные попытки отладки программы, такие как вставка выходных операторов или запуск ее в отладчике, обычно модифицируют код, изменяют адреса памяти переменных и время ее выполнения.

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

bchetty
источник
3

Я недавно прочитал аргумент против отладки отладчика (или это был StackOverflow?). У вас должны быть тестовые случаи против вашего кода. Если ваши тесты пройдены, ваша отладка, вероятно, не будет исправлять ошибку (предположим: вы будете отлаживать с данными, похожими на ваши тестовые данные).

С другой стороны, регистрация обязательна. Если вы пройдете тестирование и развернетесь в рабочей среде, вы можете обнаружить, что у вас есть ошибка. Доказательством ошибки является то, что произошло в прошлом. то есть кто-то говорит: «Как это туда попало?» Если у вас нет хороших журналов, вы никогда не найдете причину. Даже отладчик может быть бесполезен в тот момент, потому что вы не знаете, как выглядели данные, которые на самом деле использовали ошибку. Вы должны быть в состоянии отладить приложение из журналов.

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

ccoakley
источник
3

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

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

Я «миньон дебаггера» или эти парни слишком хардкорные?

Ни. Это просто люди, которым нравится усложнять свою жизнь.

BЈовић
источник
2

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

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

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

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

Кристиан П
источник
2

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

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

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

скоро
источник
0

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

yarony
источник
-1

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

Кроме того, учтите, что не все, кто занимается отладкой кода, знакомы с этим кодом. Многие временные подрядчики оказываются в среде, где у них есть только общий идеал происходящего. Им даже может быть дано подробное описание среды - или 20-летняя карта схемы и руководство по соглашениям о тайных именах (попробуйте понять разницу между таблицей X1234 и таблицей X4312 с полями F1, F2 и F3 [да, мусор, как этот существует], когда вы новичок), но часто это описание неверно; в противном случае, почему возникает «загадочная» ошибка.

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

H Грин
источник
2
это соломенное чучело разглагольствовать не отвечают задан вопрос, нигде нет утверждения «Настоящие Программистам не нужны отладчики»
комар