.jpg) |
| С. СОМАСЕГАР: «При создании новой версии Visual Studio мы стремились понять, какие новые подходы к разработке приложений сегодня наиболее актуальны» |
Ключевым докладчиком конференции TechEd, которую корпорация Microsoft впервые провела в Москве, стал С. Сомасегар, корпоративный вице-президент по инструментам разработки. Сомасегар, пожалуй, один из самых известных и авторитетных технологических спикеров корпорации, от него участники крупнейших форумов Microsoft и читатели корпоративного блога узнают о деталях ее новейших разработок. Сомасегар, работающий в Microsoft с 1989 года, принимал участие в создании нескольких операционных систем, а сейчас руководит созданием и продвижением инструментов разработки корпорации.
В личной беседе с Сомасегаром удалось узнать из первых рук подробности об основном детище его команды — платформе разработки Visual Studio.
Вы недавно представили новую версию платформы разработки Visual Studio 11. Какие основные усовершенствования в ней сделаны, каким тенденциям в мире разработки и потребностям современных разработчиков они отвечают?
Прежде всего при создании новой версии мы стремились понять, какие новые подходы к разработке приложений сегодня наиболее актуальны. Если представить себе весь спектр современных приложений в виде отрезка, то на одном его конце будут приложения, для которых на первом месте стоят устройства, а на другом — приложения, в основе которых лежит облако. В приложении типа «сначала устройство» подавляющая часть логики работает непосредственно на клиентском устройстве, хотя оно может обращаться к облаку за определенными сервисами или данными. А в приложениях, ориентированных в первую очередь на облако, основная часть бизнес-логики работает в облаке. На устройстве остается только фронтальная часть программы, отвечающая за взаимодействие с пользователем. Промежуточное положение занимает огромное количество приложений, которые используют возможности конкретных локальных аппаратных платформ и устройств, но при этом часть обработки отдают в облако.
Мы работали над тем, чтобы новая версия Visual Studio предоставляла необходимые средства для разработки всех возможных типов приложений — тех, основная часть которых работает на устройстве, тех, которые ориентированы на облако, и приложений, логика которых распределена между устройствами и облаком.
Можно выделить три категории усовершенствований, реализованных в Visual Studio 11. Первая связана с повышением продуктивности труда тех, кто занимается непосредственно кодированием. Программисты проводят в среде разработки огромное количество времени, фактически они в ней живут, поэтому улучшение удобства интерфейса между человеком и системой, предоставление дополнительных возможностей для автоматизации рутинных задач и повторяемых операций очень важно и позволяет значительно повысить производительность труда. В Visual Studio 11 было сделано много улучшений в инструментах кодирования, средствах снабжения кода комментариями, поиска, технологии IntelliSense и т. д.
Второе направление развития Visual Studio 11 относится к дальнейшему совершенствованию средств управления жизненным циклом приложений (Application Lifecycle Management, ALM). Мы уже давно поддерживаем средства ALM в своей платформе разработки, но в Visual Studio 11 сделали огромный шаг вперед. В частности, улучшены средства управления требованиями, тестирования, добавлен целый пакет новых инструментов для повышения продуктивности коллективной работы в Team Foundation Server.
Третья категория улучшений — это поддержка в среде разработки новейших операционных платформ. Идет ли речь о Windows 8, где будет использоваться совершенно новый пользовательский интерфейс Metro, о мобильной операционной системе Windows Phone или облачной платформе Azure, очень важно предоставить все необходимые средства, чтобы можно было из единой среды вести разработки первоклассных приложений, ориентированных на любую из этих платформ.
Определены ли сроки выпуска Visual Studio 11?
Нет, окончательные сроки выхода платформы на рынок еще не установлены. На конференции BUILD в сентябре мы объявили о выпуске ознакомительной версии для разработчиков (developer preview). Мы завершаем работу над функционалом, который планируется включить в эту версию, параллельно решаются задачи оптимизации и обеспечения необходимой производительности разработки. Все это будет представлено в первой бета-версии платформы.
На BUILD были одновременно анонсированы ознакомительные версии Visual Studio 11 и Windows 8. Насколько разработка новой ОС влияет на создание новой среды разработки, что еще в Windows 8, помимо нового пользовательского интерфейса, найдет отражение в средствах разработки?
Влияние очень большое. Мы убеждены в том, что с появлением новой операционной системы необходимо сразу же обеспечить набор ориентированных на нее инструментальных средств. Реализованная в Windows 8 среда исполнения Windows открыта для разработчиков через целый ряд интерфейсов API. Мы должны были сделать все, чтобы предоставить средства разработки для создания современных приложений, которые с помощью этих интерфейсов смогут использовать все новые возможности, предлагаемые этой операционной системой.
Пользовательский интерфейс — важная часть платформы, и ее необходимо учитывать при разработке приложений, но само приложение пользуется гораздо более широким набором возможностей операционной системы. Перед нами стояли две важные задачи. Во-первых, обеспечить разработчику возможность писать на максимально большом количестве языков программирования. Вторая задача — дать необходимый инструментарий для использования всех тех API, которые предоставляет платформа.
Мы уверены, что синхронизация между инструментами разработки и платформами абсолютно необходима. Например, недавно Microsoft выпустила новую версию мобильной операционной системы Windows Phone 7.5, и одновременно с ней вышли инструментальные средства, позволяющие разработчикам писать программы, ориентируясь на максимум возможностей этой платформы.
Если вернуться к спектру приложений, о котором вы говорите, то в нем преобладают две ключевые тенденции современных ИТ — широкое распространение мобильных устройств, в том числе в корпоративной практике, и все более активное использование облачных технологий. Ставят ли эти две тенденции новые проблемы перед разработчиками?
Здесь можно выделить несколько моментов. Независимо от того, о разработке каких приложений идет речь — ориентированных на устройство, ориентированных на облако или гибридных, все эти приложения так или иначе в определенный момент будут обращаться к облаку. Поэтому практически перед всеми разработчиками встает вопрос, как оптимально организовать процесс взаимодействия с облаком и воспользоваться теми возможностями, которое облако предоставляет.
Далее, надо помнить, что программисты обладают той особенностью, что, как правило привыкнув работать в рамках определенной модели программирования или с определенным языком, они стремятся придерживаться этой модели и этого языка. Мы считаем, что очень важно предоставить разработчикам свободу выбора, дать возможность справляться с новыми задачами, используя тот язык, который им нравится, и ту модель программирования, которую они считают для себя оптимальной. Поэтому, например, на платформе Windows 8 разработчики могут писать на любом языке, будь то C#, Visual Basic, среда. Net или С++, или, если они предпочитают работать с моделью веб-сервисов, использовать HTML5 или JavaScript.
Если вернуться к проблеме учета возможностей облака и устройств при разработке, то мы, конечно, понимаем, что в руках пользователей сейчас находятся мобильные устройства не только на платформе Windows. Поэтому мы разработали специальные наборы инструментов Azure Toolkit, ориентированные на наиболее известные сегодня мобильные операционные системы — Windows Phone, iOS, Android, с тем чтобы любой разработчик, независимо от того, на какую платформу он ориентируется, мог с легкостью реализовать функции, которые позволят его приложению подключаться к облаку.
Хотелось бы отметить еще одну тенденцию, она связана с тем, что разработчики сегодня испытывают огромную потребность в инструментах, способных помочь им максимально эффективно использовать новые возможности современных аппаратных ресурсов как устройств, так и облака. В частности, очень важным становится параллельное программирование, позволяющее более полно раскрывать потенциал многоядерности, графических процессоров с параллельным исполнением процессов. В Visual Studio 11 сделано многое для того, чтобы расширить возможности параллельного программирования, в том числе реализованы поддержка асинхронных процессов в C# и Visual Basic, библиотека Task Parallel Library, средства распараллеливания обработки данных, ориентированные на графические процессоры.
Недавно Microsoft рассказала о проекте Roslyn по созданию «компилятора в виде сервиса». Насколько я понимаю, речь не идет о компиляторе в облаке по аналогии с IaaS, Paas и SaaS? Поясните, пожалуйста, в чем суть этой идеи и какие преимущества она обеспечит разработчикам.
Нет, это не компилятор в облаке, суть проекта в другом. В настоящее время для большинства разработчиков компилятор представляет собой «черный ящик». Вы подаете ему на вход текст программы, внутри компилятора высокоинтеллектуальные алгоритмы непонятным вам образом обрабатывают введенный код, а на выходе вы получаете набор исполняемых модулей. Мы давно занимаемся созданием компиляторов, прекрасно понимаем, как они работают, и потому подумали, что было бы классной идеей применить свое знание этих технологий и создать ряд интересных расширений среды разработки, которые помогли бы лучше понимать код. В рамках проекта Roslyn мы полностью переписываем компиляторы C# и Visual Basic, с тем чтобы все те знания и интеллектуальные процессы, которые в компиляторе заложены, открыть и предоставить в виде сервисов разработчикам. Благодаря наличию таких сервисов разработчик сможет воспользоваться интеллектуальными алгоритмами компилятора и, основываясь на более глубоком понимании кода, создавать расширения других инструментов разработки.
Мы только что анонсировали Roslyn CTP, и я хочу подчеркнуть, что разработки проекта Roslyn не войдут в Visual Studio 11. Понадобится еще значительное время, прежде чем проект Roslyn приведет к каким-либо конкретным результатам. Первая задача состоит в том, чтобы переписать компилятор, открыть языковые сервисы, а затем наступит черед разработчиков, которые начнут делать расширения интегрированных сред разработки (IDE), и мы сможем получить от них обратную связь для окончательного завершения проекта. В конце концов Roslyn станет частью нашей платформы разработки, но это произойдет не в версии Visual Studio 11.
Но если вернуться к возникающей в связи с Roslyn ассоциации с предоставлением компилятора как облачного сервиса, то на самом деле мы постоянно думаем над тем, какие средства можно предложить разработчикам в облаке в дополнение к тому, что они имеют в Visual Studio как клиентской системе. Если эта клиентская программа будет иметь возможность работать с облачными сервисами, можно будет построить для разработчиков максимально удобную среду. Первым шагом в этом направлении стала реализация хостинга для сервера коллективной работы Team Foundation Server на платформе Azure.
Далее мы будем расширять набор предоставляемых в облаке дополнительных сервисов, они будут помогать разработчикам на Visual Studio, независимо от того, какую модель приложений из упомянутого выше спектра они применяют.
Недавно мне представилась возможность беседовать с очень известным специалистом в области программной инженерии Бертраном Мейером. Он уделяет большое внимание практическому применению формальной верификации программ для обеспечения их качества и, в частности, приводил пример Microsoft Research, где ведутся работы в этом направлении. Планируете ли вы включать в будущие версии Visual Studio инструменты верификации или другие новые средства для повышения качества разработки?
Да, конечно. Прежде всего хочу сказать, что уже в Visual Studio 2010 входят средства разбора кода (code understanding). Но там они применимы только к разработке в среде. Net, а в Visual Studio 11 их можно будет использовать для программ на С++ и др.
Вообще, если говорить о средствах обеспечения качества ПО, то их можно разбить на две крупные категории. В первую входят инструменты проверки качества на этапе разработки, до того как будет готов конечный продукт. Вторая категория охватывает средства, которые используются, когда выявляется проблема в ходе эксплуатации и надо найти ее причины и принять меры для устранения. У нас есть инструменты для обоих сценариев. Если в комплексе рассматривать и средства разбора кода, и средства автоматизации тестирования Visual Studio, то вы получаете в свое распоряжение полный набор инструментов для обеспечения качества продукта от разработки до эксплуатации.
Когда речь идет о выявлении проблем с программным продуктом, уже введенным в эксплуатацию, то здесь одна из типичных сложностей заключается в следующем. Если возникает проблемная ситуация, разработчик не может сразу определить, в чем причина, ему необходимо воспроизвести условия работы программы и уже на воспроизведенном образце провести отладку. Мы же в Visual Studio предлагаем функционал под названием Intellitrace, который позволяет фиксировать и сохранять состояние системы непосредственно в режиме эксплуатации. Это дает возможность при возникновении проблемы провести отладку того, что происходило в системе, так же, как если бы это делалось на специальном тестовом стенде, без остановки работы «боевого» приложения.
Для верификации программ на этапе разработки уже сегодня в составе Visual Studio поставляются специальные инструментальные средства Prefix и Prefast, появившиеся в результате тесного сотрудничества между моим подразделением и исследователями Microsoft Research. По мере прогресса в работе по анализу программного кода мы вместе с Microsoft Research сможем реализовать более мощные возможности соответствующих инструментов. Есть такое выражение: «Лучшая ошибка — та, которой никогда не существовало». Чем больше мы сможем предоставлять средств, которые позволят выявлять проблемы на возможно более ранних этапах разработки, тем более эффективной будет разработка. Именно поэтому мы делаем акцент на средствах анализа кода, на том, чтобы они были в руках у каждого архитектора, каждого разработчика, так чтобы с помощью этих аналитических инструментов они могли выявить все недочеты своей работы и устранить проблемы еще до того, как программа перейдет на другие этапы разработки.