Разработка Silverlight приложения для анализа ошибок (Центр Управления Проблемами «Дихлофос»)

Создать новую статью

retweet
09.08.2010 10:00


Информация об авторе

Павлов Дмитрий Юрьевич, Ивановский Государственный Энергетический Университет (ИГЭУ), аспирант 2го курса по специальности «Математическое моделирование, численные методы и комплексы программ». Выпускник ИГЭУ по специальности «Программное обеспечение вычислительной техники и автоматизированных систем».
Стажер Летней школы Intel 2010, Нижний Новгород, ментор Антон Бевзюк, менеджер Александр Коробков.

Сфера профессиональных интересов: Разработка бизнес приложений с использование платформы .Net и технологий Microsoft, экстремальное программирование и гибкие методологии разработки, паттерны объектно-ориентированного проектирования.

Аннотация

В данной статье описывается разработка системы сбора и хранения ошибок, а также разработка клиентского Silverlight приложения с богатым пользовательским интерфейсом для анализа, группировки и фильтрации накопленных ошибок (exceptions). В ходе работы применялись гибкие методологии разработки и практики экстремального программирования (Kanban, TDD, DDD). Законченная система получила название Центр Управления Проблемами «Дихлофос» и была успешно внедрена в отделе.

Введение

Когда в апреле 2010 года на сайте ISN я увидел объявление о Летней школе Intel, то понял, как хочу провести это лето. Задачу на стажировку я выбрал сразу - «Разработка Silverlight приложения для анализа ошибок». Это была отличная возможность попрактиковаться с новейшими технологиями и инструментами разработки Microsoft. К тому же, очень хотелось применить гибкие методологии разработки, о которых я давно и много читал, на практике.

Отдел, в котором я проходил стажировку, занимается разработкой нескольких десятков бизнес приложений для внутренних нужд Intel. Команда разработчиков территориально распределена, часть разработчиков работает в Нижегородском офисе (около 15 человек), другая, более многочисленная часть, находится в Индии (несколько сотен человек). Информация об ошибках, возникающих в разрабатываемых приложениях, отправляется разработчикам для последующего анализа. Такой информации поступает довольно много. Так, например, для одного приложения количество ошибок в неделю может превысить несколько сотен. Разработчикам приходиться отвлекаться и тратить свое время на сортировку и анализ поступающей информации. Однако не вся поступающая информация об ошибках является полезной.

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

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

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

Цели и задачи разработки

Разрабатываемую систему было решено назвать Центр Управления Проблемами «Дихлофос», сокращенно ЦУП «Дихлофос».
К данной системе предъявлялись следующие требования:

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

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

Технологии, инструменты разработки

При работе над проектом применялись следующие инструменты:

  • Microsoft Visual Studio 2010
  • Microsoft Team Foundation Server
  • Microsoft SQL Server 2005/2008
  • JetBrains Resharper 5.1
  • Silverlight 4
  • Microsoft Expression Blend
  • MS Visual Studio Unit Test Framework
  • Microsoft Enterprise Library 3.1, 4.1, 5.0

Разработка велась на языке C#. При разработке клиентского Silverlight приложения использовался шаблон проектирования MVVM (Model – View - ViewModel).

Описание процесса разработки

Работа велась с применением практик экстремального программирования и гибкой методологии разработки:

  • Kanban
  • eXtreme Programming
  • Pair Programming
  • Test Driven Development (TDD)
  • Domain Driven Design (DDD)

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

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

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

Таким образом, конечный пользователь был постоянно вовлечен и участвовал в процессе разработки, что позволило учесть практически все пожелания к конечному продукту. Я на своем опыте убедился в преимуществах работы по принципу разработка – показ (внедрение) – получение обратной связи от пользователя.

Кроме того, применение практик TDD и DDD позволяло легко изменять доменную модель системы, добавлять новую функциональность и рефакторить исходный код, без опасения «сломать» работу системы. Любая разработка новой функциональности начиналась с написания соответствующего теста. В итоге, я получил набор юнит тестов, полностью покрывающий всю функциональность системы.

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

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

Архитектура системы

Архитектура ЦУП «Дихлофос» представлена на следующем рисунке (Рис. 1).


Рис. 1 Архитектура ЦУП "Дихлофос"

В составе ЦУП «Дихлофос» можно выделить 2 подсистемы. Первая (Enterprise Library Exception Handler, WCF Registrator Service) отвечает за сбор и хранение информации об ошибках, вторая (WCF Manager Service, Silverlight Client) – за отображение накопленной информации.

Enterprise Library Exception Handler

Набор инструментов Enterprise Library от команды Microsoft patterns & practices – это архитектурные блоки, реализующие наиболее частые задачи, с которыми сталкиваются разработчики. Например, обработка исключений, логирование и т.д. Для удобного конфигурирования параметров каждого блока, с библиотекой поставляется удобный инструмент Enterprise Library Configuration.
Enterprise Library использовался в моем отделе для решения задач обработки и логирования информации об ошибках, возникающих в разрабатываемых приложениях. Взаимодействие с блоком Enterprise Library Exception Handling, который отвечает за обработку информации об ошибках, было уже настроено. Одной из моих задач было написание нового обработчика ошибок, который бы отправлял информацию о возникающих в приложениях ошибках и исключениях (exceptions) в базу данных ЦУП «Дихлофос». Кроме того, к моему обработчику ошибок предъявлялись дополнительные требования. Он должен был:

  • Легко встраиваться в существующую инфраструктуру приложений
  • Не требовать перекомпиляции исходного кода приложений
  • Вся настройка нового обработчика ошибок должна сводиться к добавлению соответствующих параметров к файлам конфигурации приложения (Web.config, App.config) либо вручную, либо с помощью инструмента Enterprise Library Configuration.

Данная задача была решена с помощью написания Custom Exception Handler. Enterprise Library предоставляет возможность для этого, достаточно создать класс, реализующий интерфейс IExceptionHandler:

При внедрении написанного обработчика по сбору информации об ошибках, возникла проблема в совместимости различных версий Enterprise Library: v 3.1, 4.1, 5.0. Модуль, первоначально написанный для Enterprise Library 5.0, не запускался на более ранних версиях. Данная проблема была решена написанием дополнительных Custom Exception Handler для версий Enterprise Library: v 3.1, 4.1. Таким образом, обработчик ошибок был написан в 3х версиях: для Enterprise Library v 3.1, v 4.1, v 5.0.
Кроме этого, для Enterprise Library v 5.0 был реализован дополнительный класс провайдер, позволяющий полностью интегрировать свой обработчик ошибок в среду Enterprise Library Configuration. Благодаря этому добавление моего обработчика ошибок к существующему приложению максимально упрощалась (Рис. 2).


Рис. 2 Добавление Dihlofos Exception Handler в Enterprise Library 5.0 Configuration

И, наконец, когда обработчики ошибок для 3х версий Enterprise Library были готовы и оттестированы, были написаны соответствующие программы-установщики. Теперь подключение моего обработчика ошибок к существующему приложению сводилось лишь к запуску программы установщика (Рис. 3), добавлению нового обработчика исключений (Exception Handler) в Enterprise Library Configuration, и настройке параметров: пути к WCF сервису (WCF Registrator Service) и названия приложения.


Рис. 3 Инсталлятор Dihlofos Exception Handler

WCF Registrator Service

Данный WCF сервис предоставляет API для регистрации информации о новой ошибке в базе. С данным сервисом общаются все обработчики ошибок (Enterprise Library Exception Handlers) на стороне приложения. Кроме того, приложения, не использующие Enterprise Library (например, приложение «App N» на Рис. 1) могут также регистрировать информацию об ошибках с помощью вызова API сервиса. API сервиса имеет вид:


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

WCF Manager Service

Данный WCF сервис предоставляет API для получения накопленной информации об ошибках. Сервис используется Silverlight клиентом для отображения накопленной информации об ошибках.

Silverlight Client

Представляет удобный графический интерфейс на платформе Silverlight для просмотра информации об ошибках, фильтрации по приложениям, типу ошибок и Stack Trace.


Рис. 4 Главная страница Dihlofos Silverlight Client


Рис. 5 Окно выбора приложений


Рис. 6 Окно What To Fix Details

Заключение

В ходе стажировки в Летней школе Intel 2010 удалось сделать многое: довести задание на стажировку до законченного состояния и внедрить результаты в отделе, а также приобрести бесценный опыт работы в крупной компании с мировым именем.
Во время работы над проектом удалось реализовать:

  • Собственные обработчики ошибок (Enterprise Library Exception Handlers) для различных версий Enterprise Library (v 3.1, 4.1, 5.0).
  • Полностью интегрированный в среду Enterprise Library Configuration обработчик ошибок для Enterprise Library 5.0.
  • Инсталлеры для получившихся обработчиков ошибок.
  • Обеспечить легкий механизм подключения обработчиков ошибок к существующим приложениям, не требующий перекомпиляции исходного кода приложений.
  • WCF сервис (WCF Registrator Service), ответственный за регистрацию информации об ошибках в базу данных.
  • Базу данных для хранения информации об ошибках.
  • WCF сервис (WCF Manager Service), предоставляющий механизмы доступа к накопленной информации в базе данных.
  • Silverlight клиент для отображения накопленной информации об ошибках.
  • Внедрить результаты работы в отделе.

Таким образом, удалось достичь следующих целей разработки: обеспечить сбор и хранение информации об ошибках, разработать клиентское Silverlight приложение для анализа ошибок и «развернуть» полученную систему в отделе.

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

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

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

В-третьих, удалось изучить и попробовать в деле самые новые технологии и инструменты (Silverlight 4, Enterprise Library, Microsoft TFS), и использовать самые современные средства разработки (Microsoft Visual Studio 2010, Expressions Blend, Resharper).

И, наконец, работа с опытными разработчиками позволила освоить несколько полезных приемов и техник, например таких, как рефакторинг баз данных и многое другое.

Кроме того, благодаря образовательной программе Летней школы Intel 2010 я получил представление о деятельности компании Intel в России, продуктах компании. Очень полезными оказались лекции по основам переписки и presentation skills. Отдельно стоит упомянуть дополнительные лекции по Agile, Scrum, Kanban, GUI Patterns. Они дали очень много для профессионального роста как разработчика.

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