День 1420. #Debugging
Я Исправил Ошибку. Что Дальше?
Чем больше кода вы пишете, тем больше ошибок создаёте. Т.е. как разработчик ПО вы должны тратить часть своего времени на отладку.

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

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

1. Легко ли было получить информацию, необходимую для воспроизведения ошибки?
- Какую версию приложения запускает пользователь?
- Какова конфигурация среды? (ОС, версия .NET, текущая культура, разрешение экрана, ОЗУ, загрузка ЦП и т. д.)
- Какая конфигурация приложения? (Пользовательские настройки)
- В случае сбоя доступен ли стек вызовов и понятно ли сообщение об ошибке?
- Есть ли доступ к логам? Легко ли их получить и прочитать? Предоставляют ли они достаточно информации и контекста?
- Есть ли доступ к данным телеметрии?
На этом этапе у вас должно быть хорошее представление о проблеме, не глядя на код.

2. Легко ли воспроизвести проблему в среде разработки?
- Легко ли начать работу над проектом? (Получить код/Открыть проект в IDE/Начать отладку)
- Правильно ли задокументирован процесс?
- Нужно ли вручную настраивать секреты для подключения к внешним службам?
- Требуется ли дополнительное ПО на машине и как его получить?
- Легко ли настроить ту же среду, что и в рабочей среде (Azure Web App, Docker, Kubernetes)? Легко ли отлаживать эту среду?
- Можно ли получить анонимизированные живые данные, когда это необходимо?
- Если нельзя воспроизвести проблему в своей среде, можно ли вы отладить промежуточную/производственную версию или получить дамп? Будьте очень осторожны, когда делаете это, чтобы не заблокировать работающий сервис из-за достижения точки останова и не раскрыть важные данные.

3. Легко ли работать над кодовой базой?
- Хорошо ли организован код? Находите ли вы то, что ищете?
- Код легко читается? Соблюдается ли соглашение об именовании и стиль написания кода?
- Есть ли в коде неявные зависимости?
- Насколько быстро вы можете вносить изменения и наблюдать за их результатами в приложении?
- Можете ли вы воспользоваться своей IDE для отладки?
- Можете ли использовать точки останова и просматривать локальные значения или вычислять выражения?
- Ваши типы переопределяют ToString или отмечены атрибутом [DebuggerDisplay], чтобы вы могли быстро увидеть значения во время отладки?

4. Почему разработчик внёс эту ошибку в код?
На этом этапе вы должны найти причины, по которым разработчик допустил ошибку. Сделайте шаг назад и проанализируйте проблему.
- Код слишком сложный?
- Методы слишком длинные и слишком сложные?
- Используете ли вы правильный инструмент для выполнения работы?
- Возможна ли путаница? Например, два типа с одинаковым именем в разных пространствах имен.
- Ясно ли объясняются пред- и пост-условия метода (возможно ли передать/вернуть null, дату локальную/UTC, относительный/абсолютный путь?
- Отсутствует или неясна документация/комментарии?
- Влияет ли изменение части приложения на другую часть?
- Надёжны ли тесты?
- Есть ли хотя бы один сквозной тест для основного сценария приложения?

Источник: https://www.meziantou.net/how-to-correctly-fix-a-bug.htm

День 1667. #ЗаметкиНаПолях #Debugging
Отладка с Разных Точек Зрения
Отладка — это процесс выявления основной причины ошибки и её исправления.

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

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

Прежде чем приступить к отладке, важно принять соответствующий образ мышления. Это влечёт за собой отказ от защиты своего эго, игнорирование любого давления проекта и обеспечение личного комфорта. Помните первое правило отладки: НЕ ПАНИКУЙТЕ.

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

Правильное отношение
При правильном отношении отладка может быть весёлой, как решение головоломки. Вот некоторые ключевые аспекты правильного отношения к эффективной отладке:
- Любознательность: будьте готовы исследовать и понять основную причину проблемы.
- Терпение: отладка может занять много времени. Будьте терпеливы и настойчивы.
- Открытость к обучению: рассматривайте отладку как возможность учиться и улучшать свои навыки.
- Смирение: признайте, что все совершают ошибки. Отладка — это поиск и исправление этих ошибок, а не отражение вашей ценности или интеллекта.
- Системный подход: используйте системный подход для выявления и изоляции проблемы. Избегайте поспешных предположений и тщательно исследуйте код или систему.
- Сотрудничество: не стесняйтесь обращаться за помощью.
- Внимание к деталям: обратите внимание на мельчайшие детали, поскольку они часто могут содержать ключ к разгадке источника проблемы.
- Оптимизм: вера в свою способность успешно решить проблему может помочь сохранить концентрацию и мотивацию.
- Документация: отслеживайте процесс отладки, предпринятые шаги и решения. Эта документация может оказаться полезной для будущих справок и обучения.

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

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

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

Источник: https://dev.to/rajasegar/debugging-from-different-viewpoints-46k0

День 1679. #ЗаметкиНаПолях #Debugging
Правила Отладки: Понимание Системы
Решение проблем без подлинного их понимания может создать ненужные трудности и поставить под угрозу качество программы. Поэтому крайне важно тщательно понять систему, прежде чем пытаться её исправить. Чтобы добиться этого, триангулируйте дефект, протестировав сценарии, которые должны воспроизводить ошибку, и те, которые не должны воспроизводить её. Продолжайте этот процесс до тех пор, пока не поймете проблему достаточно хорошо, чтобы точно предсказать её возникновение в каждом случае.

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

2. Знайте, что разумно
При изучении системы крайне важно иметь чёткое представление о её типичном функционировании. Понимание стандартных операций позволяет эффективно выявлять отклонения или аномалии. Многим сложно выявить проблемы просто потому, что им не хватает фундаментального понимания того, как должна работать система.

3. Знайте дорожную карту
Важно знать структуру системы. Когда определённые части системы считаются «черными ящиками», понимание того, как они должны взаимодействовать с другими компонентами, помогает определить, находится ли проблема внутри ящика или за его пределами.

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

5. Изучайте подробности
Избегайте предположений. Потратьте время на исследование и получение точной информации. Подробные детали были задокументированы либо вами, либо создателем библиотеки, API или платформы. Неразумно полагаться исключительно на свою память.
Предположения могут вывести вас на ложный путь, где неверная информация может показаться верной, и вы упустите из виду важные проблемы. Вы можете столкнуться с запутанными данными или, что еще хуже, с ложно обнадёживающими данными.
Берите пример с Эйнштейна, который никогда не трудился запоминать свой номер телефона. Он знал, что его всегда можно найти в телефонной книге.

Источник: https://dev.to/rajasegar/debugging-rules-understand-the-system-ho5

День 1710. #ЗаметкиНаПолях #Debugging
Правила Отладки: Заставь Его Упасть. Начало
В своей книге «Совершенный Код» Стив МакКоннелл предлагает научный метод отладки. Он состоит из следующих шагов:
- Стабилизировать ошибку
- Найти источник ошибки
- Исправить дефект
- Проверить исправление
- Найти похожие ошибки

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

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

Просто сделай это «снова»
Воспроизвести ошибку один раз недостаточно. Задокументируйте действия, приводящие к ошибке, и убедитесь, что она возникает при каждом повторении. Однако в определённых сценариях возникновение ошибки может привести к причинению вреда или нежелательным последствиям. В таких случаях необходимо внести коррективы, чтобы свести к минимуму степень потенциального ущерба, стремясь при этом максимально сохранить суть исходной системы и последовательность действий.

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

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

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

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

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

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

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

Окончание следует…

Источник: https://dev.to/rajasegar/debugging-rules-make-it-fail-33c0

День 1711. #ЗаметкиНаПолях #Debugging
Правила Отладки: Заставь Его Упасть. Окончание
Начало

Неконтролируемое состояние
Задача «дать ему упасть» становится значительно сложнее, когда сбой происходит периодически. Хотя вы можете точно понять, какие шаги привели к первоначальной неудаче, последовательное её воспроизведение остаётся невозможным – возможно, это происходит только раз из 5, 10 или 100 попыток.

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

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

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

Несомненно, случайность усложняет процесс подтверждения исправления. Например, если тест показывает процент неудач в 10%, а ваше вмешательство снижает его до 3% — но вы прекращаете тестирование после 28 попыток — вы можете поверить, что проблема решена, даже если это не так.

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

Черные лебеди
Легко просто игнорировать предупреждающие знаки и аргументы других людей (клиентов или тестировщиков), которые настаивают на существовании ошибок.

Знайте, что «это» может случиться

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

Итого
Если вы понятия не имеете, что может быть не так, жизнь становится сложнее! Начните с того, что убедитесь, что вы можете обеспечить постоянное проявление ошибки. Потратьте время на подготовку входных данных и настройку параметров, которые последовательно вызывают проблему. Затем упакуйте эти шаги в упрощённую процедуру, которая облегчает лёгкое и автоматизированное выполнение. Когда вы имеете дело со сложной ошибкой, вы обнаружите, что неоднократно воспроизводите её по мере выяснения основной причины. Таким образом, оптимизация процесса воспроизведения в итоге сэкономит вам время. Столкнувшись с ошибкой, которая возникает случайно, приложите усилия к пониманию причин её случайного характера.

Источник: https://dev.to/rajasegar/debugging-rules-make-it-fail-33c0

День 1722. #ЗаметкиНаПолях #Debugging
Правила Отладки: Ведите Журнал Аудита
Отладка - сложная задача, часто занимающая много времени. Поэтому наша цель - минимизация времени отладки. Каждая ошибка даёт возможность освоить методы предотвращения аналогичных проблем в будущем или быстрого их выявления, если они возникнут снова.

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

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

Ведение журнала аудита во время отладки даёт несколько преимуществ:
1) Комплексное отслеживание.
Журнал фиксирует действия по расследованию, позволяя вам перепроверять ваши действия и решения.

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

3) Точное воспроизведение.
Следуя описанным шагам, вы увеличиваете вероятность точного воспроизведения проблемы, что приводит к более эффективному устранению неполадок.

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

5) Целостное понимание.
Маршрут воспроизведения ошибки фиксирует не только действия, но и контекст и состояние системы. Это полезно для понимания более широкой картины проблемы.

6) Обучение и совершенствование.
Анализ прошлых записей журнала позволяет учиться на предыдущем опыте и может помочь избежать подобных ошибок в будущем.

7) Адаптируемое решение проблем.
Благодаря журналу аудита вы можете переключаться между различными подходами, не теряя при этом прогресса. Если один из способов окажется неудачным, вы можете повторить свои шаги и поискать альтернативные решения.

8) Эффективная документация.
Журнал служит документацией усилий по отладке. Его можно использовать в дальнейшем для обучения новых членов команды и создания базы знаний.

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

10) Аналитика на основе данных.
Записывая наблюдения, гипотезы и результаты, вы собираете данные, которые могут дать представление о повторяющихся проблемах, закономерностях и потенциальных улучшениях процесса разработки.

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

Источник: https://dev.to/rajasegar/debugging-rules-keep-an-audit-trail-3he9

День 1738. #ЗаметкиНаПолях #Debugging
Правила Отладки: Хватит Думать, Наблюдайте
Очень важно наблюдать за неудачей. Когда вы делаете предположения о причине проблемы, вы часто в итоге пытаетесь исправить что-то, не связанное с реальной ошибкой. Это не только приводит к неэффективному решению, но также отнимает драгоценное время и ресурсы.

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

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

1. Посмотрите на сбой
Очевидно, что, чтобы идентифицировать сбой, необходимо посмотреть, как сбой произошёл. Отчёт об ошибке – это последствия сбоя. Для эффективной отладки необходимо изучить сбой в деталях. Иначе вы можете решить предполагаемую проблему, тогда как неисправность будет в другом месте. В большинстве случаев наблюдение занимает меньше времени, чем разбор поспешных догадок, которые часто приводят в тупик.

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

3. Создайте инструментарий
Обычно по умолчанию можно запустить код в режиме отладки, что позволяет наблюдать за выполнением программы. Также помогает трассировка. Важно иметь механизм, который позволит выборочно включать или отключать определённые сообщения или типы сообщений. Это позволит сосредоточить внимание на сообщениях, имеющих отношение к конкретной проблеме. Учитывайте вопросы отладки с начала процесса проектирования. Убедитесь, что инструментарий трассировки и отладки являются одним из требований к вашему продукту.

4. Остерегайтесь Гейзенбагов
Гейзенберг - один из первопроходцев в квантовой физике. Он осознал, что само наблюдение за элементарными частицами влияет на их поведение. Гейзенбаг — это сбой, который реагирует на действие наблюдения. Например, исчезает в режиме отладки. Даже отладчик может влиять на поведение системы. Это неизбежная реальность, и очень важно помнить об этом, чтобы такие последствия не застали вас врасплох. Поэтому после внедрения инструментов отладки в неисправную систему важно воссоздать ошибку и убедиться, что ваши действия не повлияли на сбой.

5. Гадайте только, чтобы сузить поиск
Угадывание может быть ценным инструментом, но важно использовать догадки как средство сузить область поиска. Вы всё равно должны подтверждать свои предположения, воспроизводя сбой, прежде чем пытаться его исправить.

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

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

Источник: https://dev.to/rajasegar/debugging-rules-quit-thinking-and-look-3ang

День 1764. #ЗаметкиНаПолях #Debugging
Правила отладки: Меняйте За Раз Что-то Одно
Изменение нескольких элементов создаёт ряд проблем. Возникает вероятность мелких ошибок, очень похожих на первоначальную проблему. Т.е. вы не уверены, была ли исправлена проблема или не привело ли исправление случайно к аналогичной проблеме. Чтобы справиться с этой сложностью, вносите только одно изменение за раз.

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

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

Изолируйте ключевой фактор
Суть эффективной отладки в выявлении критического фактора путем сужения фокуса до определённого раздела кода, в котором может возникнуть потенциальная проблема. Так процесс отладки становится более точным и эффективным. Чтобы сделать это систематически исключайте части программы и наблюдайте, сохраняется ли ошибка. Нет ли при этом знакомой закономерности? Признание того, что «я это видел раньше», часто означает начало понимания, если не полное решение.

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

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

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

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

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

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

Источник: https://dev.to/rajasegar/debugging-rules-change-one-thing-at-a-time-3kc6