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

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

Случайно это - одна из причин, я обычно выполняю свои проекты веб-приложения VS через IIS не Кассини больше.

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

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

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

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

Хорошая практика должна удостовериться, что Вы не фиксируете признак, но причину.

Часто, можно было бы видеть нечетное значение при отладке и зафиксировать его там, не проверяя то, что заставило значение добираться там во-первых. Это - конечно, очень плохая идея.

BTW, это - то, почему Linus возразил добавляющей встроенной поддержке отладки ядра.

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

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

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

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

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

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

Я не уверен, где я читал об "Отладке Резиновой уточки", но я думаю ее великое. Основная идея состоит в том, чтобы установить резиновую уточку на Вашем столе и объяснить код ему. Идея состоит в том, что, поскольку Вы объясняете код утке, Вы будете в конечном счете говорить "Теперь, это происходит", и Вы заметите, что 'это' не то, что Вы намереваетесь произойти.

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

[РЕДАКТИРОВАНИЕ], которое я нашел, где я читал об Отладке Резиновой уточки резиновой уточки

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

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

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

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

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

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

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

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

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

Таким образом, моя 'лучшая практика' не должна идти дальше, пока я не уверен, что понимаю, и не предположение.

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

• Реализация поблочного тестирования, предпочтительно в форме TDD, вынуждает Вас остаться на задаче и разработать только с целью того, чтобы проходить тесты. Более трудно "блуждать", когда Вы кодируете к тесту, вместо к задаче.
• Войдите в практику регулярного рефакторинга Вашего кода. Маленькие, методы на точке легче отладить, чем монолитные методы "мастера на все руки".
• Используйте своих членов команды. Часто добавление дополнительной пары глаз может помочь промыть что-то. Возможности, если Вы не находите что-то относительно быстрым способом, Вы собираетесь продолжить пропускать его некоторое время.
• Можно всегда откатывать код в системе управления версиями, чтобы попытаться изолировать, какая версия файла вызвала введение ошибки. После того как Вы делаете это, Вы можете разность между последней пользой и первый плохой и просто сфокусироваться на изменениях между двумя.

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

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

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

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

HTH.

удачи,

Ограбить

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

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