Целеустремленно отлаживая, не используя отладчик?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For the average little silly bug, it's faster for me to read the code over 2 or 3 times, debugging in my mind than to fire up the debugger and get the program into the required state.

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

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

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

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

• Какой тест не удался? Если ответ - «нет теста», то отсутствие теста на условие отказа является более серьезной проблемой, которую необходимо решить в первую очередь.

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

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

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

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

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

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

I'd prefer to use TDD and add a test that breaks the code. Then it's easy to see where the bug is occurring and to fix it without a debugger and now I've got a test that will prevent that bug.

Different tools for different jobs. Just like you wouldn't use Perl for everything, you're not going to use a Debugger for every bug. Sometimes using a debugger fits a problem and sometimes it doesn't.

Take for example the bug that turned up in one of our products. It was pulling the last window to have focus back to focus after a print method. It couldn't be repo'd when the debugger was attached, but could when it was. This problem eventually was solved with good old fashioned Console.Write() statements.

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

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

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

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

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

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

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

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

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

My favorite feature of the Visual Studio Debugger is the Immediate Window. I'm not sure if this is provided in many other environments, but it is damn helpful sometimes.

A few examples of how:

• Data coming back from a database isn't casting correctly. Fire up the debugger and try a few casts until you get the right one (oops the int was short or the bool was a byte, etc),

• Web apps with nested controls (e.g. TemplateFields in a GridView)...I have a reference to a specific control but want to get the grid row that I'm in (or viceversa). I can code a few nested FindControls() and hope for the best, or I can just do it in the immediate window until I find the control that I want.

Every project I've worked on so far (only 1-2 years corporate experience), I've used the debugger/Immediate Window at least once or twice. It may just speak to my inexperience, but I find it's extremely helpful for getting a good understanding of what is happening in a complex system.

Взгляните на Mindscape LightSpeed. Он включает запросы LINQ и конструктор Visual Studio, который изначально работает с MySQL. Вы также можете обновить свою базу данных или синхронизировать изменения из своей базы данных прямо из дизайнера LightSpeed.

Mindscape также публикует репозиторий помощников для asp с открытым исходным кодом.

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

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

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

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

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

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

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

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

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

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

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