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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Понимание проблемы важно, и использование отладчика не заменяет ее.
2. Гадание - плохой подход к отладке. Если ваши коллеги действительно используют догадки, а не думают о проблеме, то они делают плохую работу. Догадывание означает вставлять в код произвольные операторы печати и надеяться найти что-то полезное.
3. Если ваши коллеги искренне не знают, как использовать отладчик (вместо того, чтобы не использовать его), тогда да, они некомпетентны, как кто-то, кто не знает синтаксиса языка, который они должны использовать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а также

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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