ReSharper и Roslyn: Q&A

Как уже все знают, MS предлагает «компилятор как сервис» в виде платформы Roslyn. Может быть некоторые из вас ее уже попробовали и составили какое-то первое мнение. После того, как почитаешь внимательнее возможности Roslyn и рассмотрев примеры работы с ним, возникает закономерный вопрос:

Как это будет работать с ReSharper и будет ли он переписан? Когда будет новый решарпер для новой студии?

В предыдущий раз ReSharper появился только в момент выпуска RC или около того, насколько я помню, т.е. достаточно поздно. Как оно будет в этот раз и как будут вместе жить ReSharper и Roslyn предлагается узнать из перевода интервью с разработчиками из JetBrains.

 

После анонса и выпуска Roslyn платформы на последней конференции BUILD, мы в JetBrains немедленно оказались погребены под вопросами о судьбе ReSharper, в смысле будет ли он использовать Roslyn для анализа кода и как они могут вместе сосуществовать. Поток вопросов не иссякнет, пока не будет использоваться единый шаблон для ответов на них:

resharper

Если серьезно, то вполне очевидно, что нам надо решить, как будут взаимодействовать ReSharper vs Roslyn. Этот пост призван ответить на основные вопросы.

Мы провели беседу с Сергеем Шкредовым (@serjic) ReSharper Project Lead и .NET Tools Department Lead и Алексеем Шведовым (@controlflow), Senior Developer в команде ReSharper, который отвечает за функционал генерации кода, аннотации и поддержку языков на базе XML. Дальнейшая секция вопросов и ответов результат беседы с ними.

Какую позицию занимает JetBrains по отношению к Roslyn? Является ли сама технология и ее Open Source статус важным и значимым?

Roslyn определенно очень важный и хороший шаг вперед для Майкрософт, так как это может помочь пользователям Visual Studio получить еще больше преимуществ в редактировании и анализе C# и VB кода, скажем так, в базовой поставке, без дополнительных инструментов.

Это также должно помочь разработчикам расширений для Visual Studio создавать больше плагинов ориентированных на код, используя непротиворечивое API. Появляется возможность глубже понимать как все работает изнутри – спасибо Open Source статусу проекта. Но это не отсылка к хакерам, которые желают провести свое время делая форки исходников с целью получения идеального C#, о котором они давно мечтали.

Мы так же думаем, что Roslyn не менее важен для самой Майкрософт. Они столкнулись с тяжелым бременем поддержки большого числа интегрированных в VS инструментов, таких как: редакторы кода, IntelliTrace, дизайнеры кода. Ребята из Майкрософт заинтересованы в создании более гибких продуктов, с возможностью более простого обновления. Roslyn должен помочь обновлять .NET языки и экспериментировать с ними с невероятной до этого скоростью. Кроме того, старый компилятор не позволяет запускать шаги компиляции параллельно, в то время как мы ожидаем такой возможности от Roslyn, что принесет больше возможностей для масштабирования.

В чем смысл открытия кода Roslyn?

Мы не верим, что открытие исходного кода, было продиктовано ожиданиями Майкрософт свалить разработку компилятора на внешних разработчиков\сообщества. Языки программирования слишком монолитны и сложны для того, чтобы принимать внешние правки независимо от их важности. Поэтому Майкрософт полностью оставит за собой право разработки .NET языков не опираясь на сообщество.

Возможные усилия по модификации отдельных веток компилятора для решения каких-то узкоспециальных задач будут скорее напоминать выстрел в ногу. Даже если стандартный компилятор в Visual Studio может быть заменен на самодельный, инструментальная поддержка для него будет отсутствовать. В теории можно представить себе кастомную реализацию INotifyPropertyChanged на основе специфичной реализации Roslyn, которая получит некоторую популярность. Однако, мы с трудом можем представить поддержку такой версии в ReSharper, так как наше намерение заключается в поддержке только официальной версии Roslyn.

Будет ли ReSharper в дальнейшем использовать Roslyn?

Короткий ответ на этот чрезвычайно популярный вопрос: Нет, ReSharper не будет использовать Roslyn. На это есть как минимум две основные причины.

Во-первых, это количество затраченных усилий которые нам необходимо будет потратить в смысле переписки кода, тестирования и стабилизации. Мы разрабатывали и развивали ReSharper 10 лет и у нас есть зарекомендовавшая себя платформа для рефакторинга и инспекции кода. Во многом Roslyn очень похож на модель, которую мы используем в ReSharper: мы строим абстрактное синтаксическое дерево кода и строим семантическую модель для разрешения типов, которую мы можем использовать для множества инспекций и рефакторингов. Замена такого огромного количества кода займет неимоверное количество времени. Стоит так же принять во внимание риск дестабилизации работающего кода. Лучше посвятить эти усилия на оптимизацию или добавление новых возможностей, вместо того, чтобы следующий цикл релиза отдать на реализацию того, что уже работает.

Во-вторых, причина в архитектуре. Многие вещи, которые возможны в ReSharper не поддерживаются в Roslyn, так как они слишком зависимы от концепций в нашей модели кода. Примерами такого функционала могут служить: Solution-Wide Error Analysis, инспекции кода требующие быстрого поиска наследников, инспекции кода для которых нужен «взгляд с высоты», например, поиск неиспользуемых публичных классов. В случаях, когда Roslyn предоставляет необходимое API, нет уверенности в том, что это делается самым оптимальным образом. Можно рассмотреть случай поиска всех производных типов. В Roslyn это делается простым перебором и проверкой наследования. В модели ReSharper этот функционал включен в ядро и является высокооптимизированным действием.

Модель архитектуры ReSharper концептуально отличается от Roslyn. Это выражается в совершенно разных подходах по обработке и обновлению синтаксического дерева. В отличие от ReSharepr, у Roslyn синтаксическое дерево статично. А это значит, что для любого изменения необходимо построить новое дерево.

Другое ключевое различие заключается в том, что Roslyn покрывает только два языка: C# и VB.NET, — в то время как архитектура ReSharper мультиязычна, поддерживает межязыковые ссылки и не тривиальные смешения, как например Razor. Более того, ReSharper работает с внутренним фреймворком, который может последовательно реализовать фичи для новых языков, которые могут поддерживаться в будущем. Это то, чего Roslyn не имеет по определению.

Будет ли удобно использовать сразу ReSharper и «свистелки» на базе Roslyn в Visual Studio?

Это очень сложная задача, так как мы до сих пор не уверены будет ли возможность отключить фичи основанные на Roslyn (такие как рефакторинг и подсветка) во время интеграции в новые релизы Visual Studio. Если у нас это не получится, будет большое проседание по производительности. Помимо потребления памяти и процессора процессами ReSharper, неизменяемая модель Roslyn так же значительно ударит по трафику памяти. Это в свою очередь приведет к более частому запуску сборщика мусора, что еще больше повлияет на производительность.

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

Roslyn публикует код, какая его часть представляет наибольший интерес для разработчиков ReSharper?

Мы уверены, что будем смотреть код и тесты для Roslyn время от времени, чтобы посмотреть, как реализованы те или иные фичи для C# и VB.NET. Мы не исключаем что текущий код еще сильно поменяется, так как формальные спецификации еще не завершены. Ну и на самом деле мы уже начали изучать код Roslyn.

Это более-менее описывает структуру мира, в котором живет Roslyn, как мы это видим сейчас. С течением времени что-то может поменяться, и мы будем следить, идут ли изменения в ожидаемом ключе.

 

Если возникли вопросы, то можно задать их в оригинальном посте.

 

Оставить комментарий