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

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

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

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

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

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

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

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

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

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

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

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

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