Как справляться с ошибками, когда они появляются в вашем проекте

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

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

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

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

Процесс ошибки

Цель отчета об ошибке - четко объяснить наблюдаемую проблему и подробно описать шаги, предпринятые для ее устранения, чтобы техническая группа могла определить ее основную причину и принять решение.

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

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

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

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

Обеспечьте контекст

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

Некоторые примеры часто полезной контекстной информации:

  • Идентификаторы учетной записи - адрес электронной почты вашей учетной записи, имя пользователя или организация.
  • Время и дата - когда произошел инцидент
  • Местоположение - URL-адрес и описание экрана приложения, на котором вы были.
  • Приложение / платформа - ваш веб-браузер, мобильная платформа или операционная система.
  • Версия - версия программного обеспечения, которое вы используете.

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

Сверхобщаться

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

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

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

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

Подробно описать шаги по воспроизведению

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

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

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

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

Советы по общению

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

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

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

Заключение

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

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

Приложение: Шпаргалка по отчетам об ошибках

Вот краткое руководство по сообщениям об ошибках, которые вы можете настроить для себя или своей команды:

Помнить

  • Будьте подробными и конкретными. Чрезмерное общение.
  • Отделите свои теории от наблюдений.
  • Сохраняйте учтивый тон.

Обеспечьте контекст

  • "Кто что когда где почему"
  • Идентификаторы аккаунта, дата и время, местоположение
  • Включите скриншоты / записи

Описывать

  • Что ты сделал
  • Что вы ожидали произойти
  • Что на самом деле произошло
  • Предоставьте шаги, чтобы постоянно воспроизводить проблему

Влияние

  • Как это влияет на использование вами продукта?
  • Вы нашли обходной путь?