Что помогает вам улучшить вашу способность находить ошибку?

Question

Я хочу знать, есть ли способ быстрого поиска ошибок в программе.

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

Как программисты улучшают свою способность находить ошибки?

Answer 1

Утверждения, утверждения и утверждения.

В некоторых областях нашего кода есть 4 или 5 утверждений для каждой строки реального кода. Когда мы получаем сообщение об ошибке, первое, что происходит, - это то, что данные клиента обрабатываются в нашей отладочной сборке 99 раз из ста, и утверждение срабатывает вблизи причины ошибки.

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

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

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

Answer 2

Инструменты статического кода, такие как FindBugs

Answer 3

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

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

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

Answer 4

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

Если для реализации одного отдельного функционального требования требуется N отдельных точек редактирования исходного кода, количество ошибок, внесенных в код, примерно пропорционально N, поэтому найдите методы программирования, которые сводят к минимуму N. : СУХОЙ (не повторяйте себя), генерация кода и DSL (предметно-ориентированный язык).

• Если возможны ошибки, проведите юнит-тесты.

Очевидно.
ИМХО, лучшие юнит-тесты - это Монте-Карло.

• Сделать промежуточные результаты видимыми.

Например, компиляторы имеют промежуточные представления в форме 4-х кортежей. Если есть ошибка, можно проверить промежуточный код. Это говорит о том, есть ли ошибка в первой или второй половине компилятора.

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

Answer 5

Научная отладка - это то, что я всегда использовал, и это очень помогает.

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

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

Существуют автоматизированные инструменты, которые могут помочь вам в этом процессе, в частности git-bisect (и аналогичные инструменты bisection в других системах ревизий), чтобы быстро найти, какие изменения привели к ошибке, модульное тестирование для воспроизведения ошибки и предотвращения регрессий в вашем коде (может использоваться в сочетании с bisect) и дельта-отладка для поиска виновника в вашем коде (аналогично git-bisect но в то время как git-bisect работает с историей кода, дельта-отладка работает непосредственно с кодом).

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

Answer 6

Я являюсь частью команды QA team @ work и, зная все о продукте и его разработке, много помогает находить ошибки, также когда я делаю новые инструменты QA, я передаю его наша команда разработчиков, чтобы проверить это, найти ошибки в вашем собственном коде просто hard !

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

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

Answer 7

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

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

например. если вы ожидаете непустой список:

l = getList(input)
assert l, "List was empty for input: %s" % str(input)

Answer 8

Запись Debug.Write (сообщения) в вашем коде и использование DebugView - еще один вариант. А затем запустите приложение и узнайте, что происходит.

Answer 9

Пошаговое выполнение кода, проверка потока / состояния, в котором происходит непредвиденное поведение. (Затем, конечно, разработайте для него тест).

Answer 10

«Архитектура» в программном обеспечении означает что-то вроде:

• Несколько компонентов
• Компоненты взаимодействуют через четко определенные интерфейсы
• Каждый компонент несет четко определенную ответственность
• Ответственность одного компонента отличается от ответственности других компонентов

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

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

1. В компоненте, который отвечает за ведение журнала (ваша библиотека журналов)
2. Или выше, чем в коде приложения, использующего эту библиотеку
3. Или ниже, чем в системном коде, который использует эта библиотека

Второе: проверить данные, передаваемые по интерфейсам между компонентами. Чтобы продолжить предыдущий пример выше:

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