Есть ли отладочные шаблоны?

Ответ 1

Я добавлю еще один шаблон отладки, который кажется довольно очевидным, но еще не был указан:

Уменьшите ошибку до наименьшего возможного случая, а затем используйте это как ваш unit test для любого предлагаемого исправления.

Ответ 2

Вот некоторые из них, которые работают для меня:

• Отойдите от проблемы. Подобно "больше сна", иногда отступая от проблемы и фокусируясь на чем-то совершенно другом (например, выходите на работу), помогает обеспечить ясность при возобновлении работы над проблемой.
• Объясните проблему моей жене. Ну, это не обязательно должна быть моя жена, но кто-то, кто не знаком с проблемой, системой или чем-то еще. Это заставит вас принести предположения на поверхность, объяснить, как работает система, возможно, даже вернитесь к коду, чтобы проверить, что вы говорите. У меня часто были значительные прорывы после такого обмена.

Ответ 3

Я согласен с другими в отношении Unit Testing как "Pattern" для предотвращения ошибок. Кроме того, я хотел бы привести следующие шаги из Отладка: 9 незаменимых правил поиска даже самых исключительных проблем программного и аппаратного обеспечения:

• Понимание системы
• Устранить ошибку.
• Закройте мышление и посмотрите
• Разделить и покорить
• Измените одну вещь за раз
• Сохранять контрольный журнал
• Проверьте разъем
• Получить свежий вид
• Если вы его не исправили, он не исправлен.

И последнее, на более практичной стороне, Дмитрий Востоков собрал несколько очень приятных отладочных шаблонов в своей книге и веб-сайт.

Ответ 4

Когда я просто снимаю в темной отладке, я беру подход двоичного поиска. Я прокомментирую половину моего кода или половину метода, что-то вроде этих строк, затем я сосредоточусь на недокументированной половине. Если проблема все еще существует, я прокомментирую другую половину. И так далее.

Ответ 5

Мой подход заключается в использовании научного метода:

• Соберите данные о том, что происходит, попробуйте множество разных входов и посмотрите, какие результаты я получаю.
• Разработайте гипотезу о том, что происходит
• Протестируйте указанную гипотезу, и я не прав, затем вернитесь к шагу 1 и повторите.

Ответ 6

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

git bisect - эффектный инструмент для этой цели. Но вы могли бы теоретически сделать то же самое с кучей tarballs, если это все, что у вас есть.

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

Ответ 7

Мне нравится думать, что Unit Testing - это шаблон отладки. Если вы можете воспроизвести проблему, вы можете написать unit test, чтобы сделать ее намного легче отлаживать.

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

Ответ 8

Отказоустойчивость - одна. Проблема возникает во всех ОС или связана только с одной ОС?

Продолжайте дихотомию, чтобы определить местоположение и причину проблемы.

Ответ 9

Я отлаживаю способ решения проблем. Я использую метод cartesian.

Существует 4 правила:

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

Или, скажем иначе:

• Признать истинным только то, что является несомненным.
• Разделите каждый вопрос на управляемые части.
• Начните с самых простых проблем и перейдите к более сложным.
• Просмотрите достаточно часто, чтобы сразу сохранить весь аргумент.

Вам нужно только адаптировать эти правила в контексте программирования.

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

Ответ 10

Существует несколько формальных шаблонов для устранения определенных ошибок:

• Устранить шаблон шума
• Повторяющийся шаблон ошибки
• Временной характерный шаблон ошибки

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

Ответ 11

Только некоторые из них я встретил:

• Когда две идентичные системы генерируя разные результаты, проверьте что (в порядке вероятности):
  • Версии всех компонентов в факт, идентичный между двумя систем,
  • Конфигурация идентична между двумя системами и
  • Существует нет остаточных данных в одной системе, не было на другом.
• gdb и gcs parse лучше, чем я. Позволять программное обеспечение выполняет свою работу, чтобы вы могли ваш.
• Когда данные выводятся на один конец процесса, отличный от ожидаемого, проверяйте данные по всему процессу, чтобы убедиться, что он как ожидалось, вместо того, чтобы сосредоточиться на функции в потоке процесса из реальной проблемы.
• Не сосредотачивайтесь на определенной части кода, если вы не подтвердили, что это является причиной ошибки.
• Получите больше сна. Отладка оповещений всегда более эффективна.

У меня есть больше на моем веб-сайте в разделе "Разработка ПО → " Отладка ", если вам интересно.

Ответ 12

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

Вы не можете начать осмысленную отладку до тех пор, пока ошибка не будет воспроизводимой, с поэтапным рецептом. Если вы получите плохой отчет об ошибках, вы можете столкнуться с необходимостью распознать этот рецепт самостоятельно, но если вы поддерживаете кого-то, вы должны сообщить им, что вы выясните, что рецепт займет больше времени, чем они делают это за вас, и могут даже быть невозможно. Полезный отчет об ошибке должен ответить на три вопроса о том, что я называю формулой отчета об ошибке: 1) что вы сделали? 2) что вы ожидали? 3) что произошло вместо этого?

Конечно, некоторые ошибки - Heisenbugs, по-видимому, временные. Вы все равно должны попытаться получить что-то похожее на инструкцию типа "Если я сделаю следующее, это выглядит примерно в 10% случаев, когда это нежелательный результат".

После того, как у вас есть рецепт, следующий шаг часто кипит до минимального тестового примера, как отмечали другие.

Ответ 13

Другие (Xynth, Broam, Moshe) упомянули о необходимости получить минимальный тестовый пример, надеюсь, тот, который можно вставить в ваш пакет unit test. Согласен. Как только вы сможете сделать ошибку, начните отбирать лишние факторы или даже код (как предложил Боб), проверяя каждый шаг, чтобы узнать, исчезла ли ошибка. Если он в cron, запустите его вручную. Если он запускается из графического интерфейса пользователя, попробуйте его из командной строки или простого набора тестов.

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

Ответ 14

Специализируется на отладке шейдера OpenGL, что очень непрозрачно. Dumbing stuff down хорош и необходим, но проверка вывода сложнее обычного программирования приложений, поэтому вам нужны некоторые трюки:

• Отметьте разные части в r, g, b, используя шаг(), если вам нужно проверить точные изменения значений. (Хорошо для обнаружения ошибок с плавающей запятой, таких как 1.001 или -0.001)
• Научитесь интерпретировать rgb как нормализованный вектор xyz.
• Удалите образцы текстур, постройте координаты текстуры как цвета.
• Рассмотрите возможность визуализации различных переменных в разных частях экрана и наличие свободно плавающей камеры.

Ответ 15

Спасибо за все идеи. Они были действительно полезны. Насколько я понимаю, нет определенного списка шаблонов, таких как Design Patterns, когда дело доходит до исправления ошибок. Возможно, после некоторого момента у каждого свой путь.

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

Одна из моих любимых вещей заключается в том, что если значение свойства изменяется неожиданным образом, я ставлю точку прерывания на настройщик этого свойства. Я не знаю, возможно ли это сделать с неявными замедлениями свойств (bool myProperty {get; set;}).

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

спасибо, burak ozdogan

Ответ 16

Дмитрий Востоков каталогизирует многие шаблоны отладки http://www.dumpanalysis.org/

Он пишет о многих из них в своем блоге http://www.dumpanalysis.org/blog/

В основном, имея дело с отладкой на платформах Windows, он начал вести блог о gdb в Mac OS.