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

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

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

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

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

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

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

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

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

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

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