Все новости от 9 апреля 2002 г.

От кодов — к программе

Среда разработки Visual Studio .Net постоянно пыталась анализировать то, что мы делали, и предлагать нам те ресурсы, которые могли понадобиться на следующем этапе работы. Однако ситуации при этом иногда возникали довольно странные.

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

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

Редактор исходного текста, включенный в Visual Studio .Net, в отличие от такой же утилиты Oracle JDeveloper, не способен передавать данные в разработчик визуальных форм. Когда мы изменяли исходный текст, определивший размер и форму экранной кнопки, Form Designer принимал это во внимание, однако связь между ним и сгенерированным кодом была односторонней. Коды, описывающие управление визуальными формами в Visual Studio .Net, как будто предупреждают: “Не тронь меня!”.

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

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

Не думаю, что мы отнеслись к столь непонятным маневрам чересчур пристрастно. Если подобные проблемы возникают даже тогда, когда взаимосвязи прослеживаются довольно легко, то что говорить о сложных проектах? Я, скажем, не стал бы полагаться на способность Visual Studio .Net отслеживать ход сколь-нибудь нетривиального проекта.

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

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

Для построения визуальной карты схемы, содержащей более 4900 строк текста XML, нашей экспериментальной системе на базе Pentium III с рабочей частотой 1 ГГц понадобилось почти три минуты. Когда же мы начали активно перемещаться по этой карте, загруженность процессора быстро поднялась до 80%, а вентилятор системы охлаждения жалобно взвыл. Прямо скажем: слышать стоны изнывающей от перегрузки машины нам приходится нечасто.

Окно обзора схемы Schema Overview редактора XML при анализе этого файла оказалось совершенно неэффективным. На нем отображалась такая длинная горизонтальная полоса иерархических деревьев, что на каждый элемент карты приходилось не больше одного-единственного ряда пикселов.

Редактирование ординарного исходного текста выглядит в новом пакете так же, как и в прежних средах Visual Studio: его редактор все еще лишен таких удобных функций, которые предлагают программистам KEdit фирмы Mansfield Software Group, Visual SlickEdit фирмы SlickEdit и другие подобные продукты.

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

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

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

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

Но как бы то ни было, медведь все же танцует.

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

С редактором eWeek Technology Питером Коффи можно связаться по адресу: peter_coffee@ziffdavis.com.