1990-е зовут, они хотят вернуть свой процесс сообщения об ошибках
startups debugging bug-reporting

1990-е зовут, они хотят вернуть свой процесс сообщения об ошибках

15 марта 2023 г.

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

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

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

Have you ever seen a Jira ticket with this lack of context? I have. The way we report bugs is bonkers. It's time for a change!

Настоящая жизнь жука

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

When bug reporting happens in Slack it can be especially inefficient.

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

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

Время перемен

Сегодняшний процесс сообщения об ошибках остается архаичным. С 1990-х годов в мире изобрели мгновенные сообщения, такие как Slack, и видеозвонки, такие как Zoom, и повсеместно внедрили удаленную работу. Сообщение об ошибках стало цифровым. Отслеживание ошибок переместилось из письменных файлов в тикеты Jira. И тем не менее, отчеты об ошибках по-прежнему полны надоедливой переписки, которая тратит время разработчиков.

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

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

Jam team planning Jam features

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

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

With Jam, you automatically get network requests, console logs, browser and device details and more.

Мы начали делиться Jam с другими инженерными командами и были очень взволнованы реакцией. Ramp, T-Mobile и Dell одними из первых внедрили Jam и предоставили бесценные отзывы, которые помогли нам сформировать продукт. Повторяя их вклад, мы с гордостью сообщаем, что у Jam более 14 000 пользователей, и их количество продолжает расти.

Но наша работа далека от завершения. Мы знаем, что процесс сообщения об ошибках может быть основным источником разочарования для разработчиков, и мы стремимся изменить это. Если вам надоели неясные отчеты об ошибках, мы приглашаем вас попробовать Jam и сообщить нам, что вы думаете. Мы стремимся построить лучшее будущее для инженеров, и нам нужны ваши отзывы, чтобы это произошло. Вы можете связаться со мной лично по адресу dani@jam.dev и присоединиться к нам в этом путешествии.

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE