Целенаправленная отладка без использования отладчика? - PullRequest
13 голосов
/ 09 октября 2009

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

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

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

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

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

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

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

Ответы [ 20 ]

2 голосов
/ 09 октября 2009

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

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

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

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

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

1 голос
/ 26 ноября 2009

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

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

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

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

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

1 голос
/ 09 октября 2009

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

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

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

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

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

1 голос
/ 09 октября 2009

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

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

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

1 голос
/ 09 октября 2009

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

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

1 голос
/ 09 октября 2009

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

0 голосов
/ 18 апреля 2014

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

0 голосов
/ 09 октября 2009

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

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

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

0 голосов
/ 09 октября 2009

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

0 голосов
/ 09 октября 2009

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

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

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

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