Этап исправления ошибки

Обновлено: 06.07.2024

Есть несколько основных инженерных приемов, которые я хочу осветить в серии постов, начиная с самого важного: как исправить ошибку?

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

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

Обнаружение ошибки

Прежде чем вы сможете что-то исправить, вам нужно определить неправильное поведение.
И это может быть сложно. Рассмотрим эти два случая:

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

Кого из них будет легче обнаружить? Я думаю, вы правильно догадались: первый.
Некоторые ошибки более заметны, чем другие.

Существует несколько факторов, влияющих на возможность обнаружения ошибки:

Сколько пользователей пострадало от этой ошибки? Если число будет достаточно большим, кто-нибудь обязательно об этом расскажет. Разумно ли использовать ваших пользователей в качестве службы мониторинга? Это еще один вопрос, который мы не будем обсуждать в этой статье.
Где выполняется код? На вашем сервере гораздо проще создать службу мониторинга, которая будет ловить большинство непредвиденных вещей и предупреждать вас об этом. Иногда у вас нет доступа к продукту, который вы создали. Например, при отправке корпоративным клиентам, использующим собственную инфраструктуру. Кроме того, намного проще создать фиксированную среду на собственных серверах, чтобы никакие сторонние организации не вмешивались в ваш проект.
Насколько сложно воспроизвести? Некоторые ошибки легко воспроизвести. Нажмите на эту ссылку, введите этот текст, нажмите Enter. Некоторые ошибки безумны! Вам нужно настроить специальную среду, установить какое-то определенное программное обеспечение, выполнить странные действия, и тогда вы воспроизведете ошибку (если вам повезет). Важно отметить, что некоторые ошибки вообще не воспроизводятся. Их можно просто игнорировать.

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

Sentry помогает отслеживать ошибки в коде. Он поддерживает практически любой язык, и есть бесплатная самостоятельная версия. Это также позволяет собирать прямые устные отзывы от ваших пользователей.
Prometheus – один из самых популярных инструментов мониторинга. Он доступен через docker-compose для быстрого старта.
Есть также платные сервисы, такие как NewRelic , Wombat , DataDog и многие другие.

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

Сообщить об ошибке

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

Почему вы думаете, что это ошибка? Возможно, это особенность.
Что, по вашему мнению, должно произойти? Ошибки без четко определенного ожидаемого поведения может стать очень трудно исправить. И они могут вырасти до запросов функций. Который следует решать по-другому.
Почему эта ошибка важна? Вы должны доказать, что это должно быть исправлено прямо сейчас. Так как некоторые баги пустяковые и их можно пока игнорировать.
Как воспроизвести проблему? Он должен содержать всю техническую информацию о проблеме. Какие версии использовались? Какой браузер/ОС используется? Какая конфигурация применяется? Иногда даже можно создать отдельный репозиторий только для того, чтобы показать репродукцию задачи.
Где искать дополнительную информацию о том, что происходит: журналы, трассировки стека, снимки экрана, отчеты о мониторинге, необходимые входные данные, связанные ошибки и функции и т. д. Все ссылки должны присутствовать в заявке. В противном случае решить эту проблему со временем будет очень сложно.

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

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

< /p>

О втором сообщил я. Это плохой пример отчета об ошибке.

< /p>

Это нарушает почти все правила, которые мы определили ранее. Это было сделано в спешке - чтобы не забыть об этом билете после разговора по мобильному с одним из моих пользователей. Не делайте этого.

Вот несколько реальных шаблонов отчетов об ошибках, которые вы можете использовать в своих проектах:

Также в репозитории github-issue-templates есть коллекция различных шаблонов ошибок. Не стесняйтесь использовать любой из них, чтобы сделать процесс разработки лучше!

Воспроизведение ошибки

Теперь вам нужно воспроизвести эту ошибку. И не только своей рукой, но и своим кодом. Помните — ваша цель — не допустить повторения той же ошибки. Как это возможно?

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

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

Какие инструменты помогают вам воспроизводить сложные ошибки? Ну, есть пара из них:

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

Помните, что некоторые ошибки невозможно воспроизвести за разумное время.

Вы можете ознакомиться с некоторыми регрессионными тестами, которые я создал для wemake-python-styleguide. Вот краткий обзор тестовой структуры, которая нам подходит:

Исправить ошибку

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

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

После того, как вы исправили свой код и отправили свой код, сборка CI должна пройти успешно. Если да, то ошибка исправлена. Но есть еще кое-что, что нужно сделать.

Да, есть еще одна вещь, которую большинство разработчиков обычно не делают: написание постмортема. Некоторые ошибки действительно просты и не требуют этого шага, но некоторые ошибки стоят нам много времени и денег. Мы должны проявлять особую заботу о них. Postmortem — это нетехническая история о том, что произошло, которую вы можете показать своему руководству (и которую они поймут). Что должно быть включено в вскрытие?

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

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

Послесловие

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

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

В конце всех этих шагов наступает этап, когда вы рвете на себе волосы и все еще не ушли домой. Тогда вы поймете одну из двух вещей:

вы забыли важную информацию об ошибке, например что это было или
вы можете поручить это кому-то, кто знает больше вас.

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

Что делал пользователь
Чего они ожидали
Что произошло вместо этого

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

Шаг 2. Погуглите сообщение об ошибке

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

Шаг 3. Определите строку кода, непосредственно связанную с ошибкой

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

Если вы не можете подключить отладчик к запущенному процессу, следующий метод — использовать "трассирующие маркеры", которые представляют собой просто операторы print(), разбросанные по коду и сообщающие, насколько далеко продвинулось выполнение программы. . Вывести на консоль (например: Console.WriteLine("Достигнут этап 1") или printf("Достигнут этап 1")) или записать в файл, начиная с очень детализированного (один вывод на метод или основную операцию), затем уточняя пока не найдете единственную операцию, при которой происходит сбой или неисправность.

Шаг 4. Определите строку кода, в которой действительно возникает ошибка

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

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

Шаг 5. Определите вид ошибки

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

Off-By-One
Вы начали цикл for с 1 вместо 0 или наоборот. Или вы думали, что .Count или .Length совпадают с индексом последнего элемента. Проверьте документацию по языку, чтобы узнать, отсчитываются ли массивы от 0 или от 1. Эта ошибка иногда также проявляется как исключение "Индекс вне допустимого диапазона".
Условие гонки
Ваш процесс или поток ожидает результата за несколько мгновений до того, как он будет фактически готов. Ищите использование операторов «Sleep», которые приостанавливают программу или поток, пока он ожидает выполнения чего-то еще. Или, возможно, он не спит, потому что на вашей перегруженной и недостаточно загруженной машине разработки каждый запрос удовлетворялся за миллисекунды до выполнения следующего оператора. В реальном мире все задерживается, и вашему коду нужен способ должным образом ожидать выполнения вещей, от которых он зависит. Попробуйте использовать мьютексы, семафоры или даже совершенно другой способ обработки потоков и процессов
Неверная конфигурация или константы
Просмотрите файлы конфигурации и все константы, которые вы определили. Однажды я провел 16 часов в аду, пытаясь понять, почему корзина покупок на веб-сайте зависла на этапе «Отправить заказ». Это было прослежено до неправильного значения в файле /etc/hosts, которое не позволяло приложению разрешить IP-адрес почтового сервера, и приложение работало до тайм-аута кода, пытавшегося отправить квитанцию по электронной почте на сервер. клиент
Неожиданный нуль
Спорим, вы несколько раз получили сообщение "Значение не инициализировано экземпляром объекта", верно? Убедитесь, что вы проверяете нулевые ссылки, особенно если вы связываете ссылки на свойства вместе, чтобы получить глубоко вложенный метод. Также проверьте наличие «DbNull» в фреймворках, которые рассматривают базу данных Null как особый тип
Неверный ввод
Вы проверяете ввод? Вы только что пытались выполнить арифметические действия, когда пользователь дал вам символьное значение?
Присваивания вместо сравнений
Особенно в языках C-семейства убедитесь, что вы не сделали =, когда собирались сделать ==
Неверная точность
Использование целых чисел вместо десятичных, использование чисел с плавающей запятой для денежных значений, отсутствие достаточно большого целого числа (вы пытаетесь сохранить значения больше 2 147 483 647 в 32-разрядном целом числе?). Также могут быть незаметные ошибки, возникающие из-за того, что ваши десятичные значения округляются, а отклонение со временем увеличивается (поговорите об этом с Эдвардом Лоренцем)
Переполнение буфера и индекс вне допустимого диапазона
Главная причина дыр в безопасности. Вы выделяете память, а затем пытаетесь вставить данные, превышающие выделенное пространство? Точно так же вы пытаетесь обратиться к элементу, находящемуся за концом массива?
Программист не умеет считать
Вы используете неверную формулу. Также убедитесь, что вы не использовали div вместо mod, что вы знаете, как преобразовать дробь в десятичную и т. д.
Объединение чисел и строк
Вы собираетесь объединить две строки, но одно из значений является числом, и интерпретатор пытается выполнить арифметические действия. Попробуйте явно преобразовать каждое значение в строку
33 символа в varchar(32)
В операциях SQL INSERT проверьте вставляемые данные на соответствие типам каждого столбца. Некоторые базы данных генерируют исключения (как и положено), а некоторые просто усекают и делают вид, что все в порядке (например, MySQL). Ошибка, которую я недавно исправил, была результатом переключения с инструкций INSERT, подготовленных путем объединения строк, на параметризованные команды: программист забыл убрать кавычки строкового значения, и это привело к тому, что оно на два символа превышало предельный размер столбца. Нам потребовались годы, чтобы обнаружить эту ошибку, потому что мы стали слепы к этим двум маленьким кавычкам
Недопустимое состояние
Примеры: вы пытались выполнить запрос по закрытому соединению или пытались вставить строку до того, как были вставлены ее зависимости по внешнему ключу
Совпадения в среде разработки не были перенесены в рабочую среду
Например: в искусственных данных базы данных разработки была корреляция 1:1 между идентификатором адреса и идентификатором заказа, и вы закодировали это предположение, но сейчас программа запущена, на один и тот же адрес отправляется миллион заказов, что дает вам 1:много совпадений

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

Шаг 6. Используйте процесс исключения

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

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

Шаг 7. Зарегистрируйте все и проанализируйте журналы

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

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

Шаг 8. Исключите оборудование или платформу как причину

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

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

Чтобы посмеяться, попробуйте подключить оборудование к другой розетке, особенно к другому выключателю или ИБП. Звучит безумно? Может быть, когда вы в отчаянии.

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

Шаг 9. Посмотрите на корреляции

Ошибка всегда возникает в одно и то же время суток? Проверьте запланированные задачи/задания cron, которые происходят в это время
Всегда ли это совпадает с чем-то другим, какой бы абсурдной ни казалась связь между ними? Обращайте внимание на все, и я имею в виду все: возникает ли ошибка, например, при включении кондиционера?Тогда это может быть скачок напряжения, который делает что-то странное в оборудовании.
Есть ли что-то общее у всех пользователей или компьютеров, на которые он влияет, даже если это параметр, который, по вашему мнению, не влияет на программное обеспечение, например, где они расположены? (Вот так была обнаружена легендарная ошибка "500-мильная электронная почта").
Происходит ли ошибка, когда другой процесс на машине потребляет много памяти или циклов? (Однажды таким образом я обнаружил проблему с SQL-Server и раздражающее исключение «нет доверенного соединения»)

Шаг 10. Привлеките помощь извне

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

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

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

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

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

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

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

Надеюсь, эти шаги помогут и вам.

Шаг 1. Воспроизведите ошибку самостоятельно

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

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

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

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

Шаг 2. Убедитесь, что вы действительно понимаете проблему

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

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

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

И не только ради вас.

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

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

Избегайте использования предположений, даже если они верны.

Шаг 3. Исправьте ошибку

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

Итак… иди и решай проблему!

Я не могу помочь вам с этим, извините. Я знаю, вы прочитали заголовок и предположили, что я могу. Мне очень жаль, и я британец, так что вы знаете, что я имею в виду. Я просто буду терпеливо ждать здесь со своим чаем!

Шаг 4. Проверка исправления

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

Хотя мы еще не совсем вышли из леса…

Шаг 5. Не тестируйте исправление. Попробуйте сломать его.

Тестирование — понятие расплывчатое само по себе.

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

Избавьтесь от путаницы. Не тестируйте примененное исправление. Вместо этого войдите и попытайтесь сломать его.

И вот почему: даже если у вас есть набор тестов со 100% покрытием кода, вы все равно можете пропустить жизненно важный сценарий, который может вызвать проблемы. Попытка сломать его дает вам цель и помогает вам и вашей команде довести свою работу до предела.

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

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

Шаг 6. Закрытие цикла

Удалось ли вам его сломать? О, Боже. Вернитесь к шагу 1 и повторите попытку.

Если вы не смогли его разбить, поздравляем! Разве вы не чувствуете себя намного спокойнее, зная, что точно знаете, что исправили?

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

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

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

Метод

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

Этап 1: Идентификация ошибки

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

Шаг 0. Не паникуйте!

Даже если ошибка находится в производстве и возникает в пятницу перед выходом из офиса, НЕ паникуйте!

Шаг 1. Воспроизведите ошибку

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

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

Шаг 2. Понимание ошибки

Этот шаг тесно связан с предыдущим. Различные механизмы, которые вы использовали для воспроизведения ошибки, могут дать вам четкое представление о проблеме; однако в некоторых случаях это не так.

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

Шаг 3. Понимание ожидаемого поведения

Выполняя предыдущие шаги, вы получаете ответ на следующий вопрос: почему возникла ошибка? На этом шаге вы должны ответить на другой вопрос — что должно произойти, если ошибка не возникнет?

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

Шаг 4. Разграничьте проблему

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

Следующие методы могут помочь вам определить проблему:

Используйте журналы: если вам повезет, журналы укажут прямо на нужную часть кода, вызывающую проблему

Добавить журналы, если они не существуют

Рефакторинг кода для облегчения его понимания

Устранить аппаратную корреляцию

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

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

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

Если это так, вы имеете право паниковать!!

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

Шаг 5. Аудит кода

После того как вы определили блок кода, вызывающий проблему, вам необходимо проверить другие части кода (функции, модули и т. д.) во взаимодействии с ним по следующим причинам:

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

Причина вашей ошибки в идентифицированном блоке кода может иметь такое же влияние на них, как и при их взаимодействии

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

Этап 2: Исправление ошибки

Потратив достаточно времени на то, чтобы понять и идентифицировать ошибку, вы можете приступить к этому этапу.

Шаг 6. Внесите исправления

Извините за этот шаг, но мне нечего сказать.

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

Шаг 7. Проверьте исправление

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

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

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

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

Очистить и сообщить

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

Шаг 8. Очистите код

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

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

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

Шаг 9. Сообщите об ошибке

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

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

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

Заключение

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

рекомендации, отладка, обнаружение ошибок, исправление ошибок, производительность, отладка, репликация, идентификация, тестирование

Читайте также: