Целенаправленная отладка без использования отладчика?

Ответ 1

Не используя отладчик для F10/F11 через ваш код, вы можете стать лучшим разработчиком.

Во время моей первой работы я много программировал в Linux, где отладчик Visual Studio недоступен. Поскольку отладка была сложной, я научился анализировать свой код и действительно понимать, как он работает. Из-за этого я стал лучшим разработчиком.

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

Ответ 2

Причина использования отладчика в качестве последнего средства?

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

Ответ 3

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

Мой любимый (если это правильный текст) пример, это ошибки памяти. На языке, подобном C или С++, неправильное использование системы памяти (двойное удаление, доступ к объектам через мертвые указатели, завершение конца массива) может привести к повреждению программы таким образом, что проблема не проявится нигде рядом с оригиналом причина.

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

Теперь мы можем начать аргумент, что автоматические средства памяти и библиотеки проверки границ являются отладчиками!; ^) ~

Ответ 4

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

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

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

Ответ 5

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

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

• Какой тест не прошел? Если ответ таков: "нет теста", то отсутствие теста на условие отказа - это более глубокая проблема, которая должна быть исправлена ​​в первую очередь.

• Какую информацию имеет исключение? (Это предполагает среду с исключениями). Если ответ "нет исключения", или исключение не имеет большого контекста, а затем сканирование мест, где проглатывается исключение, или добавление большего количества контекста к исключению - это более глубокая проблема, которая должна быть исправлена ​​в первую очередь.

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

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

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

Конечно, бывают случаи, когда ошибка возникает в одной строке, например, не проверяя нулевой указатель/ссылку и т.д., но не являются ли эти "простые" ошибки теми же типами ошибок, которые устраняют современные IDE и инструменты? Просто запустите инструмент lint/static-analysis и прислушайтесь к предупреждениям - вы больше не будете получать эти типы ошибок. Тогда у вас останутся такие вещи, как ошибки дизайна, которые требуют рассуждения человеческого разума - как может выглядеть отладчик?

Ответ 6

Операции печати, которые сбрасываются в файл, могут выполняться текстовым способом. grep, sort, sed и awk могут помочь в сложных вопросах отладки. Также можно написать небольшую программу для разбора сбрасываемого текста, если это необходимо.

Ответ 7

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

Ответ 8

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

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

Ответ 9

Две причины отказа от использования отладчика:

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

Я не знаю, являюсь ли я "таким программистом", но не вижу, что вам нужно для отладчика:

• Перерыв в точке останова и/или разрыв при вызове исключения
• Проверять данные и проверять столбец во время перерыва

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

Ответ 10

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

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

Две вещи, которые действительно делают отладчик userfil: условные точки останова и инспектор объектов. Они, безусловно, являются наиболее полезными функциями отладчика для меня.

Ответ 11

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

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

Ответ 12

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

Ответ 13

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

Имея рабочий отладчик или среду эмуляции, я бы иногда спасал мне дни или недели, переделывал, диагностировал.

Ответ 14

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

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

tl; dr: моя причина использовать отладчик в качестве последнего средства - это скорость.

Ответ 15

Моя любимая функция отладчика Visual Studio - это окно Immediate. Я не уверен, что это предусмотрено во многих других средах, но иногда это полезно.

Несколько примеров того, как:

• Данные, возвращаемые из базы данных, не корректно отображаются. Запустите отладчик и попробуйте несколько отбрасываний, пока вы не получите правильный (oops int был коротким или bool был байтом и т.д.),

• Веб-приложения с вложенными элементами управления (например, TemplateFields в GridView)... У меня есть ссылка на конкретный элемент управления, но я хочу получить строку сетки, в которой я находится (или наоборот). Я могу закодировать несколько вложенных FindControls() и надеюсь на лучшее, или я могу просто сделать это в ближайшем окне, пока не найду элемент управления, который я хочу.

Каждый проект, над которым я работал до сих пор (всего 1-2 года), я использовал отладчик /Immediate Window хотя бы раз или два. Он может просто говорить о моей неопытности, но я считаю, что это очень полезно для хорошего понимания того, что происходит в сложной системе.

Ответ 16

Я использую отладчик, когда:

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

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

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

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

Ответ 17

Эти ребята происходят из эпохи unix, где полноценная IDE не под рукой. Вот почему добавление printf намного быстрее, чем запуск GDB.

В настоящее время установка точки останова в visual studio - это самый быстрый способ отладки, поэтому каждый использует

На разных платформах, таких как встроенные устройства, наличие printfs в файле журнала или что-то подобное по-прежнему является самым быстрым вариантом

Ответ 18

Наше программное обеспечение работает на Linux/Solaris/HPUX/AIX/FreeBSD/MacOS, и очень сложно получить отладчики для некоторых из этих платформ, и намного проще просто добавить дополнительный код трассировки.

Ответ 19

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

Следы являются основой для начала работы над проблемой

NB Встроенное приложение в автомобиле.

Ответ 20

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