VS 2005 – первые впечатления

Ну вот и вышла официально VS 2005. О нововведениях написано и показано было много, мне же хотелось "потрогать" продукт своими руками и оценить, чего будет стоить переход и какие преимущества он даст. Делюсь впечатлениями.

Удобства

Заметно, что уделено много внимания кастомизации среды. Для этого появилось множество настроек. О разработчике позаботились (на этот раз ;) ) – не зря все эти комьюнити, фидбэк и привью. Масса мелких улучшений касается юзабилити IDE (например, докинг окон или свойства проекта). Наконец-то появились шаблоны (code snippets). На мой взгляд, удобства - это важно, так как они увеличивают не только комфорт, но и производительность разработчика.

Нововведения

Хотя о нововведениях написано было много, все же не удержусь упомянуть некоторые, поскольку они бросаются в глаза. Анализ кода, рефакторинг, и автоматизированные тесты – в общем, они есть. Раньше приходилось пользоваться дополнительными утилитами, теперь все интегрированно в студию.

Открываем старый проект...

Для проверки совместимости я открыл небольшой (всего нескольких проектов), но насыщенный разнообразными техниками (например, Managed C++ и COM-серверы) solution, созданный в 2003-й студии. Визард предложил сконвертировать проект, а в конце работы отобразил отчет: 0 ошибок, 0 предупреждений. Отличный результат. Компиляция и запуск старой программы на Framework 2.0 также прошли успешно.

Отладчик работает быстрее. Основные окна отладки изменений на первый взгляд не претерпели. Отладчик стал более "хитрый" – например, при нажатии trace into при десериализации он заходит в конструктор десериализумого класса, чего раньше не происходило. Однако, эта "хитрость" связана с меньшей надежностью: при попытке протрассировать (trace into) ничем не примечательное присвоение переменной, что отладчик по идее должен игнорировать и переходить на следующую строку, отладчик выдал сообщение об ошибке ContextSwitchDeadlock. Данная ошибка воспроизводилась постоянно в нескольких сессиях отладки, однако, исчезла после перезагрузки компьютера. В общем, по традиции, сразу после релиза начинаем ждать сервис пак.

Ложка дегтя

Хотя удобству IDE в новой студии уделено немало внимания, не везде выдержан единый стиль. Некоторые закладки в свойствах проекта не подстраиваются автоматически при изменении размеров окна. Например, окно Build events не растягивается вместе с окном настроек; если нужно больше места, то необходимо нажать на кнопку открытия отдельного окна Build Events (зачем?). Мелочь, но из таких мелочей складывается впечатление о качестве продукта. Помню, на докладе по SQL Server 2005 на конференции Platform 2006 зал аплодировал просто тому, что диалоги настроек имеют нефиксированный размер. И молча слушал, когда речь шла, например, о поддержке xml запросов на уровне SQL. :)


Особо надо сказать о снипетах. Эту важную и привычную во многих IDE опцию Microsoft, однако, умудрилась сделать неудобной. Во-первых, менеджер снипетов вместо кода показывает описание, шоткат, тип снипета и автора. Сам код снипета увы недоступен ни для просмотра ни для редактирования. Я не знаю кого интересует описание снипета, по-моему, - сам код как правило красноречивее, а зачастую его нужно менять под собственный стиль.



Во-вторых, сама вставка снипета. Шоткат для вызова списка снипетов Ctrl-K, X. (Не самый удобный, так что лучше сразу сменить.) Однако, всплывающее окошко снипетов отображает еще не сами снипеты, а их категории; необходимо сместить курсор на нужную категорию, войти в нее, нажав Enter, после чего можно выбрать снипет!!! Это похоже на плохую шутку: смысл снипетов – минимизировать нажатия клавиш, а не наоборот. Такое впечатление, что IDE других производителей (IDEA, Delphi) пишутся разработчиками и для разработчиков - в отличие от студии.

Серьезный недостаток - невозможность в новой студии создавать проекты для фрэймворка 1.

[Update]Вот еще (далеко не полный) список недоработок студии: VS 2005 Annoyances

Выводы

Переход на новую студию и фрэймворк должны быть достаточно простыми, и преимущества серьезные. Улучшилась юзабилити среды и появились фичи для "серьезных" разработчиков - рефакторинг, автоматические сборка и тестирование, статический анализ кода (только в Team Suite?). Такое смещение акцентов закономерно, так как сложность процесса разработки растет. В то же время, есть проблемы с надежностью и удобством продукта.

Replacer

При разработке на C# COM-серверов для использования в MS Office встает проблема экспорта интерфейсов таким образом, чтобы обеспечить их совместимость с VBA. В C# / .Net имеется довольно небольшой набор средств, позволяющих управлять видом COM-интерфейсов и маршаллингом типов: атрибуты, кастомизированные маршаллеры и собственно синтаксис C# в сочетании с маршаллером по умолчанию. Однако этих средств недостаточно для того, чтобы реализовать некоторые типичные для VBA конструкции. Например, параметры-массивы или функции с необязательными параметрами.

Выход - не использовать Type Library, генерируемую средствами фрэймворк (.tlb файл), а писать свои определения интерфейсов на IDL. При помощи IDL можно описать любой интерфейс, поддерживаемый COM. Недостаток подохда в том, что написанный вручную IDL нужно синхронизировать с описанием интерфейса на C#. (В отличие от tlb, генерируемого по умолчанию, который синхронизируется с кодом автоматически во время сборки проекта.) Синхронизация IDL вручную чревата ошибками и требует много рутинной работы, объем которой растет вместе с ростом разрабатывамой библиотеки компонентов. Поэтому необходима утилита для генерации IDL на основе кода. Эту утилиту можно запускать при сборке, в том числе автоматической.

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

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

В итоге получилась утилита командной строки - Replacer, - которая используется следующим образом:

Replacer.exe macros.xml

То есть набор параметров (входной и выходной файлы) и макросов поиска и замены (регулярных выражений) описывается в XML файле.

[Update]На данный момент подход уже используется продолжительное время, и позволил практически забыть о проблеме совместимости COM интерфейсов между C# и VBA.

Открытие блога!

Добро пожаловать в мой блог!

Здесь я планирую писать о том, что меня интересует, а значит, надо немного рассказать о своих интересах. Интересуют меня следующие темы:

- финансовые рынки, инвестиционный банкинг, трэйдинг
- информационные технологии, проектирование ПО, процесс разработки
- программирование финансовых приложений