Лучшие практики для отладки

Question

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

Мой подход выглядит примерно так.

• Воспроизведите проблему. В идеале максимально уменьшить входной сигнал.

• Изучите, что идет не так, и перечислите теории, где может быть ошибка.

• Изучите одну теорию за раз, отлаживая эту конкретную область кода.

Повторите шаги по мере необходимости.

Для сложных проблем отладки я часто работаю с коллегой. Для WinDbg это особенно полезно.

Любые другие полезные советы или рекомендации по отладке?

Answer 1

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

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

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

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

НТН.

ура

Rob

Answer 2

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

Answer 3

Я не уверен, где я читал о "отладке резиновой утки", но я думаю, что это здорово. Основная идея заключается в том, чтобы поставить на стол резиновую утку и объяснить ей код. Идея состоит в том, что, объясняя код утке, вы в конце концов обнаружите, что говорите: «Вот, это происходит», и вы заметите, что «это» - это не то, что вы собираетесь делать.

Не имея утки, я обнаружил, что просто прошёл код и объяснил самому себе. Это работает, но я все еще думаю, что могу принести утку.

[EDIT] Я нашел, где я читал о резиновой утке Отладка резиновой утки

Answer 4

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

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

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

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

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

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

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

Так что моя «лучшая практика» - не двигаться дальше, пока я не буду уверен, что понимаю и не угадаю.

Answer 5

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

• Внедрение модульного тестирования, предпочтительно в форме TDD, заставляет вас оставаться на задании и развиваться только с целью сдачи тестов. Труднее "бродить", когда вы кодируете тест, а не задачу.
• Вступайте в практику регулярного рефакторинга вашего кода. Небольшие точечные методы легче отлаживать, чем монолитные методы «мастер на все руки».
• Используйте членов вашей команды. Часто добавление дополнительного набора глаз может помочь избавиться от чего-либо. Скорее всего, если вы не найдете что-то относительно быстро, вы некоторое время будете продолжать упускать это из виду.
• Вы всегда можете откатить код в своей системе контроля версий, чтобы попытаться определить, какая версия файла вызвала появление ошибки. Как только вы это сделаете, вы сможете различить между последним хорошим и первым плохим и просто сосредоточиться на изменениях между ними.

Answer 6

Барьеры входа для отладчика в VS.NET с таким языком, как C # или VB.NET, настолько смехотворно низки, что зачастую проще вставить одну или две точки останова, если вы знаете, что проблема, и просто пройти через них.

Иногда я использую Edit & Continue для написания кода. Это великолепно. Вы можете увидеть результаты сразу. Часто это наиболее полезно, когда есть какой-то алгоритм или относительно сложный для понимания цикл.

Answer 7

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

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

Answer 8

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

http://www.amazon.com/Debugging-Applications-Microsoft%C2%AE-Microsoft-Pro-Developer/dp/0735615365/ref=sr_1_1?ie=UTF8&s=books&qid=1238705836&sr=1-1

альтернативный текст http://ecx.images -amazon.com / images / I / 51RQ146x9VL._SS500_.jpg

Answer 9

Это ни в коем случае не технический совет, но он часто работает в моем случае.

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

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

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

Answer 10

Я перефразирую мой ответ в аналогичной теме (что по сути является последним пунктом в ответе joseph.ferris на эту тему ):

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

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