Как известно, не бывает программ без ошибок, и существует множество инструментов и подходов, предназначенных для повышения качества выпускаемых приложений, от модульных тестов до анализаторов кода.
Однако даже если вы используете их все одновременно, никто не может гарантировать, что ваши приложения не содержат ошибок.
И если проблемы, возникающие при разработке и тестировании, нам видны сразу или почти сразу, и мы способны получить подробную информацию о том, что произошло, и быстро это исправить, то пострелизные ошибки, возникающие на стороне пользователя, более коварны.
Самое главное, что, скорее всего, вас о них просто не проинформируют. Как часто вы отправляли сообщения об ошибках в Microsoft, когда вас об этом просили? :) Пользователи, как правило, либо просто перезапускают приложение, ругаются и продолжают им пользоваться дальше, либо удаляют его совсем.
Если вам посчастливилось получить уведомление о падении, это часто будет выглядеть примерно так: 
а это совершенно не вносит ясности в понимание проблемы.
В результате у пользователей остается негативный опыт использования вашей программы, и вы не можете ничего с этим поделать.
Ну а если надежды на пользователей нет, то придется брать дело в свои руки.
Начнем с того, что мы знаем, что можем обрабатывать все исключительные ситуации в наших программах.
Например, в .
NET мы можем добавить глобальный обработчик для всех исключений.
Самое простое, что можно сделать дальше — записать в журнал все исключения, поступающие на этот обработчик.
Это хоть что-то.
Однако лог просто не отправится сам, и нам придется ждать сообщения от пользователя, чтобы узнать о проблеме и попросить его прислать этот лог, а это пустая трата времени, да и вообще пользователя можно вообще не писать.
Как вариант, мы можем сами отправить наш лог по электронной почте, но страшно представить, во что превратится наш почтовый ящик, если мы получим достаточно большое количество оповещений.
И это вполне реально на крупных проектах.
Да и вообще, парсить написанное в текстовом лог-файле в 100500 строк — занятие не очень приятное.
В результате мы приходим к выводу, что наиболее адекватное решение — это сервис, который будет работать в облаке и получать информацию о произошедших ошибках, обрабатывать ее, структурировать и показывать нам через веб-интерфейс в удобном виде.
.
Ну а почему бы нам не написать аналогичный сервис для себя? Изначально мы сделали в наших демках простой сборщик сбоев, чтобы получать данные об этих сбоях и на их основе исправлять проблемы в наших компонентах, тем самым улучшая их качество.
Это был всего лишь стек счетчиков и название демо-модуля, однако мы быстро поняли, что этих данных недостаточно, и начали его расширять.
В результате сейчас мы собираем очень подробную информацию о среде, в которой произошла ошибка, от списка загруженных библиотек и версий студии и фреймворка до версии ОС и текущей установленной культуры.
При этом, если нам понадобится, мы всегда можем добавить любую дополнительную информацию через механизм CustomData. Например, вы можете посмотреть отчет об испытаниях .
Когда информации было достаточно для поиска проблемных мест, мы столкнулись с тем, что иногда отчетов было очень много.
Ведь если проблема достаточно тривиальна, то велика вероятность, что на нее наткнутся многие пользователи.
И в такой ситуации мы получаем отчет от каждого из них.
В результате мы имеем кучу отчетов, которые если и не идентичны, то чрезвычайно похожи: 
Понятно, что работать со всем этим, мягко говоря, сложно, плюс среди всех этих одинаковых отчетов могут затеряться уникальные, оповещающие о других проблемах.
Чтобы избавиться от этого, мы реализовали поиск дубликатов по определенному набору ключевых полей и свернули их в один отчет: 
Да, это намного лучше.
Однако помимо дублей во входящих было довольно много отчетов, которые нам просто не интересны, например, это могли быть отчеты об уже исправленных проблемах.
Это подтолкнуло нас к задаче реализовать автоматическое игнорирование входящих отчетов для некоторых условий, а условий нам было задано очень много: чтобы игнорировалось по версии, и чтобы игнорировалось по ключевым словам в стеке столбцов.
, и чтобы ее можно было игнорировать в определенных строках стека столбцов, и чтобы ошибку можно было игнорировать без наших мы не получили никаких компонентов в Colstack и т. д. и т. п.
В результате мы определили 4 основных типы правил игнорирования, и это охватывало все наши задачи.
В общем, эта тема заслуживает отдельной статьи, поэтому здесь я приведу ссылку на документацию, чтобы вы могли составить общее впечатление об этом механизме: Игнорирование фильтров Работая с сервисом, мы нашли ему еще одно необычное применение: он отлично может помочь службе поддержки.
Часто пользователи пишут, что у них возникла какая-то проблема, но воспроизвести ее можно только на машине пользователя, и нет возможности обмануть или получить какую-либо подробную информацию о самой ошибке.
Или, например, возникают ошибки в программах, которые имеют ограниченные права и не могут писать лог-файл.
Во всех этих ситуациях нам успешно помогает Logify, ведь сбор данных о сбоях развернутых приложений — его основная задача.
В результате Logify был внедрен во многие наши продукты и теперь приносит ощутимые преимущества.
В процессе разработки Logify явно перестал быть просто проектом для внутреннего использования, и мы решили выпустить его как отдельный сервис.
Его отшлифовали и представили публике с переработанным пользовательским интерфейсом сначала в виде бета-тестирования, а на данный момент он уже полностью запущен в производство.
Итак, если кому-то интересно, приглашаю попробовать: Логифицировать .
Клиенты доступны по адресу GitHub .
Теги: #devexpress #devexpress #devexpress #разработка #качество от #logify #программирование #.
NET
-
Инструкции По Преобразованию .Wmv В .Mov
19 Oct, 24 -
Информация – Главный Инструмент Управления
19 Oct, 24 -
Почему Работа Не Квартира?
19 Oct, 24 -
Лепка Снеговика (Оформление Приложения)
19 Oct, 24 -
Google Закрывает Сервисы Latitude
19 Oct, 24
