Гольф в графстве Айлэнд

Microsoft не перестает меня удивлять. Казалось бы, что нового можно предложить в среде программирования? Устранить ошибки (а заодно добавить новые) да внести некоторые количественные изменения - дополнительные компоненты и опции. Однако в новой версии Visual Studio "Whidbey", финальный релиз которой обещается в начале 2005 года, шаги вперед, пусть и не семимильные, но все-таки заметные, сделаны сразу по нескольким направлениям.

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

1) Расширители кода (expansion, см. рис.). Как показывает практика, до 75% кода программы - это такие простые конструкции, как условия, циклы, классы и тому подобная элементарщина. Дабы не набирать этот, почти очевидный, код вручную, IDE предоставит вам возможность одним нажатием вставить весь модуль. Естественно, вы можете сделать свои или настроить существующие расширители - благо они написаны на XML.

2) Смарт-теги. Кому-то может показаться, что это излишество, но смею заверить, что излишество весьма и весьма полезное. Например, при ошибочном наборе ключевых слов вам, как в "Ворде" при проверке орфографии, будет предложен список возможных значений (см. рис.).

3) Технология intelliSense подверглась доработке. Она позволяет автоматически завершить написание оператора, свойства или функции; то есть когда вы начинаете писать команду или параметр, в окне предлагаются возможные варианты, и вам остается только подтвердить один из них, нажав Enter. Появилась поддержка шаблонов и средства формирования списка из доступных значений при добавлении блоков try/catch (см. рис.).

4) Шаблоны кода (code snippets, см. рис.) По сути, это обычные куски кода, которые раньше хранились в разрозненных файлах или, того хуже, в голове. Теперь все это хозяйство помещается в единое хранилище, откуда извлекается парой кликов.

5) Возможность вычисления выражений непосредственно при редактировании, без компиляции, причем с проверкой синтаксиса и выводом рекомендаций (см. рис.)

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

Теперь рефакторинг стал неотъемлемой частью IDE, так что такие нудные операции, как переименование переменной, класса или объекта, выполняются автоматически. Причем в окошке Preview Changes вы увидите те строки кода, в которые будут внесены изменения. Какие из инструментов рефакторинга войдут в финальную версию продукта, пока не ясно, но в существующей на момент написания статьи демо-версии уже имелись следующие:

7) Раскраска типов и ключевых слов. Теперь текст программы может сиять, как рождественская елка, достаточно настроить раскраску пользовательских типов и ключевых слов.

Безусловно, эти новшества можно считать косметическими, но их появление заслуживает добрых слов. Помимо них есть и другие маленькие радости: IDE научилась автоматически сохранять результаты работы через заданные промежутки времени. Естественно, с предоставлением возможности восстановления при фатальном сбое, что при программировании и отладке более вероятно, чем при банальном наборе. Наконец, модифицирована подсистема поиска (окошко Find and Replace), которая теперь позволяет выполнять поиск в свернутом тексте (так называемый #region). Не остался без внимания и отладчик. Если раньше всплывающая подсказка была активна только для простых (не составных) переменных, то теперь она имеет место и в более сложных случаях: достаточно навести курсор и можно увидеть специальную подсказку (DataTips), демонстрирующую не только значения переменной, но и всю иерархию типа (рис. 7). Следуя современным тенденциям (читай - большим мониторам), появились инструменты для управления все большим числом dock-окошек. Если раньше они скакали, как заправские акробаты, то теперь можно предварительно посмотреть, куда же окно прицепится.

Присвоят ли новой версии Framework полновесную двойку или обойдутся цифирями 1.2, не столь важно, но то, что нововведения здесь действительно значимы, - факт неоспоримый:

Вместе с формой изменилось и содержание - в том смысле, что изменились и сами языки программирования (я приведу лишь список изменений, подробнее читайте на сайте MSDN):

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

Конечно, в Редмонде не могли забыть и сопутствующий продукт - MS Office, который ныне является не только офисным пакетом, но и целой платформой (да простят меня профессионалы за столь вольное сравнение). Нельзя сказать, что появление Visual Studio Tools для MS Office System (VSTO) произвело фурор, однако вынесение его в отдельный продукт говорит о самостоятельности этого инструмента разработки. Автономный продукт, несомненно, удобнее, особенно для неанглоязычных офисных разработчиков. Ведь до недавних пор разработка собственных приложений требовала локализованной версии Office, и это помимо Office Developer, включавшего все офисные приложения и выходившего только на английском языке. К тому же полученные приложения могли не работать при иной локализации. Теперь эти проблемы должны остаться позади.

Если мы заглянем во внутренности VSTO, то увидим, что механизм автоматизации и среда разработки самого Office 2003, как и прежде, базируются на традиционных механизмах VBA и COM. А вот VSTO позволяет создавать DLL-расширения для того же "Ворда" прямо в среде .NET Framework на языках VB.NET или C#.

Однако не "Микрософтом" единым. Обратим взор на продукт конкурента, причем продукт неординарный.

Начну издалека. Жила-была хардверная компания, продающая неплохое серверное оборудование. То ли работы у ее инженеров было мало, то ли они по натуре были затейниками, но в конце концов в их светлых головах родилась идея облегчить создание ПО для самых разных устройств - так появился Java. Все было бы замечательно, вот только новый язык оказался, мягко говоря, непростым. А по сравнению со всякими Visual Basic’ами - вообще неподъемным. Разумеется, нашлись профессионалы, которым он пришелся по душе и которые несут его флаг до сих пор, однако число их не столь велико, как хотелось бы авторам Java. Причин тому множество, но трудность и некая "невизуальность" играют здесь не последнюю роль. Именно для решения последней проблемы и был изобретен Ace (новое название DASL).

В переводе с английского Ace означает очко, выигранное одним ударом в таких играх, как теннис, гольф, гандбол. Это самый быстрый и эффективный способ достичь выигрыша.

DASL (Distributed Application Specification Language)

Язык, включающий в себя несколько подъязыков. BOS - язык описания бизнес-логики: объектов, правил их взаимодействия и поведения и отношений между ними. AUS - язык описания задач, итерационной модели и т. д. ACE - ядро, сердце проекта DASL. Главное назначение ACE - отвлечь внимание от конкретных архитектур, будь то J2EE, .NET, Corba или ODBC. Декларируется, что сопряжение со сторонними уровнями (как нижележащими - веб-серверами, СУБД, так и уровнем выше - серверами бизнес-логики) целиком берет на себя ACE, от программиста требуется лишь описать предметную область. Более того, при смене парадигмы программирования, например переходе от двухзвенной модели (сервер - множество "толстых" клиентов) к трехзвенной (клиент - веб-сервер - сервер приложения), модификация кода происходит почти в автоматическом режиме: порой достаточно выставить другие опции для проекта, а исходный код будет автоматически переписан.

Если отвлечься от маркетинговых реверансов, то DASL может стать таким же важным шагом для Java, как в свое время Delphi стал для Паскаля. Его именно так и называют - визуальным языком программирования. Впрочем, не следует питать иллюзий по поводу визуальности: она не отменяет необходимости ручного программирования, просто при старте программист получает скелет приложения, построенный визуальными методами (см. рис.). В основе основ - моделирование кода в виде бизнес-схем (на самом деле, имеющих не большее отношение к бизнесу, как процессу зарабатывания денег, чем Java к современному балету) и автоматическая генерация исходного кода. Как правило, конструирование программы состоит в своеобразном "рисовании" диаграмм - расстановке блоков и их соединении. Такой подход таит в себе определенные противоречия. С одной стороны, он дает существенные плюсы:

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

С другой стороны, генерируемый код не будет максимально производительным и гибким - в нем останутся стереотипы, заложенные создателями. Спешу заверить поклонников Java, что второго VB (читай - Visual Java для чайников) в самом негативном смысле мы не получим. Код, конечно, немного механистичен, но вполне доступен пониманию, работоспособен и производителен.

В качестве иллюстрации нового подхода приводится занятное приложение по созданию веб-магазина игрушек. Исходный вариант на J2EE, поддерживающий базовый функционал (просмотр каталога, заказ и система его отслеживания, обработка кредиток и пр.) содержал четырнадцать тысяч строк кода и создавался полгода. Дабы продемонстрировать свое превосходство над противником, команда из Microsoft переписала это приложение, породив лишь три с небольшим тысячи строк ручного кода. Естественно, наезд не мог остаться без ответа: используя DASL, один разработчик всего за неделю воссоздал то же самое приложение, написав ручками лишь 224 строки, что должно повергать в шок всех сторонников Microsoft.

Несмотря на, казалось бы, разгромные цифры, этот пример не стоит рассматривать слишком серьезно. Конечно, DASL создавался не для того, чтобы написать именно такое приложение в более короткие сроки, но некоторая некорректность здесь все же есть.

Да, визуальность налицо, но за все надо платить, платить гибкостью и производительностью. К тому же смущает слабая раскрутка - попробуйте в любой поисковой системе найти материалы по Sun Ace. Похоже, проект ведет полулетаргическое существование, но самое удивительное, что даже попробовать DASL рядовому программисту не так-то просто.

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