Часто соблазнительно просто сказать «о, я знаю, что делает этот фрагмент кода, это нормально». Не делай этого. Проверьте каждое предположение и тщательно проработайте все.
+1. Абсолютно. Будьте готовы быть удивленными тем, как некоторые вещи, которые, как вы думали, вы знаете, будут подшучивать над вами.
aufather 13.10.10
у меня работает :)
сетзамора 13.10.10
3
Отладка чужого кода - это огромная трата времени, убийца производительности, но это так. Единственный раз, когда действительно имеет смысл исправлять ошибки других, это когда они ушли. То, что я НЕНАВИЖУ, НЕНАВИЖУ, то, что старший кодер проходит через объективный дерьмовый код, затем задает вопрос, чтобы добиться своевременного прогресса, и читает лекцию о совершенствовании моих навыков в изучении существующей кодовой базы. В отличие от изучения матери-природы, решение проблем, вызванных человеком, вряд ли доставляет удовольствие. По крайней мере, я получил свой ответ. Обратной ситуации не произойдет, потому что я просто лучше и оставляю меньше ошибок.
Работа
1
@Job: ... хорошо? Возможно, вы хотели оставить этот комментарий к сообщению? :)
Адам Лир
Это! Глупо слепо доверять любому небольшому кусочку вашего кода, если вы отлаживаете странную проблему и код кажется нормальным.
Дан,
7
Тестирование пошагово .
Сначала углубляйтесь в свой код и тестируйте его, начиная с самого маленького модуля, постепенно повышающегося. Таким образом, вы не испытываете особого стресса, пытаясь выяснить, где именно может быть проблема.
Это также означает, что это влияет на меньшее количество кода за раз, так как вы перемещаетесь постепенно ... поскольку иногда у меня возникали проблемы, когда я что-то исправлял, и это приводило к поломке множества других вещей. Я отдаю должное моему боссу за это, поскольку он научил меня этому, когда я бездельничал.
Разделяй и властвуй - это хороший подход. Попробуйте определить некоторые видимые входные данные (пользовательский ввод / сетевое событие ...) и выходные данные (журнал, выходные данные пользователя, исходящее сетевое сообщение ...), между которыми существует проблема. Попробуйте разместить отпечатки в значительных кусках или значимых точках между ними и попытаться сузить область ошибки в коде.
Разделяй и властвуй также может очень хорошо работать в случае регрессии над кодом, контролируемым версией Найдите две сборки - одна там, где она работает как положено, другая с регрессией. Сократите разрыв до тех пор, пока вы не останетесь с кучей проверок в качестве потенциальных подозреваемых.
Вместо того, чтобы разбивать двоичные ошибки, пишите тесты в форме
Данный...
Когда...
Ожидайте ...
Чтобы проверить, что вы на самом деле знаете, чтобы быть правдой о функционировании приложения в сравнении с тем, что вы считаете правдой.
Большинство IDE позволяют легко извлекать методы и создавать заглушки для тестирования xUnit. Используйте это.
Почему бы не посыпать отладками? Потому что после того, как вы закончите, вам, вероятно, придется отменить большую часть этой работы и удалить изрядное количество этих отладок. Когда вы пишете тесты, ваша отладка поможет в предотвращении и обнаружении будущих ошибок.
Абсолютная отладка - это само по себе искусство, особенно отладка кода других людей.
Gratzy 13.10.10
2
Как уже говорили другие - ничего не предполагайте. Это особенно верно, если его код вы написали. При отладке чужого кода вы, скорее всего, будете тормозить, потому что код для вас новый или вы не доверяете кодеру. При отладке собственного кода слишком легко предположить, что вы написали его правильно, помедленнее!
Для фактического процесса отладки:
Напишите модульные тесты, если они еще не существуют.
Добавьте соответствующую регистрацию, если она еще не существует.
Затем используйте отладку.
Добавление модульных тестов и ведение журнала сначала более эффективно, чем сначала использование отладчика. Кроме того, вы получаете дополнительное преимущество в виде модульных тестов, которые помогают не вводить будущие ошибки, а ведение журнала поможет отлаживать сеансы в будущем.
Прежде чем перейти к небольшому фрагменту кода, посмотрите, сможете ли вы точно определить результат. Это, как правило, идет вразрез с тем, что вы ничего не предполагаете (за что я проголосовал, кстати, но, по мере того, как вы набираетесь опыта, это может помочь сузить область поиска)
Это может звучать тривиально, но изучите нюансы вашего отладчика и изучите горячие клавиши. Иногда отладчики могут быть достаточно медленными, чтобы ваш разум задавался вопросом, когда вы проходите через них. Если вы можете идти в ногу с машиной и не копаться, это может помочь.
Если вы можете изменить код во время отладки:
рассмотреть возможность утверждения до и после условия. Иногда вы можете перешагнуть, а не в код.
для операторов if со сложными выражениями подумайте над чем-то (некоторые могут нахмуриться, но это работает для меня)
нравится:
bool isLessThan5 = a < 5;
bool isGreaterThan10 = a > 10;
if ( isLessThan5 || isGreaterThan10 )
{
// more code here
}
вместо того:
if ( a < 5 || a > 10 )
{
// more code here
}
Для случаев, когда вы не можете отладить все, по какой-либо причине, научитесь «резиново-утиным» с коллегой. Иногда акт объяснения проливает свет. (хорошо, возможно это не совсем в теме вопросов, но я думаю, что это достаточно близко, чтобы оправдать упоминание)
Для именования подусловий требуется еще один шаг, а именно рефакторинг имен, когда вы узнаете, для чего это условие. Это может оказаться, if (tooCloseToHydrant || overTheBrink) { когда вы узнаете больше позже.
1
Две вещи, основанные на том, что большую часть последних 22 лет мы потратили на поддержку кода, написанного другими людьми.
Поймите, какие ошибки вы обычно пишете.
Например, я очень дотошный кодер, поэтому, как только мой код компилируется, он обычно не содержит тривиальных ошибок. Так что мои ошибки имеют тенденцию быть странными сложными вещами, такими как тупиковые блокировки. С другой стороны, у меня есть друг, который в основном пишет тривиальные ошибки - точки с запятой в конце C ++ для циклов, поэтому следующая строка выполняется только один раз, такого рода вещи.
Не думайте, что другие люди пишут такие же ошибки, как и вы.
Я не знаю, сколько раз я потратил впустую время на то, чтобы вытащить большие отладочные пистолеты, предполагая, что жук был моим видом очень тонкой странной вещи, только чтобы мой друг посмотрел через мое плечо и сказал: «Вы заметили это дополнительное точка с запятой?" После многих лет этого я сначала обращаюсь к банальным, низко висящим фруктам, когда смотрю на кодекс других людей.
Вы переформатируете код, чтобы увидеть, движется ли что-нибудь?
@ Thorbjørn: Если я стал владельцем кода, я иногда делаю это для улучшения читабельности, но не для того, чтобы найти опечатки. Интересная идея!
Боб Мерфи
Вы не должны совершать это, просто посмотрите, что происходит. Я настоятельно рекомендую применять политику, которая требует переформатирования кода - желательно автоматически - при регистрации.
@ Thorbjørn: я бы с удовольствием это сделал. Что вы рекомендуете в качестве кода "prettifier"? Я в основном работаю на Linux и Mac.
Боб Мерфи
Я использую Eclipse, доступный в обоих местах, и у редактора Java есть так называемое действие Сохранить, где вы можете указать, что должно происходить при каждом сохранении файла. Здесь одним из вариантов является форматирование источника. Мы небольшая команда, поэтому я не исследовал больше в этом. Более опытные команды допускают хуки перед фиксацией в системах управления исходным кодом, позволяя отклонить исходную фиксацию, если она неправильно отформатирована. Очень эффективный.
1
Знай свои инструменты. Например, в отладчике Visual Studio есть замечательная функция TracePoints, которая похожа на точки останова, но вместо того, чтобы останавливать код, вместо этого вставляет оператор трассировки в выходные данные отладки.
Чтение книг или посещение занятий по использованию вашего отладчика настоятельно рекомендуется. Я взял пару уроков и прочитал несколько книг Джона Роббинса, которые сильно повлияли на мою эффективность в качестве отладчика.
Функционально понять, что пытается сделать код. Если вы не знаете полную картину (все тестовые примеры, которые должен пройти этот код), трудно отладить должным образом без появления новых ошибок.
Написание автоматизированного модульного теста и других типов интеграционных и функциональных тестов.
Чем больше у вас автоматических тестов, тем меньше времени вам нужно проводить в отладчике.
Также хороший дизайн - ТВЕРДЫЕ принципы. Если вы пишете небольшие, специализированные классы и предпочитаете композицию наследованию, устранению дублирования и т. Д., Ваш код всегда будет легче отлаживать.
Я считаю, что хорошо разработанный код приводит к другому набору ошибок, который плохо разработан. Вообще говоря, хорошо разработанный код создает ошибки, которые легче найти, воспроизвести и исправить.
Исключением (и всегда есть один) является многопоточный код :-)
Если вы сузили область до небольшого региона, но все еще не можете обнаружить ошибку, попробуйте опцию «Просмотр кода + сборка» в вашем отладчике. Зная достаточно ASM, чтобы сказать «здесь должна быть ветвь» или «почему она только копирует низкое слово?» будет часто точно определять ошибку кодирования.
Слайды для книги доступны онлайн, но сама книга легче читать.
Книга поможет вам начать и заставит вас более научно думать об отладке, но она не заменит практики. Возможно, вам придется писать и отлаживать в течение 10 лет, прежде чем вы увидите, как улучшается ваша производительность на порядок. Я до сих пор помню, как у меня на челюсти в Sun было замечено, что старшие разработчики, которые программируют для Unix в течение 30 лет, находят неясные многопоточности или параллельные ошибки в считанные минуты. Опыт имеет значение!
Ответы:
Не принимайте ничего
Часто соблазнительно просто сказать «о, я знаю, что делает этот фрагмент кода, это нормально». Не делай этого. Проверьте каждое предположение и тщательно проработайте все.
источник
Тестирование пошагово .
Сначала углубляйтесь в свой код и тестируйте его, начиная с самого маленького модуля, постепенно повышающегося. Таким образом, вы не испытываете особого стресса, пытаясь выяснить, где именно может быть проблема.
Это также означает, что это влияет на меньшее количество кода за раз, так как вы перемещаетесь постепенно ... поскольку иногда у меня возникали проблемы, когда я что-то исправлял, и это приводило к поломке множества других вещей. Я отдаю должное моему боссу за это, поскольку он научил меня этому, когда я бездельничал.
источник
Разделяй и властвуй - это хороший подход. Попробуйте определить некоторые видимые входные данные (пользовательский ввод / сетевое событие ...) и выходные данные (журнал, выходные данные пользователя, исходящее сетевое сообщение ...), между которыми существует проблема. Попробуйте разместить отпечатки в значительных кусках или значимых точках между ними и попытаться сузить область ошибки в коде.
Разделяй и властвуй также может очень хорошо работать в случае регрессии над кодом, контролируемым версией Найдите две сборки - одна там, где она работает как положено, другая с регрессией. Сократите разрыв до тех пор, пока вы не останетесь с кучей проверок в качестве потенциальных подозреваемых.
источник
Вместо того, чтобы разбивать двоичные ошибки, пишите тесты в форме
Чтобы проверить, что вы на самом деле знаете, чтобы быть правдой о функционировании приложения в сравнении с тем, что вы считаете правдой.
Большинство IDE позволяют легко извлекать методы и создавать заглушки для тестирования xUnit. Используйте это.
Почему бы не посыпать отладками? Потому что после того, как вы закончите, вам, вероятно, придется отменить большую часть этой работы и удалить изрядное количество этих отладок. Когда вы пишете тесты, ваша отладка поможет в предотвращении и обнаружении будущих ошибок.
источник
Продолжайте отлаживать. Если вы будете много отлаживать, вы станете лучше.
источник
Как уже говорили другие - ничего не предполагайте. Это особенно верно, если его код вы написали. При отладке чужого кода вы, скорее всего, будете тормозить, потому что код для вас новый или вы не доверяете кодеру. При отладке собственного кода слишком легко предположить, что вы написали его правильно, помедленнее!
Для фактического процесса отладки:
Добавление модульных тестов и ведение журнала сначала более эффективно, чем сначала использование отладчика. Кроме того, вы получаете дополнительное преимущество в виде модульных тестов, которые помогают не вводить будущие ошибки, а ведение журнала поможет отлаживать сеансы в будущем.
источник
Прежде чем перейти к небольшому фрагменту кода, посмотрите, сможете ли вы точно определить результат. Это, как правило, идет вразрез с тем, что вы ничего не предполагаете (за что я проголосовал, кстати, но, по мере того, как вы набираетесь опыта, это может помочь сузить область поиска)
Это может звучать тривиально, но изучите нюансы вашего отладчика и изучите горячие клавиши. Иногда отладчики могут быть достаточно медленными, чтобы ваш разум задавался вопросом, когда вы проходите через них. Если вы можете идти в ногу с машиной и не копаться, это может помочь.
Если вы можете изменить код во время отладки:
нравится:
вместо того:
Для случаев, когда вы не можете отладить все, по какой-либо причине, научитесь «резиново-утиным» с коллегой. Иногда акт объяснения проливает свет. (хорошо, возможно это не совсем в теме вопросов, но я думаю, что это достаточно близко, чтобы оправдать упоминание)
источник
if (tooCloseToHydrant || overTheBrink) {когда вы узнаете больше позже.Две вещи, основанные на том, что большую часть последних 22 лет мы потратили на поддержку кода, написанного другими людьми.
Поймите, какие ошибки вы обычно пишете.
Например, я очень дотошный кодер, поэтому, как только мой код компилируется, он обычно не содержит тривиальных ошибок. Так что мои ошибки имеют тенденцию быть странными сложными вещами, такими как тупиковые блокировки. С другой стороны, у меня есть друг, который в основном пишет тривиальные ошибки - точки с запятой в конце C ++ для циклов, поэтому следующая строка выполняется только один раз, такого рода вещи.
Не думайте, что другие люди пишут такие же ошибки, как и вы.
Я не знаю, сколько раз я потратил впустую время на то, чтобы вытащить большие отладочные пистолеты, предполагая, что жук был моим видом очень тонкой странной вещи, только чтобы мой друг посмотрел через мое плечо и сказал: «Вы заметили это дополнительное точка с запятой?" После многих лет этого я сначала обращаюсь к банальным, низко висящим фруктам, когда смотрю на кодекс других людей.
источник
Знай свои инструменты. Например, в отладчике Visual Studio есть замечательная функция TracePoints, которая похожа на точки останова, но вместо того, чтобы останавливать код, вместо этого вставляет оператор трассировки в выходные данные отладки.
Чтение книг или посещение занятий по использованию вашего отладчика настоятельно рекомендуется. Я взял пару уроков и прочитал несколько книг Джона Роббинса, которые сильно повлияли на мою эффективность в качестве отладчика.
источник
Функционально понять, что пытается сделать код. Если вы не знаете полную картину (все тестовые примеры, которые должен пройти этот код), трудно отладить должным образом без появления новых ошибок.
источник
Написание автоматизированного модульного теста и других типов интеграционных и функциональных тестов.
Чем больше у вас автоматических тестов, тем меньше времени вам нужно проводить в отладчике.
Также хороший дизайн - ТВЕРДЫЕ принципы. Если вы пишете небольшие, специализированные классы и предпочитаете композицию наследованию, устранению дублирования и т. Д., Ваш код всегда будет легче отлаживать.
Я считаю, что хорошо разработанный код приводит к другому набору ошибок, который плохо разработан. Вообще говоря, хорошо разработанный код создает ошибки, которые легче найти, воспроизвести и исправить.
Исключением (и всегда есть один) является многопоточный код :-)
источник
Если вы сузили область до небольшого региона, но все еще не можете обнаружить ошибку, попробуйте опцию «Просмотр кода + сборка» в вашем отладчике. Зная достаточно ASM, чтобы сказать «здесь должна быть ветвь» или «почему она только копирует низкое слово?» будет часто точно определять ошибку кодирования.
источник
Ознакомьтесь с очень ценной книгой Андреаса Зеллера « Почему не работают программы: руководство по систематической отладке ». Он познакомит вас со многими методами, теориями и инструментами, некоторые из которых находятся на переднем крае исследований.
Слайды для книги доступны онлайн, но сама книга легче читать.
Книга поможет вам начать и заставит вас более научно думать об отладке, но она не заменит практики. Возможно, вам придется писать и отлаживать в течение 10 лет, прежде чем вы увидите, как улучшается ваша производительность на порядок. Я до сих пор помню, как у меня на челюсти в Sun было замечено, что старшие разработчики, которые программируют для Unix в течение 30 лет, находят неясные многопоточности или параллельные ошибки в считанные минуты. Опыт имеет значение!
источник