Как выглядит исправление ошибки
16 мая 2022 г.Исправление ошибок — неотъемлемая часть программирования. Невозможно написать код без ошибок — вы всегда начинаете с чего-то, тестируете это и исправляете то, что не так. Опыт работы над ошибками сильно различается между проектами, которые вы делаете самостоятельно, и коммерческими проектами на работе. В этой статье я показываю, как я подхожу к новым ошибкам в своей работе.
Откуда берутся ошибки
Большинство ошибок, с которыми я сталкиваюсь, исходят от моих коллег, которые тесно сотрудничают с клиентами в службе поддержки или на должности по работе с клиентами. Они находят проблемы, помогая клиенту решить проблему или достичь своих целей. Решением некоторых проблем является настройка параметров в приложении или обновление поврежденных данных в базе данных: в этом случае эти проблемы решают сотрудники службы поддержки. Когда они не видят возможности устранить проблему самостоятельно, они пишут тикет в разработку. И эти билеты в конце концов прибывают на мой стол.
Это вообще ошибка?
Ошибки, связанные с бизнес-приложениями, могут быть довольно тонкими — до такой степени, что не совсем ясно, является ли данное поведение правильным или нет. Иногда это сильно зависит от контекста: может быть, у одного клиента есть рабочий процесс, в котором он предпочитает одно поведение, но текущее поведение является оптимальным для других клиентов.
В большинстве случаев потребность одного конкретного клиента инициирует создание тикета. Из-за этого мы должны убедиться, что исправление не сделает всех других клиентов недовольными. Чтобы избежать такой регрессии, мы часто обсуждаем в большой группе, какое поведение необходимо. Если для разных клиентов важно иметь разное поведение, возможно, нам нужно будет контролировать эту часть для каждого клиента. В этих случаях отчет об ошибке становится запросом функции.
Воспроизведение ошибки
Когда мы соглашаемся, что какое-то поведение является неожиданным, мне нужен способ увидеть, как оно происходит. В противном случае я бы менял код, не видя последствий своих изменений. Слепая корректировка кода, скорее всего, приведет к еще большему количеству ошибок. Настройка, которую мы имеем для приложения, немного сложна: я могу воспроизвести большинство проблем локально, но для некоторых мне нужно использовать внешний сервер.
Локально
Лучше всего воспроизвести проблему на машине разработчика. Это обеспечивает быструю обратную связь при работе с заявкой. Большая часть системы прекрасно воссоздана изолированно, чтобы создать локальную среду в приложении, которое я поддерживаю. Когда я могу воспроизвести проблемное поведение на своем локальном компьютере, у меня есть короткий [цикл обратной связи] (https://how-to.dev/how-to-speed-up-your-progress-with-feedback) для моих изменений. , и я могу быстро перебирать код и исправлять ошибку, не теряя много времени.
К сожалению, наш проект имеет некоторую сложность, не позволяющую локально воспроизвести некоторые ошибки. Несколько частей системы отличаются для среды разработки:
- унаследованная БД, которая только частично доступна для непроизводственной среды, и
- сторонние интеграции, которые мы отключили для локальных и тестовых сред, например, заказ доставки посылки по заказу.
На тестовом сервере
Для моей работы у нас есть дублированные данные о клиентах для тестовой среды, и они ближе к фактическому приложению, чем локальная настройка. Если ошибка не возникает локально, то следующим местом для проверки является тестовый сервер. Такой способ далек от совершенства; любые исправления должны пройти долгий путь, прежде чем я смогу проверить их в действии.
Тестировать на выделенном тестовом сервере намного лучше, чем делать это непосредственно на производстве, потому что, если что-то пойдет не так, мы все равно сможем исправить это до того, как это повлияет на клиентов.
На производстве
Последняя надежда - увидеть ошибку своими глазами. Если ошибка связана с клиентом, это может зависеть от точной комбинации настроек в его учетной записи или его данных. Воспроизведение ошибок в продукте помогает сохранить здравомыслие: это может подтвердить, что отчет об ошибке не был ошибочным. Но использовать производство в качестве тестовой площадки даже для самых незначительных изменений кода — плохая идея — это медленно, и если я что-то напутаю, это повлияет на клиентов.
Возврат тикета его автору
Если я не могу воспроизвести ошибку самостоятельно, я мало что могу с этим поделать. В этой ситуации я прошу репортера предоставить дополнительную информацию, а иногда даже вызываю их на звонок с демонстрацией экрана, чтобы мы не тратили слишком много времени на синхронизацию.
Многие вещи могут быть причиной ошибки.
- Возможно, в заявке упущены какие-то важные детали сценария, когда ошибка должна появиться, или
- возможно я упустил какую-то деталь, или
- может это был просто глюк
Другая возможность заключается в том, что кто-то исправил проблему за время, прошедшее с момента исходного отчета об ошибке.
Поиск исходника в коде
Обсудив ожидаемое поведение и увидев ошибку в действии, я готов просмотреть код и изучить его работу. В зависимости от качества кода эта задача может быть довольно простой в хорошо организованном проекте или довольно сложной, если у нас есть ситуация с «спагетти-кодом».
Исправление + добавление тестов
Последний шаг — изменить поведение и протестировать изменение. Как минимум, мне нужно увидеть, что моя ошибка исчезла из приложения, поэтому я повторяю шаги воспроизведения и смотрю, стал ли результат лучше, чем раньше.
Если приложение ведет себя так, как должно, то следующим шагом будет добавление некоторых автоматических тестов. Самый простой подход — добавить несколько модульных тестов к аспекту, который вы только что изменили. Полное покрытие включает в себя проверку изменений взаимодействия с пользователем с помощью сквозного (E2E) теста.
Подробнее о различных аспектах тестирования вы можете прочитать в других моих постах:
Также опубликовано [Здесь] (https://how-to.dev/what-fixing-a-bug-looks-like)
Оригинал