Привет, это снова Без слайдов. Я Алексей Федоров, и на этот раз в гостях у меня побывал Сергей Шкредов, руководитель всего .NET-направления в компании JetBrains.



С Сергеем мы говорили:

• о последних релизах ReSharer;
• о новой схеме подписок и лицензий;
• про непростые отношения с Microsoft;
• о рантайме и развитии языка;
• о том, как поменял ситуацию выход Roslyn;
• о работе с фидбеком пользователей для улучшения продукта;
• о планах развития других продуктов .NET стека;
• о важности внутриотраслевого общения и обмена опытом;
• про разработку продуктов для С++;
• немного о ReSharper C++, на который должны подсесть даже разработчики Microsoft;
• О том, как пользователи почувствуют изменения;
• Как ReSharper будет развиваться дальше.

Вот видео



Под катом — текстовый вариант интервью.

О новых релизах ReSharer и Update Rate

—Сергей, у вас недавно был большой релиз, даже два.

— Да.

— Ты можешь мне немного рассказать, что у вас там нового в новом ReSharper? Так, очень коротко. И, собственно, почему релиза было сразу два?

— За предыдущий год мы сделали три больших релиза — это ReSharper 9.1, 9.2 и 10.0. И мы на этот год взяли себе такой темп — делать релизы раз в четыре месяца, и в каждом релизе не прятать фичи, выпускать всё как можно раньше. Это лучше соответствует тому, как развивается Visual Studio — там происходят все время какие-то новые события. И с этой точки зрения релиз 10.0 мало чем по количеству фич отличался от релиза 9.2. Единственное, что на этот релиз у нас было строгое ограничение: мы вместе с выпуском всех продуктов меняли систему лицензирования всех наших IDE, поэтому дата релиза была зафиксирована задолго до этого релиза. Собственно, из-за зафиксированной даты релиза получилось два.

— То есть, это был багфикс?

— Да, багфикс-релиз, который вышел через две недели после 10.0.

— Много багов пофиксили?

— Много, порядка сотни. В основном, конечно, пользователи жаловались на Unit Testing и плохой резолвинг UWP-приложений.

— Ну сейчас пользователи уже успокоились? Все в порядке?

— Сейчас уже да. На самом деле следует смотреть не на то, что пишут в Твиттер, а на update rate (процент людей, которые перешли на новую версию), то он в два раза лучше, чем был для ReSharper 9. То есть, за первые три недели существования ReSharper 10 на него проапдейтилось в два раза больше людей, чем год назад.

— А много вообще по вашим данным людей пользуется старыми версиями?

—Я думаю, нет. То есть, к моменту релиза следующей версии предпоследней версией пользуется порядка 30%, а 70% людей уже на новой сидят. И готовы перейти на следующую, самую новую, версию.

—То есть сейчас есть 30% которые пользуются ReSharper 8?

— Да.

— Понятно. А вы как-то пытались с ними общаться, понять, почему они не хотят переходить?

— Я думаю, что это нормальное распределение такой активности разработчиков. И это мало связано с какими-то внутрепродуктовыми причинами.

О хитрой схеме подписок и лицензий

— Старая лицензия — она была по времени или она была по версии? Я мог, имея ту лицензию, бесплатно проапгрейдится?

— Где-то около двух–трех лет назад мы стали продавать подписки, которые позволяли в течении года обновляться на любую версию. Покупаешь, и у тебя в течение года есть все версии, которые мы выпускаем, вне зависимости от того, как мы их называем. Таким образом мы отвязались от версионирования, что есть это позволило нам выпускать более частые релизы, не опасаясь за то, что мы не получим достаточный Upgrade Rate на мажорной версии. Ну и для коммерческих пользователей у нас еще оставались perpetual (бесконечные по сроку действия — прим. автора) лицензии без подписки на обновления. Сейчас такие лицензии уже ушли. Я могу, конечно, прокомментировать новую подписочную схему.

— Да, расскажи, пожалуйста. У вас всё еще раз изменилось, об этом много писали и говорили. Ты можешь коротко подытожить, что в итоге получилось. Мне кажется, это будет для наших зрителей не лишним.

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

Соответственно, когда мы это поняли, мы ввели подписки. Подписки всем хороши, но подписка – это штука, которую ты должен обязательно себе купить. То есть ты покупаешь себе perpetual-лицензию и к ней подписку. Мы к этому не сразу пришли. Мы на самом деле разделили сейчас плату за подписку на год вперед, и плату за perpetual-лицензию.

Первый наш вариант схемы подписочной был такой: вы покупаете лицензию на год, и через год у вас все отнимают. И мы, конечно, встретили массу негативного фидбэка по этому поводу. Я думаю, это заслуга большая наших маркетологов, наших СЕО, что среди всего этого фидбека мы смогли понять, что именно в этой ситуации волнует пользователей. А пользователей волнует отсутствие гарантий того, что они смогут продолжить пользоваться продуктом.

Например, были компании, которые явно писали нам, о том, их бюджет утверждает, например, конгресс Соединённых Штатов. И если он не утвердит бюджет на обновление версии, мы просто на следующий год останемся без продукта. Это самая показательная, думаю, история, которая помогла понять, что надо оставить perpetual-лицензию.

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

— Если не купишь, то что происходит?

— Тебе придется пользоваться через год той версией, которую ты купил.

—То есть происходит откат назад, на версию, актуальную в момент покупке?

—Да. Можно рассматривать это как откат, а можно рассматривать как то, что ты в течение года принимаешь решение о том, что «я хочу новую». И в таком случае платишь через год, когда продляешь подписку.

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

— Компания Adobe. Но там история проще, конечно. Мы много слушаем пользователей, и из-за этого наши решения иногда становятся иногда сложнее.

— Окей, ну-то есть довольно уникальная история.

— Я могу привести еще больше примеров. Два дня назад Microsoft перешел на такую же схему.

— Интересно.

— Абсолютно на такую же. Причем на эту тему не было ни единого большого поста в интернете.

— А как так вышло? Почему в вашем случае были обсуждения?

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

—То есть можно сказать, что ваш продукт-менеджмент живет фидбеком?

— Да, в большой степени.

Про непростые отношения с Microsoft

— А какие у вас вообще отношения с Microsoft? Сам я — человек из мира Java, а там довольно давно, уже лет десять как, платформа более-менее открытая. Разговаривая с ребятами из JetBrains, я понял, что они в принципе хорошо осознают, что происходит внутри самой Java-платформы и могут в любой момент посмотреть любой сложный код, разобраться, даже что-то где-то попатчить.

— Там не нужно коммуницировать с вендором.

— Именно. А у вас, в .NET-мире, как это происходит?

—То, как мы работаем, как мы планируем наши релизы, сильно поменялось за последние несколько лет. И поменялось из-за того, что поменялось отношение Microsoft к экосистеме, к работе с партнерами, к уровню открытости компании. Три года назад ситуация была такая: были приватные билды Visual Studio, которые выдавались только партнерам — была партнерская программа, по которой мы тесно коммуницировали с Microsoft. Мы имели право сабмитить более приоритетные баги на Visual Studio.

То есть Microsoft целенаправленно поддерживал избранных производителей расширений для Visual Studio, порядка ста или двухсот компаний, и для этого были всякие приватные программы. Сейчас большинство фидбека, большинство изменений и билдов можно получить абсолютно легально через открытые источники, а большинство команд с которыми мы общаемся, разрабатывают в Open Source. Сейчас всё меньше и меньше Visual Studio становится закрытым продуктом, который требует достукиваться до Microsoft для того, чтобы принести фидбэк, или что-то поменять, или что-то узнать новое.

—Получается, что многие вещи вы стали делать самостоятельно?

— Visual Studio Industry Partner (VSIP) Program, можно сказать, перестала быть каким-то большим бенефитом для нас. Мы ездим на мероприятия, где можно пообщаться с командой, и это практически единственная просьба от VSIP Program.

— А почему они так изменили свой подход, как ты думаешь?

— Они стали терять разработчиков. Microsoft долго был вендором, который представлял инструменты для разработчиков, которые покрывали все нужды для всех сценариев. С появлением мобильных платформ все изменилось. Инструментария Microsoft стало не хватать, чтобы клиентам Microsoft свои программы писать под Android, под iOS. Это первая причина, которая запустила этот сдвиг.

Второй, наверное, фактор, который повлиял на открытость, это наверное, Azure. Чтобы затащить как можно больше разработчиков, причем не только .NET, а Java, Python, PHP, Ruby — всех разработчиков в свой Cloud, нужно представлять им инструменты. Есть четкая политика — инструменты для разработчиков Microsoft предоставляет сейчас условно бесплатно. Хотя есть случаи, когда не бесплатно (например, Visual Studio), а есть случаи, когда далеко не бесплатно (например, Visual Studio Enterprise). Хотя 6000 долларов это не 14000 долларов, как она стоила год назад.

— Год назад и рубль был другой. А вот, допустим, приход в Microsoft нового СЕО год назад повлиял ли на ситуацию?

— Я думаю, что сильно повлиял, и он в таком смысле продолжил, дал дальше делать инструменты для разработчиков более открытыми. И двигаться в сторону того, что Microsoft – это облачный провайдер и будет укреплять эту свою позицию. Развивать именно экосистему на базе тулов Microsoft, экосистему разработки под все платформы.

— Была еще очень интересная история, связанная с кросс-платформенностью. Вот есть Mono, который под Linux, и есть что-то в этом месте от Microsoft, которая как-то будет конкурировать. Ничего про это не знаешь?

— С Mono история такая, что это как раз та самая дырка в стеке технологий Microsoft, про которую я говорил. Так же как дела обстоят: в Microsoft приходит клиент с тремя тысячами лицензий на Visual Studio, говорит: «нам нужно программу под iOS писать. Я сижу на ваших инструментах уже 10 лет, что мне делать?» Обращается к консультанту Microsoft, и тому нужно дать ответ. Поэтому у Microsoft есть бизнес-задача – обеспечить разработку под iOS.

Соответственно, какие есть варианты? Есть Xamarin, вполне работающая штуковина, есть Apache Cordova, есть нативная компиляция С++ под разные устройства. Вот три инструмента, которые будем развивать, для того, чтобы покрыть этот сценарий. То есть кроссплатформенная разработка — это такое затыкание дырок с помощью внешнего партнера.

Обычно в Microsoft это так происходит, что сначала они затыкают дырки с помощью внешнего партнера, потом сами выпускают продукт и занимают это место. Но сейчас я не вижу таких тенденций, не вижу, чтобы Microsoft пытался бы перетянуть кроссплатформенную разработку к себе. Пока они на стадии кооперации находятся. Те библиотеки, которые написаны на Mono, подтягивают к себе. Core CLR, виртуальные машины, какие-то элементы фреймворка…

—То есть это взаимный процесс?

– Да, это сейчас очень взаимный процесс. Я надеюсь, конечно, что оно унифицируется в какой-то точке.

—Сейчас у них есть собственная реализация виртуальной машины .NET под Linux. Довольно сырая, так?

— У нее есть шанс стать нормальным продуктом.

— Но Microsoft об этом рассказывает как о готовой экосистеме, как будто это готовый продукт, бери и пользуйся. Видимо, это не совсем так?

— Чтобы пользователей на него перетащить, его нужно так позиционировать. Я не вижу перетекания пользователей с классического ASP.NET на ASP.NET на базе Core .NET. Просто еще не готовы. Я думаю, что это будет происходить, но не сейчас. Сейчас есть проблемы с перетаскиванием своего кода.

Дело в том, что сейчас есть существенные проблемы на пути к перетаскиванию своего кода под DNX, под .NET Core. Они связаны с отсутствием вышедшей в релиз версии фреймворка, под который ты можешь таргетить свои библиотеки, чтобы они работали и в классическом ASP, и под полный .NET фреймворк, и в Core CLR. Для этого у Microsoft существует много версий .NET: есть Silverlight в браузерах, есть Windows Phone, есть Desktop-приложения, есть «полный» .NET Framework.

Сейчас появился еще один стек — Core CLR. И в принципе, как отдельная реализация, он ничем не отличается от всех остальных. У Microsoft есть решение для того, чтобы писать код под разные стеки. Эдакий хак, который для каждого варианта сочетаний этих платформ умеет генерировать код, работающий именно на трех или двух из них.

Это не очень работающий сценарий, потому, что количество таких сочетаний растет, грубо говоря, экспоненциально. Сейчас Microsoft активно работает над тем, чтобы от этой экспоненты избавиться и сделать платформу, которую ты можешь таргетить. Чтобы код, который таргетит эту общую платформу, работал у тебя везде. Тогда появятся обновленные версии NuGet-пакетов, которые ты можешь использовать везде и компилировать их подо все, используя одни и те же библиотеки.

— Это у них получается, но, видимо, не очень быстро. Да?

— Очень много дизайн-решений меняется буквально на глазах. Сейчас та версия, которая есть, она не является финальной, Microsoft уже работает над другой версией.

О рантайме и развитии языка

— Насколько, по-твоему, .NET — это legacy-технология, насколько это живая технология? Я сейчас объясню свой вопрос. До какого-то момента, может быть, года до 2008-го, было очень мощное развитие языка. Про Runtime я не могу сказать, мне не хватает экспертизы. Мне кажется, Runtime не очень сильно продвигается вперед. А вот язык в то жесамое время очень сильно развивался. C Java — прямо противоположная история, там язык очень долго тупил, а Runtime развивался дикими темпами. Интересно, что, по моему ощущению, в последнее время с C# тоже ничего глобального не происходит. Изменения были раньше более заметны. Как ты считаешь?

— Совершенно верно. Я думаю, что Runtime отстает от JVM очень сильно. Виртуальная машина в .NET обладает очень плохим сборщиком мусора и очень слабым JIT-компилятором. В итоге получается медленно исполняющийся код, в котором приходится вставлять затычки на затычки, чтобы избежать лишних аллокаций и справиться с теми функциями, которые автоматически не инлайнятся. Код автоматически не оптимизируется на должном уровне. В Java такой проблемы нет.

— А язык?

— Был период, когда язык мало развивался — до выпуска C# 6. Он связан с переходом на новый компилятор Roslyn, который задержался на несколько лет. Года на два, по ощущению.

— То есть, язык не развивался примерно версии с третьей или четвертой?

— С пятой. Пятую версию выпустили, а потом начали писать новый компилятор. Писали его долго и мучительно. В основном, пытались достигнуть той же производительности, которая была в нативном компиляторе, при условии всех архитектурных улучшений.

В итоге заданной цели достигли в режиме компиляции. То есть, когда сейчас С# 6 и C# 5 используешь — Разница в скорости не заметна. По сравнению с остальными этапами сборки компиляция не стала занимать больше времени.

А вот с точки зрения поддержки в IDE — налицо массивный провал. С точки зрения поддержки C# 6 в Visual Studio 2015 — это полный fail. Мы не можем редактировать проект ReSharper Visual Studio в релизе 2015 без ReSharper. Оно выжирает всю память, виснет и все. Такая ситуация.

— Да, это довольно интересно. Особенно на первых этапах, когда вы увидели первые билды, наверно, были бурные эмоции. Как вы жили с этим?

— Волосы дыбом вставали.

— Да. Понятно, что в какой-то момент вы, видимо, там все мажорные проблемы пофиксили и как-то дальше смогли хотя бы внятно с этим жить?

— Сейчас мы поддерживаем Visual Studio 2015, грубо говоря, с закрытыми глазами. Мы сами ей не пользуемся. Планируем переезд потихоньку на нее, там в апдейте стало получше. Мы порезали ReSharper так, чтобы можно было кусочками его запускать. Мы создаем меньшие Solution’ы, чтобы можно было начинать всем этим пользоваться.

— У IntelliJ IDEA, с точки зрения восприятия ее как инструмента, случился колоссальный прогресс в 2007 году, сразу после выхода на рынок процессоров Core 2 Duo. Был очень сильный (по сравнению с Pentium D) performance-рывок. Соответственно, IntelliJ IDEA из положения «IDEA тормозит» перешел в положение «О, IDEA— отличный инструмент. Теперь можно работать!» IDEA стала работать быстрее просто потому, что железо резко стало лучше. Этого хватило. С тех пор люди на производительность IDEA особо не жалуются. Правильно я понимаю, что в .NET стеке производительность IDE— это все еще головная боль?

— К сожалению, да. Мы находимся в довольно тяжелом положении. У нас примерно половина багов с производительностью вызваны работой Visual Studio, а вторая половина — вызвана нами. Мы очень часто не можем отличить одни от других. Может быть, в ReSharper typing происходит медленно, потому что сейчас в бэкграунде Roslyn анализирует файлы и аллоцирует сотни мегабайт в секунду, отчего просто GC помирает?

Когда ты находишься «как бы внутри своего кода», Microsoft сделал некоторые оптимизации специальные, которые учитывают то, как typing в IntelliSense взаимодействует с фоновым анализатором кода. Соответственно, когда мы запускаем наши активности по автодополнению и type assist, мы влияния на то, как работает Roslyn background thread, не имеем.

— Они намеренно так сделали?

— Я думаю, что они решали свою проблему. Конечно же, о нас они не думали. Это естественно.

О том, как поменял ситуацию выход Roslyn

— А насколько выход Roslyn изменил положение дел? Это для вас головная боль?

— Нам стало полегче. Дело в том, что мы лучше стали понимать разные виды проектов, в которых Roslyn используется как Language-сервис. Мы оттуда вытаскиваем модель компиляции, файлы, референсы, идущие в компиляцию. В предыдущих версиях Visual Studio, когда не было Roslyn, это был довольно трудоемкий момент, связанный с вызовом билда, вытаскиванием референсов из Visual Studio напрямую. Это было сложно и с багами. Сейчас это гораздо более прямой процесс. Мы используем Roslyn для того, чтобы создать модули и то, как они будут взаимодействовать с компилятором.

— А как Visual Studio взаимодействует с компилятором? Студия использует для построения собственной модели кода сам компилятор?

— Visual Studio — да. In process загружает Roslyn.

— А в старом случае?

— В старом случае было тоже самое, только в нативном коде на С++. Можно было только догадываться, что он делает и где. Но он не влиял на Garbage Collector никак, мы его не видели никогда в профайлерах. Он, может быть, там был, но он был очень быстрый.

— Связано ли это с тем, что Roslyn — это еще сырая технология? Или связано с тем, что она как-то в корне неправильно спроектирована?

— Да, конечно. Очень сырая. В плане оптимизации конструктора данных, который используется в Roslyn для простейшей функциональности Rename или при нахождения ошибок во всем Solution’е — это прямые алгоритмы, которые тупо работают. Но, понятное дело, влияют на производительность в конце концов.

— То есть, в принципе, шанс того, что разработчики Microsoft ускорят Roslyn, есть?

— Шанс есть, конечно. Но может возникнуть проблема с компанией Microsoft, где такая необходимость может быть не осознана на должном уровне. И не будут выделятся время, и деньги на это.

— Понятно. А тот Open Source, который сейчас происходит, он Open Source только с точки зрения «я могу посмотреть» или «я могу законтрибьютить»?

— Контрибьюшенов я видел очень мало. Сейчас, в основном Core CLR, это все такой показанный исходный код, который ты можешь скомпилировать или просто посмотреть, почитать. Я не слышал, чтоб их массово кто-то принимал.

— То есть, в принципе шансов, что вы придете и поможете им, пофиксите им все проблемы с перформансом, тоже не очень много, судя по всему?

— Эти проблемы с перформансом часто лежат в области компиляции студии именно с Roslyn. Шанс на то, что мы придем и будем в Roslyn что-то изменять есть, конечно. Мы смотрим, анализируем, что и как происходит. Мы имеем представление об архитектуре, об архитектурных проблемах.

Как ReSharper будет развиваться дальше

— Значит, Roslyn строит свою собственную модель, свое собственное дерево, да? Это, видимо, что-то типа Concrete Syntax Tree.

— Да. Очень специфичное, с пробелами, с комментариями… Конкретный синтаксис, так, как он написан в редакторе. То, что в IDE используется — это очень конкретное синтаксическое дерево, ни в коем случае не AST.

— Вы строите модель кода. У вас это свое дерево?

— Да.

— А у Roslyn — своё. Видимо, студия пользуется им — это логично. Собственно, как вы с этим живете? Как вы с этим будете жить дальше?

— У нас сейчас есть несколько направлений. Первое — это не использовать Visual Studio. Второе — это использовать Visual Studio, но запускать ReSharper отдельным процессом. У нас есть видение, есть дизайн, решение, когда все ReSharper’овские модели кода, все синтаксические деревья, индексы, кэши и все, что касается семантической модели, хранится в отдельном процессе.

— Мы с Кириллом Скрыганом это обсуждали, когда он рассказывал, что ReSharper сильно упирается в ограничение по памяти 32-битной Visual Studio. Я ему сказал, что очевидно тогда делать ReSharper out-of-process, на что он ответил, что да, надо, но это чревато Memory Traffic’ом.

— Собственно, дизайн-решение заключается в том, чтобы минимизировать этот Memory-Traffic. Работает это примерно так: мы можем воспринимать студию как UI-приложение. То есть, сделать MVVM. Можно рассматривать, что бэкэнд ReSharper’а — это такая ViewModel для студии, которая является View. Если рассматривать трафик между ними, то это будет трафик тех данных, которые достаточны для того, чтобы отобразить изменения в UI. Ты никогда не найдешь массированную пересылку данных на уровня UI. Всегда надо применять два символа, две подсветочки…

Это все живет на стороне студии, на стороне UI. Данных, которые нужно пересылать для того, чтобы отобразить UI, мало. Тысячи объектов переслать — это мгновенно. Переслать изменения в документе при тайпинге — тоже мгновенно. На этой идее можно так построить код, чтобы синхронизировалось только те данные, которых достаточно для отображения UI.

— Насколько Visual Studio хорошо спроектирована, насколько она позволит вам это сделать?

— Это исключительно вопрос нашего кода, то есть интеграция наша со студией никак не поменяется.

— Ты очень красиво все описал. А в реальности это заработает? Visual Studio позволит вам всю работу с UI куда-то вытащить?

— Этот вопрос написания наших элементов UI. Давайте приведем пример. Вот, например, показывается «бульбочка». Для того, чтобы показать ее, сейчас используется PSI, синтаксические деревья, документы, вся проектная модель. Если мы оставим то, что есть и будем пересылать эти синтаксические деревья целиком – то это, конечно, никуда не взлетит. Но вообще, чтобы нарисовать «бульбочку», нам нужны иконка, текст и все.

Когда мы нажали Alt + Enter, мы передали item в виде текста и иконы, когда мы нажали «применить какую-то бульбочку», мы на бекэнд, который работает out-of-process, отослали на исполнение одну команду. Все изменения данных в синтаксических деревьях и документах – они все произошли Out-of-process. Теперь на фронтенд в качестве результата нужно вернуть новое положение курсора и поменять те документы, которые были открыты в редакторах. И всё.

— Задача сводится к тому, чтобы разработать протокол обмена данными между ReSharper’ом и тем, что видит пользователь на UI, причем минимальный по трафику.

— У нас есть наработки по протоколу. Протокол очень интересный, реактивный. Мы синхронизируем одинаковую структуру данных, которая будет работать с обеих сторон. Это большое изменение — нужно изменить весь исходный код ReSharper’а.

Это изменение заключается в том, что ViewModel надо переписать так, чтобы они не держали в себе ссылки на сематические модели кода. Это огромное изменение, поэтому придется делать его постепенно. Мы потихоньку начнем делать так, чтобы наш продукт работал и так и так. И будем архитектуру приводить к тому, что UI не будет зависеть от семантической модели. И это опять инверсия зависимости.

О том, что как пользователи почувствуют изменения
— Насколько для пользователей это будет прозрачным?

— В конце концов, это должен быть тот же самый User Experience.

— Пользователь не должен ощущать, что бэкенд другой у всей этой истории?

— Конечно. В какой-то момент мы подменим старый новым. И всё.

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

— Конечно. В ReSharper сейчас кода, который непосредственно парсит, резолвит что-то —порядка 10%.

— Насколько имеет смысл вообще заниматься всей возней c Visual Studio, учитывая, что у вас в компании офигенный опыт и очень успешный спрос по построению собственных IDE?

— Visual Studio, конечно, имеет смысл, с нее мы никуда не слезем. Это инструмент, который обеспечивает разработку на всех платформах, которые нужны для Microsoft. Он меняется раз в три месяца и поддерживает новые платформы от Microsoft. Повторять эту работу — вовсе не наш приоритет.

В первую очередь нужно понимать, что Visual Studio решает внутренние задачи Microsoft. Вот, например, вышла Universal Windows Platform, а под нее нужно все программы дебажить, запускать, профилировать, настраивать проекты, которые будут работать под разные платформы… Это мы повторять не будем.

Немного о ReSharper C++, на который должны подсесть даже разработчики Microsoft

— Пользуются ли разработчики Microsoft, которые все это делают, ReSharper?

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

— Значит, разработчики Microsoft заинтересованы в том, чтобы ReSharper работал и развивался. Наверное, это очень большое подспорье — если вы их подсадили на ваш инструмент.

— А сейчас хотим подсадить их на ReSharper C++ — это наша большая цель.

— А расскажи, пожалуйста, об этом проекте.

— Начали мы писать ReSharper С++ года 3-4 назад. Зарелизили весной. Мы его продаем как отдельный продукт, такой фигурно выпиленный язык C++ без всего остального. Из тех, кто пользуется ReSharper C++ — примерно 2/3 пользуются им без ReSharper, а треть ставит себе ReSharper C++ в составе ReSharper Ultimate.

— Насколько вообще люди, которые пишут на C++ под Windows, пользуются именно Visual Studio?

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

— Это именно Managed С++ или любой?

— Managed С++ — это абсолютно тупиковая ветвь развития технологий Microsoft, которая была призвана упростить интеграцию Managed кода с не-Managed кодом.

— А,-то есть нужно было как-то С++, что бывают там какие-то

— Просто сделать маршаллинг, сделать взаимодействие проще. Когда у тебя есть header, описанный для С++, ты его можешь прямо использовать в Managed С++ проекте — это удобно. Я вижу, что сейчас большинство людей которым нужен interop, используют либо COM, либо Implicit PInvoke. Наш опыт использования Managed C++ скорее негативный — в компиляторе баги и пр.

Возвращаясь к твоему вопросу, люди используют Visual Studio не для Managed C++, а для нативного С++ — это разработка под различные устройства, картографические приложения, игры и т.д. — в общем, для всего, что на C++ пишется.

— Можно сказать, что для программирования на C++ под Windows Visual Studio — это основной инструмент разработки?

— Конечно. Да и не только под Windows. Люди, которые программируют под Linux, тоже очень часто сидят в Visual Studio — и это нормально. Просто это хороший редактор.

Про разработку других продуктов для С++

— У меня есть вопрос, связанный с разработкой других ваших продуктов для С++, в частности CLion — от ведь тоже поддерживает С/C++. А есть еще AppCode для Objective-C. Как ReSharper живет параллельно с этими IDE? Есть ли что-то общее в этих продуктах? Обмениваетесь ли вы опытом с разработчиками этих IDE?

— Мы ориентируемся на две вещи. Во-первых, на стандарт языка C++, а во-вторых — на компилятор Microsoft. У CLion и AppCode приоритеты немного другие. Опытом c ними мы обмениваемся. Есть довольно много дизайн-решений, которые плавно перетекают в CLion из ReSharper. Когда начинали писать ReSharper C++ — уже был опыт написания ReSharper C++ в CLion.
Вообще, С++ в AppCode начался абсолютно фееричным образом. Там был Objective C, и в какой-то момент мы поняли, что там есть header-файлы, которые используются и для Objective C и для С++. То есть там где-то под define'ами написаны большие конструкции на С++, на которых парсер ломался, просто потому, что их не понимал. И тогда пришлось как-то поддерживать С++ для того, чтобы поддерживать Objective C. И с этого началась поддержка С++ в AppCode.

Разрабочики CLion и разрабочики AppCode между собой общаются, обмениваются опытом?

— Они, конечно, общаются между собой.

— У трех ваших инструментов много общего кода?

— Его вообще нет. ReSharper С++ был написан сильно позже, и его писал человек, который до этого делал поддержку С++ в AppCode. И поэтому изначально ReSharper С++ дизайнился лучше, то есть архитектурно он правильней.

— А это «правильней» выражается в чем? В том, что меньше костылей приходится вставлять для того, чтобы все работало?

— Да. В конце концов, просто меньше ошибок кодов и багов в поддержке IDE.

— А насколько на самом деле компилятор Microsoft поддерживает стандарт языка C++?

— Уже лучше и постоянно улучшают.

— Реальность такова, что реализация не всегда соответствует стандарту.

— С этой точки зрения С# ничем не отличается от языка, который в реализации часто не соответствует стандарту. Сейчас, с открытием исходного кода, стало, конечно, гораздо проще. Когда что-нибудь ведет себя не так, как написано в спецификации — мы смотрим код, как оно написано в компиляторе, и вcё.

— А для вас, что важнее — соответствие спецификации или реализации?

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

— А как вообще появился сам ReSharper в JetBrains?

— Он появился еще до меня: я в ReSharper только в 2007 году пришел уже на 3 версию или на 4-ую. ReSharper появился тогда, когда появился Eclipse. То есть, компании потребовалось диверсификация деятельности, поскольку возникла серьезная угроза основному продукту: все-таки бесплатные платформы, бесплатные IDE для Java – это серьезный конкурент.

— То есть, это было бизнес-решение?

— Думаю, что да.

— А сейчас вы с коллегами по JetBrains чувствуете, что выиграли войну у Eclipse?

— Да, чувствуем.

О важности внутриотраслевого общения и обмена опытом

— А что насчет ReSharper? Есть разные люди, в том числе, в России, которые делают инструменты для разработки на C#: например, ребята из DevExpress делают CodeRush, который с Roslyn работает. Вы с ними общаетесь, обмениваетесь опытом или нет?

— Я думаю, что DevExpress как-то подзабил на разработку инструментов, разочаровался. CodeRush — это больше сайд-проект: уже в конце 2000-х стало уже понятно, что ReSharper доминирует.

— Вопрос в том, как они у себя решают указанные тобой ранее проблемы. Вы общаетесь с ними? Не общаетесь?

— Они переезжают на Roslyn и пишут те фичи, которые не были написаны на Roslyn. Архитектурно, мне кажется, это невозможно. Написать функциональность ReSharper поверх Roslyn нельзя, не изменяя Roslyn. У нас слишком много структур данных внутренних компиляторных, которые используются для реализации фич анализа. Фича не пишется поверх какой-то код модели, которая зафиксирована. В процессе работы программиста в Visual Studio код модели постоянно немного меняется, меняются индексы, меняется то, что мы храним, то как мы храним. Чтобы корректно производить рефакторинги, мы используем компиляторную инфраструктуру, которая у нас написана. Те проверки, которые мы делаем для проверки ошибок компиляции, мы используем потом в том, чтобы написать предложение о том, что, например, «этот тип может быть заменен на var». И это всюду.

—А теперь у вас есть Roslyn. И вроде как вам нужно жить параллельно.

— Да, мы живем.

— Вы вообще не планируете его использовать?

— Нет.

—На данном этапе вы выиграли войну. И вы доминируете. Но сейчас с выходом Roslyn у остальных появляется шанс.

—У нас нет проблем с производительностью. У нас нет сомнений в том, что мы сможем в том же темпе писать новые анализы или еще более умные completion’ы и еще более умные рефакторинги.

— У вас и так сложные продукты, а сейчас они будут еще сложнее.

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

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

О планах развития других продуктов .NET-стека

— Кроме ReSharper, про которые мы поговорили, у вас в .NET-стеке есть и другие продукты. Что происходит сейчас с ними и что вы планируете с ними делать?

— История началась давно, когда мы написали профилировщик dotTrace. Первую версию профилировщик dotTrace написал Миша Сеньков, который пишет сейчас ReSharper С++. В какой-то момент мы решили форкнуть нашу кодовую базу. В ReSharper’е было много кода, в котором написаны UI, коллекции, примитивы, Application-модели и т.п. Для выпуска продукта dotTrace мы форкнули платформу, и с этого момента у нас происходили несинхронизированные релизы на базе одной и той же платформы разных продуктов: dotTrace и ReSharper.

— То есть, внутри вашей кодовой базы была сущность, которая называется «платформа», и с ней оперировали оба этих продукта?

— Да, репозиторий, там много сборок. Каждый продукт использовал платформу. И у каждого продукта был свой релизный цикл. Накладных расходов, чтобы все это организовать, сделать стабилизацию была просто тьма. Соответственно, когда я пришел к руководству .NET отделом, оно началось с идеи, что платформа должна быть общая, у продуктов должен быть общий релизный цикл и желательно единый Solution, в котором разрабатываются все эти продукты. И мы, соответственно, начали соответственно унификацию нашей кодовой базы так, чтобы из одного солюшена можно было строить новую продукцию.

Если в предыдущих версиях интеграция dotTrace состояла из двух частей: из плагина к ReSharper и отдельного Extension’a для Visual Studio, потому что для того, чтобы интегрироваться с Visual Studio, нужно интегрировать менюшки, сделать манифест, package – все атрибуты Visual Studio экстеншена. В новой схеме мы сделали один продукт, который целиком интегрируется в Visual Studio, но собирается по частям. ReSharper — наверное, единственный Extension, который так делает в Visual Studio. Наш инсталлятор позволяет выбрать несколько продуктов и собирает Extension на лету. То есть, все атрибуты экстеншена у нас генерируются и компилируются. Прямо в инсталляторе написан код, который в Runtime интегрирует несколько продуктов в студию side-by-side.

Мы сделали кнопки, позволяющие включать и выключать каждый продукт. Если рассматривать архитектуру этого решения в принципе, то разные программы, например, ReSharper, Command Line Inspect Code Tool (это утилита для запуска анализа кода на билд-сервере), dotPeek, dotTrace, dotCover, dotMemory, — они запускаются все одинаковым кодом в абсолютно одинаковых условиях, просто с разными параметрами. То есть это фактически одна программа, которая запускается с разными параметрами, и эти программы можно запускать на всех наших сборках.

Когда-то на DotNext я делал доклад про то, как устроена Application-модель, основанная на зонах, которая позволяет все это делать. Собственно, все стало проще. Релизы стали проще. Программы стали все интегрированными теперь. Пользователи теперь не спрашивают: «Какой dotCover совместим с вот этой вот версией ReSharper?» Все это нам позволило выпустить ReSharper C++ как отдельный продукт, который может работать и вместе с ReSharper, и ReSharper без него может работать, и вместе они тоже могут работать.

— Насколько ваша новая модель уже сидит в головах у пользователей?

— В головах у пользователей я вижу, что очень много людей ставят — инсталляции dotTrace в студии выросли в разы.

— Здесь хороший потенциал для всяких там кросс-продаж.

— Кросс-продажи привели к тому, что мы продажи профайлеров прекратили совсем, и их просто не купить как отдельные продукты. Потому, что это больше приводит к проблемам, чем к пользе. Проблема заключается в том, что у меня есть лицензия на ReSharper, отдельно на dotTrace, я хочу поставить новую версию продукта, а версии синхронизированы. И вот эти лицензии на отдельные версии не работали совсем. Они могут быть несовместимы, могут отличаться, могут кончаться – одна позже, другая раньше… Чтобы избавиться от этих всех проблем, просто сделав более дорогую версию.

О работе с фидбеком пользователей для улучшения продукта

— Мы с тобой постоянно говорим про Performance. Специфика ReSharper’а такова, что в приложении много разной функциональности, и каждый пользователь использует свое собственное ее подмножество. А большинство людей, которые пишут на .NETe, они пишут программы с вполне обозримой кодовой базой, где есть фиксированный workload, где по циклу выполняются одни и те же операции, где действительно можно снять какой-то профиль и посмотреть горячие методы. У вас это как-то совершенно не так. Как вы с этим живете? Как вы все это держите в голове?

— Есть несколько вещей. У нас есть такая кнопка – Profile Visual Studio. Ты, как пользователь, можешь записать кусок времени, когда ReSharper тормозил, отослать это нам и мы, скорее всего, что-то с этим сделаем. Это механизм, который работает. С его помощью мы, версия за версией, исправляем баги. А дальше… дальше сложно.

Как программист походит к оптимизации, желательно обозримой? Find Usage, анализ файла, навигация, может, в каких-то сложных местах. И смотрит, сколько времени потратилось на эту операцию. Find Usage сейчас у нас занимает 10 секунд, а должен занимать семь. Но в процессе изменений мы делам кэши, меняем структуруыданных, которые тоже нужны. И можно легко потерять производительность в каком-нибудь другом сценарии, например, в код Code Completion, а еще хуже в какой-нибудь синхронной части его части, который работает у тебя в Foreground и напрямую влияет на время отклика при печати.

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

— Как это вообще можно тестировать?

— Это практически не поддается регрессионному тестированию. Одним из важнейших критериев корректности любого теста на производительность является повторяемость результата. Это работает, если у тебя стабильная виртуальная машина на сервере, на котором нет другой нагрузки. А когда у тебя typing тормозит на каждый 10-й символ, а девять проходят — это довольно тяжело уловить.

— Непонятно, как сформулировать метрику, в которой это можно увидеть.

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

— Правда ли, что это лечится иными подходами к самой разработке, как примерно Дима Иванов рассказывал? И второе — правда ли, что в этом месте единственное, что работает – это пользовательский фидбек?

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

— Много таких скриншотов?

— Несколько в день. Часто бывает, что тормозит не ReSharper, а какой-нибудь экстеншн к ReSharper’у, экстеншен к Visual Studio или сама Visual Studio. Ну или что-нибудь, что вообще не поддается никакому анализу.

— Вы в этом случае идет в Microsoft или к тому, кто делал этот экстеншн для ReSharper?

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

---

Другие выпуски «Без слайдов» вы можете найти на нашем Youtube-канале, а расшифровки — на хабре, просто поискав в нашем блоге или по соответствующей метке.