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

Question

В главе 5 из "Практика программирования" Брайан Керниган и Роб Пайк напишите:

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

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

Итак, я хотел бы спросить сообщество stackoverflow:

Если вы программист, который рассматривает инструменты, называемые «отладчики», в качестве крайней меры (кроме получения начальной трассировки стека), каковы ваши причины для использования других методов в первую очередь?

Одна (1) причина за ответ для более простого голосования, пожалуйста!

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

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

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

Answer 10

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

При этом, после многих лет опыта программирования, вам нужно все меньше и меньше НУЖДАТЬСЯ в отладчике, поскольку вы больше способны просто "знать", почему проблема возникла.

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