Там кто-либо отлаживает Шаблоны? [закрытый]

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

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

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

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

спасибо, Бурак Оздоган

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

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

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

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

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

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

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

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

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

Способ отладки - это способ решения проблем. Я использую декартов метод.

Есть 4 правила :

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

Или, скажем, по-другому :

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

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

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

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

• Устранить шаблон шума
• Повторяющийся шаблон ошибки
• Шаблон ошибки, зависящий от времени

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

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

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

Конечно, некоторые ошибки - это Heisenbugs, очевидно временные. Вы все равно должны попытаться получить что-то похожее на утверждение вроде "

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

Вот несколько из них, которые мне подходят:

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

Я встретил лишь несколько:

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

У меня есть больше на моем веб-сайте в разделе Разработка программного обеспечения -> Отладка, если вам интересно.

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

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

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

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

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

• Понять систему
• Сделать ошибку
• Хватит думать и посмотрите
• Разделяй и властвуй
• Изменяй по одному
• Вести журнал аудита
• Проверить плагин
• Получи свежий взгляд
• Если ты не исправил это, это не так Не исправлено

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

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

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