Как решить, что исправить, когда
Одна фундаментальная истина разработки программного обеспечения заключается в том, что будут возникать ошибки, и это включает в себя всевозможные причуды, такие как ошибки кодирования, проблемы, возникающие из-за того, что зависимость отключена, визуальные несоответствия, возникающие из-за неправильного понимания макета, и многое другое.
Хотя существует множество методов, которые помогают повысить качество кода, например, разработка через тестирование и принципы SOLID; и хотя существует множество других методов, которые помогают выявлять ошибки на раннем этапе, такие как регрессионные тесты, нагрузочные тесты и многое другое, ошибки все равно будут возникать и раздражать ваших пользователей.
К счастью, есть несколько методов, которые помогут вам упростить сортировку и исправление ошибок.
1. Знайте своих клиентов
Прежде чем разрабатывать какую-либо функцию, всегда полезно узнать своих клиентов как можно больше - это неотъемлемая часть любого гибкого процесса. Однако большинство команд забывают, что это также важно для поддержки вашего приложения.
Чтобы успешно отсортировать заявки об ошибках на более поздних этапах процесса, вы должны быть в состоянии определить, какие устройства / ОС / браузеры используют ваши клиенты; к какому сегменту принадлежат ваши клиенты, и какие уровни обслуживания вы взяли на себя, а также какие уровни обслуживания ожидают ваши клиенты.
Зная, какие браузеры используют ваши клиенты, вы можете заранее протестировать свои интерфейсы с этими браузерами, а также получить некоторые средства для определения того, сколько людей будут затронуты проблемами браузера.
Даже во времена, когда в браузере меньше движков рендеринга, в зависимости от размера ваших интерфейсов, вы обнаружите тонкие или резкие различия. Добавьте довольно новые технологии, такие как WebRTC, и знакомство с различиями браузеров и версий станет рутиной еженедельно.
Как только вы узнаете, какие браузеры используют ваши клиенты, решите, какие именно браузеры вы хотите поддерживать, и, в идеале, что делать с остальными - простое игнорирование их только добавит вам нагрузки в дальнейшем и разочарует пользователей.
Вы можете перенаправить некоторые браузеры на страницу, объяснив, что они не поддерживаются (например, IE8?), А какие нет; а для других вы можете просто показать уведомление о том, что браузер не поддерживается и могут существовать проблемы, но не блокировать их.
Знание ваших клиентских сегментов помогает понять, насколько вероятно изменение этих браузеров, например насколько вероятно, что они обновят свои браузеры.
Корпоративные клиенты с большей вероятностью будут придерживаться более старых / долгосрочных версий браузера, и они потенциально не смогут ничего изменить без одобрения центрального ИТ-отдела.
Также важно четко сообщать, какие уровни обслуживания вы обязуетесь, и знать, каких уровней обслуживания ожидают ваши клиенты.
Сообщение о потенциальном времени простоя из-за технического обслуживания и ошибок должно быть не только частью любого честного контракта, но также должно быть ясно, какое приложение и качество вы пытаетесь предоставить.
Если вы пишете программное обеспечение для врачей, вам, вероятно, не следует полагаться на один сервер. В любом случае, ваши клиенты и фактические конечные пользователи могут по-разному относиться к уровню обслуживания вашего приложения, а это означает, что вы всегда должны помнить, что ожидания обычно выше, даже если в вашем контракте есть время для решения проблемы.
2. Отслеживание проблем с помощью простого процесса
Если вы знаете, кто ваши клиенты и чего они ожидают, вы можете начать полноценное тестирование своего приложения. Каждую ошибку, которую вы обнаружите или о которой вам сообщают, следует отслеживать простым способом, чтобы ни у кого не было оправдания, чтобы не сообщить об ошибке.
Вы можете добавить адрес электронной почты, например [email protected], чтобы ваши коллеги могли легко и быстро сообщить вам о проблеме.
В конце концов, сотрудники отдела продаж или службы поддержки могут слышать об ошибках непосредственно от клиента, но не сообщать о них, если процесс слишком сложен для использования, и при этом необходимо найти обходной путь для клиента или к нему подать жалобу.
Вы все равно должны убедиться, что все знают, какая информация вам нужна для лучшего отслеживания проблемы - кто сообщил об ошибке, кто был затронут проблемой, на каком устройстве, с помощью какой версии / браузера, в какое время, какая функция использовалась, и что произошло - но на самом деле часто не вся информация доступна.
Если вы обнаружите проблемы, которые могут повлиять на многих пользователей, или проблемы, которые являются серьезными, даже если они могут повлиять только на нескольких пользователей, также сообщите об этом хотя бы в вашей компании, чтобы люди, контактирующие с клиентами, знали о них.
В зависимости от целевой аудитории вашего продукта вы также можете поделиться со своими клиентами списком известных проблем (желательно вместе с обходными путями).
3. Используйте инструмент автоматического сообщения об ошибках.
В дополнение к тому, что люди вручную сообщают об ошибках, убедитесь, что вы настроили автоматический инструмент для сообщения об ошибках, такой как Rollbar, Sentry, Bugsnag, Raygun или любой другой.
Все эти инструменты поддерживают множество языков программирования, что позволяет получать отчеты как из внешнего интерфейса (в коде JavaScript, TypeScript и т. Д.), Так и из серверной части вместе со многими дополнительными показателями, такими как количество затронутых людей, как часто возникала ошибка, настраиваемые метаданные и многое другое.
В настоящее время многие также предлагают сравнение выпусков, чтобы вы могли отслеживать свою стабильность с течением времени.
Тем более, что часто ваши пользователи не будут беспокоиться о сообщении об ошибке, имея автоматизированный инструмент, сообщающий об исключениях вместе с трассировкой стека, исходной картой и хлебными крошками, которые привели к ошибке, что помогает отлаживать и обнаруживать ошибки в массовом порядке.
Инструменты на удивление легко настраиваются - в большинстве языков программирования (например, Java) или фреймворков (например, Express) это так же просто, как добавление библиотеки или промежуточного программного обеспечения, и действительно нет оправдания для отказа от сбора этих данных.
Также не забудьте ввести любые метаданные, которые впоследствии могут быть полезны для сортировки и исправления ошибок (например, уровень лицензии клиента, идентификатор пользователя, используемый продукт), но помните, что не следует чрезмерно обмениваться данными, особенно когда речь идет о PII.
Но даже если ваша компания сильно ограничивает отправку данных сторонним обработчикам данных (привет, GDPR), вы можете найти инструменты сообщения об ошибках, которые используют локальные установки (например, Bugsnag).
А для стартапов планы начального уровня (с более коротким сроком хранения исторических данных) доступны и определенно дешевле, чем тратить время разработчика на попытки вручную найти причины ошибок.
4. Имейте политику «нулевых ошибок», чтобы улучшить свое качество и изменить свое мышление.
Как только вы обнаружите в своем приложении некоторые ошибки, самое время отсортировать и исправить их.
Многие команды совершают ошибку, собирая старые отчеты об ошибках в своем бэклоге продукта, загромождая свой бэклог и требуя постоянных усилий для определения приоритета каждого нового тикета по сравнению с тикетами, сделанными месяцами (или даже годами).
Прежде всего, чтобы иметь более свежую основу для работы, просто закройте старые сообщения об ошибках. Если вы недостаточно заботились об ошибке, чтобы исправить ее, например, в последние шесть месяцев, скорее всего, в следующие шесть месяцев это вас не волнует.
Если сообщение об ошибке устарело, скорее всего, часть вашего приложения изменилась или браузеры, которые были затронуты, больше не существуют. Если кто-то отправил отчет об ошибке год назад и по-прежнему заботится об исправлении, он обратится к нему снова; в противном случае исправление ошибки, скорее всего, ничего не изменит.
Вместо этого сосредоточьтесь на том, что делать с вашими текущими ошибками, и убедитесь, что они не станут такими же старыми. Для этого попробуйте применить политику «ноль известных ошибок».
Это значительно сокращает когнитивные усилия, необходимые для определения приоритетов ошибок, поскольку заявки на ошибки больше не будут оставаться в вашем бэклоге навсегда, и не будет возможности просто откладывать исправление ошибок на каждый спринт.
Во-вторых, это со временем повышает качество вашего кода, не (просто) потому, что разработчики по крайней мере будут рассматривать все ошибки, а в большей степени потому, что он имеет сильный психологический эффект - он заставляет всех искать способы уменьшить количество проблем и увеличивает качество вашего продукта на нескольких уровнях.
Это также можно применить к существующим приложениям; закройте слишком старые тикеты, а затем работайте над всеми оставшимися тикетами ошибок в пакетах в течение следующих двух спринтов, пока не дойдете до нуля.
Однако убедитесь, что эта политика поддерживается командой и руководством. Команды разработки / эксплуатации часто приветствуют такую политику, поскольку мы часто гордимся качеством своей работы и хотим, чтобы все работало безупречно.
Однако руководству может не нравиться любое падение скорости, поскольку ценность для бизнеса, которую может иметь стабильный код, часто видна только тогда, когда ключевые клиенты жалуются (а к тому времени, вероятно, будет уже слишком поздно).
Следовательно, обязательно объясните природу исключений в коде (поведение системы невозможно предвидеть), корпоративный риск (жалобы клиентов и / или проблемы с безопасностью / GDPR) и увеличение скорости в долгосрочной перспективе (лучшее общее качество и более глубокое понимание кода командой).
Если вы не можете или не хотите применять политику «нулевых известных ошибок», обязательно определите политику вместе со своей командой и руководством.
Это не обязательно должно быть полноценное соглашение об уровне обслуживания, особенно потому, что оно часто усиливает ощущение того, что ИТ - это внутренний поставщик, а не часть компании.
Тем не менее, вы должны, по крайней мере, объяснить своим коллегам, почему определенные ошибки все еще существуют, и в идеале регулярно обновлять старые сообщения об ошибках.
5. Сортировка сообщений об ошибках, поступающих от затронутых клиентов, во-первых, во-вторых, по степени серьезности.
Прежде чем приступить к работе над исправлением ошибок, обязательно сначала отсортируйте ошибки. Подобно методам управления задачами, таким как GTD, постарайтесь немедленно исправить все очевидные быстрые победы.
Если в строке допущена опечатка, отсутствует значок значка, код состояния POST-ответа сервера - 204 вместо 201, попробуйте немедленно исправить это.
Если вы уверены, что что-то исправить всего за пару минут, не стоит слишком долго думать об этом в процессе сортировки.
Что касается всего остального, не вдавайтесь в подробности, прежде чем работать над исправлением, и особенно не пытайтесь оценить его (например, не с помощью очков истории или каким-либо другим способом).
Часто расследование составляет большую часть исправления ошибки, поэтому оставьте это разработчику, когда он начнет работать над проблемой; и поскольку оценка перед расследованием затруднена из-за скрытой сложности большинства ошибок, оценки являются пустой тратой времени.
Кроме того, очки истории должны отражать скорость работы вашей команды по реализации функций, а не ошибок (в конце концов, это очки истории).
В противном случае команда, которая никогда не улучшит свое качество, будет постоянно иметь высокую скорость, в то время как команда, у которой остается все больше свободного времени для разработки функций, не имеет увеличения скорости.
Следовательно, для всех проблем, которые не могут быть устранены немедленно, вы должны просто придумать простую приоритизацию, которая в идеале работает, не вдаваясь слишком глубоко в отчет об ошибке, например, сначала обслуживайте своих ключевых клиентов, а затем все остальное; исправляйте ошибки сначала у многих пользователей, а потом уже у остальных.
Традиционный подход «сначала исправляйте блокировщики, затем критические ошибки, а затем косметические проблемы» не помогает, если ваш единственный ключевой клиент, ответственный за 30% вашего дохода, недоволен, пока вы работаете над блокировщиком, который произошел с одним IE11. пользователь, зарегистрировавшийся на пробную сессию.
Когда вы, наконец, начнете исправлять ошибку, установите временные рамки для расследования отчета об ошибке, а также временные рамки для разработки исправления, чтобы были четкие границы.
Это гарантирует, что разработчикам не нужно активно просить о помощи, так как многие этого не сделают. В зависимости от вашего домена, возможно, когда превышен временной интервал, команда может помочь разобраться в ошибке, ваш внешний поставщик услуг может присоединиться, клиента могут попросить провести сеанс демонстрации экрана,…
Наконец, если ошибка действительно не может быть исправлена (например, ее решение неэкономично; этот бедный пользователь IE11), обязательно добавьте ее в список «известных проблем» (или технических требований) для вашего приложения, и в идеале добавьте полезное сообщение об ошибке.
6. Улучшение взаимодействия с пользователем при возникновении ошибки или сбоя
Наконец, насколько это возможно в вашем фреймворке или языке программирования, постарайтесь создать хорошее взаимодействие с пользователем при возникновении проблемы.
Например, если вы работаете над приложением React, убедитесь, что неудачный запрос сервера не приводит к сбою всего приложения, и используйте границы ошибок, чтобы сообщить, что некоторые функции вашего приложения в настоящее время недоступны.
В идеале вы должны подготовить страницу статуса, используя одну из многих служб страницы статуса (Admin Labs, Statuspage,…), и ссылку на эту страницу статуса на страницах ошибок 5xx вашего сервера, а также в нижнем колонтитуле вашего приложение.
Во время серьезных сбоев или проблем вы можете сообщить, что сломано, что вы делаете, чтобы это исправить, и когда ожидать безотказной работы, чтобы клиенты не остались одни в недоумении, что происходит.
Также подумайте о своем процессе разработки и о том, как его улучшить, чтобы уменьшить влияние ошибок.
Например, посмотрите, можете ли вы реализовать новые функции или изменения с помощью флагов функций, чтобы не все клиенты пострадали от ошибок программирования. Этот метод программирования также прекрасно «упаковывает» новую функцию, так что с ее недоступностью можно легче справиться, даже в дальнейшем.
Кроме того, используя флаги функций, вы можете собирать отзывы о новых функциях от реальных клиентов (или, по крайней мере, от внутренних клиентов в действующей системе), постепенно развертывать функции или отменять развертывание, а затем снимать флажок, когда функция становится доступной для всех. и работает.
