Ответы:
Не принимайте ничего
Часто соблазнительно просто сказать «о, я знаю, что делает этот фрагмент кода, это нормально». Не делай этого. Проверьте каждое предположение и тщательно проработайте все.
Тестирование пошагово .
Сначала углубляйтесь в свой код и тестируйте его, начиная с самого маленького модуля, постепенно повышающегося. Таким образом, вы не испытываете особого стресса, пытаясь выяснить, где именно может быть проблема.
Это также означает, что это влияет на меньшее количество кода за раз, так как вы перемещаетесь постепенно ... поскольку иногда у меня возникали проблемы, когда я что-то исправлял, и это приводило к поломке множества других вещей. Я отдаю должное моему боссу за это, поскольку он научил меня этому, когда я бездельничал.
Разделяй и властвуй - это хороший подход. Попробуйте определить некоторые видимые входные данные (пользовательский ввод / сетевое событие ...) и выходные данные (журнал, выходные данные пользователя, исходящее сетевое сообщение ...), между которыми существует проблема. Попробуйте разместить отпечатки в значительных кусках или значимых точках между ними и попытаться сузить область ошибки в коде.
Разделяй и властвуй также может очень хорошо работать в случае регрессии над кодом, контролируемым версией Найдите две сборки - одна там, где она работает как положено, другая с регрессией. Сократите разрыв до тех пор, пока вы не останетесь с кучей проверок в качестве потенциальных подозреваемых.
Вместо того, чтобы разбивать двоичные ошибки, пишите тесты в форме
Чтобы проверить, что вы на самом деле знаете, чтобы быть правдой о функционировании приложения в сравнении с тем, что вы считаете правдой.
Большинство IDE позволяют легко извлекать методы и создавать заглушки для тестирования xUnit. Используйте это.
Почему бы не посыпать отладками? Потому что после того, как вы закончите, вам, вероятно, придется отменить большую часть этой работы и удалить изрядное количество этих отладок. Когда вы пишете тесты, ваша отладка поможет в предотвращении и обнаружении будущих ошибок.
Продолжайте отлаживать. Если вы будете много отлаживать, вы станете лучше.
Как уже говорили другие - ничего не предполагайте. Это особенно верно, если его код вы написали. При отладке чужого кода вы, скорее всего, будете тормозить, потому что код для вас новый или вы не доверяете кодеру. При отладке собственного кода слишком легко предположить, что вы написали его правильно, помедленнее!
Для фактического процесса отладки:
Добавление модульных тестов и ведение журнала сначала более эффективно, чем сначала использование отладчика. Кроме того, вы получаете дополнительное преимущество в виде модульных тестов, которые помогают не вводить будущие ошибки, а ведение журнала поможет отлаживать сеансы в будущем.
Прежде чем перейти к небольшому фрагменту кода, посмотрите, сможете ли вы точно определить результат. Это, как правило, идет вразрез с тем, что вы ничего не предполагаете (за что я проголосовал, кстати, но, по мере того, как вы набираетесь опыта, это может помочь сузить область поиска)
Это может звучать тривиально, но изучите нюансы вашего отладчика и изучите горячие клавиши. Иногда отладчики могут быть достаточно медленными, чтобы ваш разум задавался вопросом, когда вы проходите через них. Если вы можете идти в ногу с машиной и не копаться, это может помочь.
Если вы можете изменить код во время отладки:
нравится:
bool isLessThan5 = a < 5;
bool isGreaterThan10 = a > 10;
if ( isLessThan5 || isGreaterThan10 )
{
// more code here
}
вместо того:
if ( a < 5 || a > 10 )
{
// more code here
}
Для случаев, когда вы не можете отладить все, по какой-либо причине, научитесь «резиново-утиным» с коллегой. Иногда акт объяснения проливает свет. (хорошо, возможно это не совсем в теме вопросов, но я думаю, что это достаточно близко, чтобы оправдать упоминание)
Две вещи, основанные на том, что большую часть последних 22 лет мы потратили на поддержку кода, написанного другими людьми.
Поймите, какие ошибки вы обычно пишете.
Например, я очень дотошный кодер, поэтому, как только мой код компилируется, он обычно не содержит тривиальных ошибок. Так что мои ошибки имеют тенденцию быть странными сложными вещами, такими как тупиковые блокировки. С другой стороны, у меня есть друг, который в основном пишет тривиальные ошибки - точки с запятой в конце C ++ для циклов, поэтому следующая строка выполняется только один раз, такого рода вещи.
Не думайте, что другие люди пишут такие же ошибки, как и вы.
Я не знаю, сколько раз я потратил впустую время на то, чтобы вытащить большие отладочные пистолеты, предполагая, что жук был моим видом очень тонкой странной вещи, только чтобы мой друг посмотрел через мое плечо и сказал: «Вы заметили это дополнительное точка с запятой?" После многих лет этого я сначала обращаюсь к банальным, низко висящим фруктам, когда смотрю на кодекс других людей.
Знай свои инструменты. Например, в отладчике Visual Studio есть замечательная функция TracePoints, которая похожа на точки останова, но вместо того, чтобы останавливать код, вместо этого вставляет оператор трассировки в выходные данные отладки.
Чтение книг или посещение занятий по использованию вашего отладчика настоятельно рекомендуется. Я взял пару уроков и прочитал несколько книг Джона Роббинса, которые сильно повлияли на мою эффективность в качестве отладчика.
Написание автоматизированного модульного теста и других типов интеграционных и функциональных тестов.
Чем больше у вас автоматических тестов, тем меньше времени вам нужно проводить в отладчике.
Также хороший дизайн - ТВЕРДЫЕ принципы. Если вы пишете небольшие, специализированные классы и предпочитаете композицию наследованию, устранению дублирования и т. Д., Ваш код всегда будет легче отлаживать.
Я считаю, что хорошо разработанный код приводит к другому набору ошибок, который плохо разработан. Вообще говоря, хорошо разработанный код создает ошибки, которые легче найти, воспроизвести и исправить.
Исключением (и всегда есть один) является многопоточный код :-)
Если вы сузили область до небольшого региона, но все еще не можете обнаружить ошибку, попробуйте опцию «Просмотр кода + сборка» в вашем отладчике. Зная достаточно ASM, чтобы сказать «здесь должна быть ветвь» или «почему она только копирует низкое слово?» будет часто точно определять ошибку кодирования.
Ознакомьтесь с очень ценной книгой Андреаса Зеллера « Почему не работают программы: руководство по систематической отладке ». Он познакомит вас со многими методами, теориями и инструментами, некоторые из которых находятся на переднем крае исследований.
Слайды для книги доступны онлайн, но сама книга легче читать.
Книга поможет вам начать и заставит вас более научно думать об отладке, но она не заменит практики. Возможно, вам придется писать и отлаживать в течение 10 лет, прежде чем вы увидите, как улучшается ваша производительность на порядок. Я до сих пор помню, как у меня на челюсти в Sun было замечено, что старшие разработчики, которые программируют для Unix в течение 30 лет, находят неясные многопоточности или параллельные ошибки в считанные минуты. Опыт имеет значение!