Что помогает Вам улучшить Вашу способность найти ошибку?

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

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

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

Например, если Вы ожидаете непустой список:

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

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

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

Так, как Вы сказали, чем лучше архитектура, тем легче найти ошибки.

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

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

Во-вторых: исследуйте данные, переданные через интерфейсы между компонентами. Продолжать предыдущий пример выше:

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

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

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

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

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

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

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

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

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

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

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

Статические инструменты кода как FindBugs

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

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

• Где ошибки вероятны, имеют модульные тесты.

Очевидно.
По моему скромному мнению, лучшими модульными тестами является Монте-Карло.

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

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

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

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

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

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

Знайте свои инструменты.

Удостоверьтесь, что Вы знаете, как использовать условные точки останова и часы в Вашем отладчике.

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

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

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

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

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

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

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

Опыт делает Вас лучшим отладчиком. Обратите пристальное внимание на ошибки, которые Вы И другие обычно делаете. Попытайтесь выяснить, относятся ли эти ошибки ко ВСЕМУ коду, который влияет на Вас, не единственный экземпляр того, где ошибка была замечена.

Raymond Chen известен своими полномочиями экстрасенс отладка.

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

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

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

Управляемый дизайн теста является довольно большим перемещением в программировании прямо сейчас. Вам будет трудно находить язык, который не поддерживает некоторое тестирование. Даже JavaScript имеет множество наборов тестов.

Вот профилактический метод после нахождения ошибки: Я нахожу действительно полезным занять минуту и думать об ошибке.

1. Какова была ошибка точно в сущности.
2. Почему это происходило.
3. Вы, возможно, нашли это более ранним, легче.
4. Что-либо еще Вы извлекли уроки из ошибки.

Я нахожу, что взятие минуты для размышления об этих вещах сделает его намного менее вероятно, что Вы произведете ту же ошибку в будущем.

Сон и отдых.

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