.NET Tools. Интервью с Сергеем Шкредовым (JetBrains), Павлом Авсениным и Александром Захаровым (DevExpress)
Некоторые разработчики программируют взглядом. Другие слепы и программируют на слух\ощупь. Отдельным товарищам достаточно маркера и доски. Но все-таки большинство .NET-разработчиков пользуется Visual Studio для кодирования и дебага, парочкой профайлеров, декомпилятором, плагином для VCS, браузерными инструментами, R#\CodeRush, тулзой для контроля базы данных, баг-трекером, билд-системой и кофемашиной.
Мне удалось поговорить с разработчиками некоторых из перечисленных средств разработки.
Под катом — скучная и совершенно неинтересная реклама, немного Roslyn, чуть-чуть Rider, минимум CodeRush, малость описаны фичи C# 7.0, бегло рассмотрены перспективы .NET и один раз упоминается PVS-Studio.
JetBrains представлял Сергей serjic Шкредов, автор многочисленных фич в ReSharper, адепт системного программирования, руководитель .NET-направления в JetBrains, а также один из разработчиков (и пользователей) Rider.
— Добрый день, Сергей. Начнем с начала, а именно с IDE. Сейчас .NET мир лихорадит: вышли новые версии .NET, новые версии студии, своих первых пользователей нашел Rider. Когда ситуация немного успокоится?
— Добрый день. Надеюсь, никогда не остановится. Мы живем в мире, который крайне быстро меняется. И, на мой взгляд, сейчас в .NET гораздо больше порядка. MS развивает его как платформу, обслуживающую все MS-стеки разработки: отделы мобильной разработки, облачной, WinPhone, десктоп — все заинтересованы в развитии платформы. Чувствуется, что сейчас разработка упорядочивается: уменьшается влияние отдельных команд, .NET развивается как единое целое.
— У каждой платформы свои ограничения, не будет ли сокращаться основа .NET, общая для всех?
— Как раз наоборот. Для интеграции с .NET Standard каждая из платформ развивает свои API, расширяет их. Меня удивляет только живой Mono, я думал его заменит .Net Core. С другой стороны, Mono развивается с .NET Standard, что внушает определенные надежды.
— Судя по обсуждениям разных IDE на хабре, главные характеристики IDE — скорость работы, минимум потребляемой памяти\проца, скорость загрузки проектов, ну и набор фич. Есть ли вещи более важные?
— Конечно. Производительность критична. IDE должна быстро загружаться, загружать проекты, не блокировать UI; Этакие три кита, три критерия производительности.
Но при этом каждая IDE поддерживает некий стек технологий. То есть, имеются разработчики, они решают типовые бизнес задачи, обычно на одном стеке технологий. Соответственно, основная задача IDE — облегчить работу с этим стеком. Например, мы в Rider концентрируемся сейчас на кроссплатформенной мобильной разработке и ASP.NET.
— Выбрали самое популярное направление?
— В том числе. Помимо популярности, эти стеки не так сильно приросли к MS. Много OpenSource-утилит, инструментов. Если взять SharePoint или Office разработчика — без VS практически невозможно что-либо сделать. Кстати, я забыл упомянуть Unity. Аудитория немаленькая, но потребности у неё отличаются от того, что мы привыкли видеть в Web или мобильной разработке. Кода не так много, и польза от IDE чуть менее заметна.
— Вы собираетесь работать еще и с игровым движком?
— Нет, только со скриптовым. Грубо говоря, Unity состоит из двух частей: графического движка и скриптов. С графикой работают в Unity Studio, скрипты пишут под MonoDevelop или VS. Мы поможем работать со скриптами.
— Ранее R# был ограничен .NET framework 3.5. Сейчас это ограничение в силе?
— Нет, мы уже не поддерживаем версии VS меньше 2010, слишком мало пользователей у них осталось, да и для VS 2010 требуем 4.0. Cкоро будем требовать 4.5. Хотелось бы .NET 4.6.2, но он установлен далеко не у всех наших пользователей… Так что в ближайшие несколько лет ничего не изменится.
— Инструменты сейчас все чаще и чаще парят в облаках. Сервера, системы мониторинга, TFS, превратившийся в VSTS… Ожидает ли нас облачная IDE?
— Разработчикам пока лучше посидеть на десктопе, по крайней мере, я не вижу мотивации для перехода в облака. Разве что пригодилась бы мини IDE для быстрых фиксов без локального чекаута. Да, билд-фермы в облака уходят. Если у тебя часто возникает затык с очередью билдов, было бы неплохо иметь возможность быстро добавить несколько машин в build agents pool. При этом тут тоже нужно считать. По нашим расчетам, получается дешевле ставить собственные сервера.
— У вас TeamCity?
— Да, вся наша внутренняя инфраструктура живет на TeamCity. Для OSS-проектов мы тоже используем публичную инсталяцию TeamCity.
— Вопрос про анализаторы Roslyn. Простейший рабочий анализатор пишется за несколько часов, однако дальше простейших же примеров дело обычно не заходит. И это при наличии уже готовых решений, которые могут служить отличной спецификацией. В чем проблема с этими анализаторами?
— Писать их просто, но какова мотивация авторов? Анализаторы — это клевая игрушка. Того же эффекта можно было и раньше добиться с помощью R# SDK. Пожалуй, единственное преимущество анализаторов Roslyn — это хорошая интеграция с Build процессом и IDE, это реально классно сделано. Но как и у нас, там есть большие проблемы с публичным API. Язык меняется, а это значит, что анализаторы тоже надо дописывать для новых конструкций языка.
В Open Source обычно контрибьютят либо полностью готовый фреймворк, либо соединение пару сложных фреймворков для получения готовой тулзы. Придумать же сложный проект с анализаторами тяжело: по факту ценность такого проекта накапливается с количеством анализаторов. При этом многие из них весьма похожи. В итоге для получения серьезного продукта нужно запилить 100 почти одинаковых фич. Методично, один за одним писать скучные куски кода — откуда возьмется мотивация на это? Плюс, написать анализатор правильно с первого раза трудно, жизненный цикл немаленький. То есть, ты пишешь анализатор, релизишь его, получаев 15 реквестов на редкие баги. Довольно тяжелое занятие.
— То есть, за подобные вещи стоит браться с чисто финансовыми намерениями? Самая простая мотивация?
— Я ожидал такого, что кто-то возьмется. Вот, PVS-Studio взялись. Пилят анализатор за анализатором.
— А что с производительностью анализаторов?
— Сильно страдает. Например, для работы с интерфейсами нужно строить индекс, который позволяет быстро анализировать десяток сценариев, иначе у нас будет десяток перевычислений. Если пилить это в Open Source — кто-то должен написать такой индекс, а потом десятку разработчиков придется как-то к индексу коннектиться. Даже за счет проблем коммуникации это очень сложно.
— Разработчики все больше и больше полагаются на свои инструменты. Помимо знания непосредственно языка (и пары платформ) сейчас нужно уметь работать с VCS, дебаггером, парой профайлеров, рефлектором, различными тулзами для рефакторинга, тестовым фреймворком (а то и не одним), системой управления проектами, инструментами разработки в браузере, да и сам .NET язык постоянно развивается. Мы становимся все более зависимыми от инструментов и stackoverflow. Настанет ли время, когда класс программиста будет определяться знанием утилит и плагинов, а не языка и библиотек?
— Да, знание языков и алгоритмов обесценивается. Инструменты становятся удобнее, часть работы берут на себя. Вспомни старые добрые WinForms: надо было создать элемент, подцепиться к EventHandler, написать метод для обработки, изменить модель, получить ответ, изменить пару компонент, кучу всего провалидировать. Недавно я писал на Kotlin c React, и почти не думал о UI. Изменил модель, отдал её на перерисовку, и фреймворк сам подхватил все изменения. Совершенно иной подход. Думаю, в ближайшее время от программистов будут требовать знание фреймворков, модных технологий, понимание как писать скалируемый код, переносимый. А алгоритмы и структуры данных — прошлое.
— Это касается только .NET мира? Полагаю, возражения системных программистов будут весьма эмоциональными.
— Разработчики компиляторов и высоконагруженных решений, конечно, останутся. Но сейчас все больше и больше людей программирует просто с помощью StackOverflow и довольны этим.
— Разработка стала проще?
— Исчезла необходимость разбираться в том, как работает конкретный фреймворк. Точнее, фреймворки появляются настолько быстро, что у тебя нет времени на их изучение, и ты вынужден доверять их авторам.
— Сергей, ты не мог бы рассказать про Team Tools (Hub, TeamCity, Upsourse, YouTrack)? Насколько сильно ваш набор приблизился к VSTS и Atlassian стеку? Что нам ждать в будущем?
— Необходимые компоненты мы собрали: YouTrace — баг трэкер, TeamCity — CI сервер и Upsource для код-ревью. При этом конкурировать нам с конкурентами сложно, наши продукты разрознены. В продукте Hub мы организовали User Managment, но оставшихся интеграций — вагон.
— Как вы будете это исправлять?
— Пока только планы, публичных заявлений не будет. Но мы понимаем, что люди работают в командах, и хотим, чтобы IDE знала о командах больше. То есть, ты зашел в студию, подключился к серверу — и у тебя IDE уже знает о твоих проектах, тасках, багах и т.д.
— Rider. Год назад вы не собирались слезать со студии, в январе же анонсировали свою IDE. Чего нам ждать от нее (помимо скорости\удобства)? Плагины? Интеграция со всем и вся? Интеграции со своим Team Tools стеком?
— Мы пока не слезаем со студии. Основные фичи R# и профиляторов работают со студией (и шарятся с Rider). Что до Rider — сейчас уже собрали значительную пользовательскую базу. Есть люди, которые сидят на Rider месяцами, не открывая студию (я в их числе). Сейчас мы рассылаем ссылки на свежие билды нашим самым ранним пользователям private EAP, но уже на днях собираемся открыть публичный EAP, а значит Rider можно будет скачивать всем прямо с сайта. Для нас это важный шаг, количество пользователей увеличилось на порядок. Очень много усилий мы сейчас прилагаем для достижения стабильности, чтоб билд\дебаг работал для любых проектов и выживал на любых системах.
Разделив обработку кода и UI — мы получили довольно шуструю, отзывчивую IDE. Над расширяемостью тоже поработали, плагины можно писать как к фронт-энду, так и к бек-энду. Сейчас пилим анализатор, позволяющий определять совместимость плагинов.
— Какая билд-система используется для билда?
— MsBuild на Widows, можно использовать XBuild на Mac и Linux (мы его не рекомендуем, но в то же время понимаем, что не все еще перешли на кросс-платфоменный MsBuild). В плане билд-системы мы никуда не от MS не уходим.
— То есть, ошибок билда при миграции со студии не будет?
— Именно. По большому счету, нет никакой миграции, открываешь все тот же студийный .sln и продолжаешь работу.
— Вы планировали выпустить релиз осенью. Получится?
— Увы. Пока планируем релиз на начало следующего года. Продукт будет платный, и нам не хочется стыдиться того, за что берем денежку.
Другого производителя, DevExpress, рекламировали адепты парного программирования:
Павел pavsenin Авсенин
.NET-разработчик, в эпоху бума Flash сбежавший в разработку приложений для соцсетей. Четыре года назад он вернулся и с тех пор помогает выбирать красивые имена для новых переменных в команде CodeRush. Большой любитель созерцать разные заголовочные файлы, особенно весной.
Александр alexandrz Захаров
Увлекся компьютерами и программированием еще в раннем детстве. Прошел через ZX Spectrum, BASIC, Pascal, C, C++, Java, и в итоге остановился на C# и .NET.
Сейчас занимается разработкой CodeRush в компании DevExpress.
— Добрый день. Сейчас .NET мир лихорадит: вышли новые версии .NET, новые версии студии. В DevExpress почти все продукты завязаны как минимум на один из этих компонентов, насколько тяжело вам успевать за MS?
— Да, MS развивает .Net Core, Xamarin, запускает Standard, и нас это радует. Технология развивается — значит она живет. Что касается поддержки — у нас свой подход: мы следим за любой технологией с самого начала её существования, но серьезно начинаем с ней работать только после некоторой стабилизации. Мы смотрим, пробуем, делаем билды, но публично это не выкладываем. Так, мы наблюдали за .NET Core и не предпринимали активных действий до выхода релиза. Так что, все изменения по сравнению с RC нас не коснулись. Помимо того, что мы не тратим сил на поддержку «не выстреливших» продуктов, за время ожидания у нас накапливаются запросы от клиентов, что позволяет нам точнее расставить приоритеты.
Хотя провалы случаются и у нас. Например, мы потратили немало ресурсов на поддержку мертворожденного Silverlight.
В последнее время работать стало проще: много вещей лежит в OpenSource, есть Early Access. Проще стало реагировать на изменения, мы узнаем о них раньше.
— Иногда конкуренты создают что-то до вас. Насколько вам помогают их продукты?
— У нас нет приоритета по скорости, наша цель — качество. Мы посматриваем на решения конкурентов, учитываем их успехи и ошибки, но стратегию свою пытаемся строить исходя из запросов юзеров и их отзывов.
— Вопрос про анализаторы Roslyn. Простейший рабочий анализатор пишется за 5–10 вечеров, однако дальше простейших примеров дело обычно не заходит. И это при наличии уже готовых решений, которые могут служить отличной спецификацией. В чем проблема с этими анализаторами?
— Во-первых, подобные анализаторы (по сотне штук в пакете) есть.
Во-вторых, API — шикарное, но сам подход иммутабельных деревьев непривычен большинству разработчиков.
В-третьих, один анализатор действительно пишется за несколько часов, но обычно людям нужен целый спектр подобных вещей, для чего уже желательна команда, желательно пишущая продукт ради денег (это значительно ускоряет проект).
Почему же в OpenSource до сих пор такой команды не появилось?
— Сам MS развивает свои рефакторинги. Полагаю, никто не желает с ними соперничать. Плюс, висит вопрос мотивации: реально большой и сложный проект нужно поддерживать, а рассчитывать на поддержку в OpenSource рискованно. Вот и получается: маленький проект никому не нужен из-за недостатка функционала, большой из-за возможных рисков с поддержкой.
— Когда мы пишем анализатор — мы кидаем место фиксеру, и он бегает по коду во второй раз. Как вы решает проблему повторных вычислений?
— Если ты бегаешь по синтаксису — проблем у тебя нет, это быстро. Если же обрабатывается семантика — у Roslyn есть свой кеш. В целом проблема невелика. И потом, говорить о повторных вычислениях в вакууме бессмысленно. Чаще всего надо замерять каждый анализатор отдельно.
— DevExpress упоминался как контрибьютор в Roslyn. Насколько проект открыт, насколько он развивается, какие тренды сейчас в его развитии?
— Конкретно команда CodeRush не контрибьютила. У нас была одна идея, но её уже серьезно пилили, так что мы решили не вмешиваться.
Что до открытости: приобщиться к великому может каждый, проект развивается активно.
Каждый апдейт студии — апгрейд перформанса, иногда открывают API. Так, в 3 превьюшке разрешили экспорт комплишен-провайдеров для вставки автодополнений в основную сессию IntelliSense. Был API internal, стал public. Сейчас еще и сам C# активно пилят до 7 версии (быстрее бы уже), добавляются фичи, в том числе из функционального программирования. Ну, и рутина: фиксы, перформанс, полировка API.
— Анонсирован .NET standard 2.0. Он станет таки единым стандартом, или можно скачивать картинку про 15 уже 16 стандартов?
— Таки станет. .NET Core, Desktop, Xamarin — все там будем. Все зависит только от MS, желание у них есть, Roadmap есть, так что свою работу они доделают. С другой стороны, как видно по опыту предыдущих попыток, процесс унификации сложен и тернист, платформ немало. Скорее всего, придется сделать несколько попыток.
Наверняка будут будут сложности. Раз API общий, а реализация разная — появятся недокументированные возможности, раз они появятся — их будут юзать, раз их будут юзать — код станет непереносимым. И хоть это будет косяк разработчика — непереносимость появится. Производительность под разными платформами будет различаться. Возможно, появится какое-нибудь исключение или атрибут NotSupportedPlatform.
Иными словами, унификация закончится, но когда именно — только время покажет.
— На каком стандарте MS остановится? 4.5, 4.5, 4.5.1?
— Они будут работать вечно. Не только потому, что им выгодно над чем-то работать, но и потому, что мир меняется, открываются новые возможности. И появляются новые конкуренты.
Сейчас MS занимается IoT, возможно, появится .NET для кофеварок. Может, запилят .NET для браузеров, TypeScript намекает. Разработки в нативной компиляции ведутся. Возможностей — миллион.
— Сейчас началась маркетинговая волна мессенджер-ботов. Ожидают ли нас скайп-помощники админов\тестировщиков\разработчиков?
— Уже есть подобные вещи. Например, бот коннектится к билд-серверу, смотрит последние билды, если есть красные — шлет сообщение в Slack. С другой стороны — боты лишь интерфейс. Если есть какой-то софт для задачи — его можно прикрутить к боту. Разве что, есть некоторая сложность с обработкой команд в мессенджере, могут потребоваться интеллектуальные утилиты.
— У DevExpress солидный набор инструментов, причем сильно различающихся по «направлению»: дополнение для IDE, графика, тестовый фреймворк, инструменты аналитики… При этом они кажутся достаточно разнородными. Насколько тяжело поддерживать такое разнообразие?
— Основное направление: разработка компонентов для разных платформ. Графика. Компоненты, контролы для WPF, WinForms, JS, etc. Остальное — просто некое развитие идеи компонентов. Разнообразие есть, но обычно есть система и поддерживающая её команда. Так что основные проблемы возникают при кросспроектных коммуникациях.
— CodeRush поддерживает все популярные тестовые фреймворки. Как вы боретесь с искушением написать свой?
— Борьба с искушением проста — у нас нет искушения. Была мысль сделать mock-фреймворк с возможностью подменять непубличное API и поведение типов из BCL, мысль до сих пор есть, но приоритеты иные. Есть nUnit, xUnit — незачем с ними бодаться, они отлично делают свою работу. Кроме того, у нас были запросы непрерывного прогона тестов (в фоне), но запросов этих немного.
— Какие инструменты популярны в конторе, разрабатывающей инструменты?
— CodeRush. Хотя кое-кто не видит пользы в подобном инструментарии, принципиально его не использует. VS. nUnit, xUnit. Git, Mercurial. Багтрекер свой, Trello как планировщик, профиляторы — от PerView до dotTrace. Свое решение для CI, основано на CruiseControl. В целом, зоопарк обширен.
— Разработчики все больше и больше полагаются на свои инструменты. Настанет ли время, когда класс программиста будет определяться знанием утилит и плагинов, а не языка и библиотек?
— Инструменты экономят время, и немало. Можно ли называть себя программистом не умея ими пользоваться — большой вопрос.
Опять-таки, может, где-то еще сохранился анахронизм с разделением на проектировщиков, программистов и тестировщиков, когда проектировщик проектирует архитектуру, отдает это черни, которая программирует и потом отдает код другой черни, которая тестирует. У нас разработчик делает все эти вещи сам, и требования к разработчику соответствующие.
— На собеседовании вы спрашиваете его про любимые инструменты? Это критичный вопрос?
— Не критичный. Eсли человек чего-то не знает: возможно, он этим не пользовался, не было повода. Обучаемость важна. Она определяет класс программиста.
— Честно говоря, я не сталкивался пока с функциональными языками. Про обновление .NET новости мелькают часто, а F# почти не упоминается. Язык еще развивается?
— Упоминаний мало по одной простой причине: все необходимое уже на борту. С версии F# 3.0 там только небольшие косметические улучшения. Последнее время MS пытается интегрироваться с Roslyn на уровне проектной модели (Workspace API). Кстати, интерес к F# лишь растет. Появляются конференции, видео, посты. Есть небольшое, но преданное комьюнити.
Хотя масштаб, конечно, несопоставим с C# (пока что). Если сравнивать количества — на одного F# разработчика приходится десять разработчиков C#. Просто из-за функциональной парадигмы, не каждому она удобна или понятна. Скорее всего, со временем F# догонит C#, или вольется в него. Это не язык для финансов, Machine Learning, это отличный язык для всего.
— Появится ли CodeRush для F#?
— Сейчас тулинг убог, есть Visual F# Power Tools — и все. Остальное — точечные инструменты. По поводу CodeRush для F# — тут все зависит от запросов наших пользователей. Они есть, но их пока не очень много. Возможно, после интеграции с RoslynWorkspaceApi задача станет проще, и мы всерьез об этом задумаемся.
— Насколько реально использовать CodeRush для обучения? Он подсвечивает ошибки, предлагает исправления.
— Закрепление — возможно. Накосячил — тут же получил втык. Вежливый. Насчет же обучения — нет. Некоторые джуны увидев ошибку — гуглят. Что, зачем, почему так нельзя, почему нужно иначе. Остальные не думая применяют рефакторинг. Более того, если много полагаться на инструмент — в один момент перестаешь развиваться. Зачем, если умная тулза все сделает за тебя?
— CodeRush. В чем принципиальное отличие от R#? Вы конкурируете, или занимаете две ниши?
— Это инструменты одного класса, инструменты продуктивности разработчиков, и занимают они одну нишу. По факт, они появились почти одновременно. Когда только появлялись первые студии — у MS был IntelliSense и все. Тогда и появились CodeRush и R#.
— Почти 15 лет истории?
— Да. Хотя сейчас история переписывается. Одно время продукты были похожи, цеплялись к студии, тормозили её. То есть ранее студия разбирала код, и CodeRush\R# разбирал. Потом на стороне редактора потребовался доступ к компилятору, MS сделали CompilerAsService, у внешних утилит появилась возможность цепляться к компилятор… короче, два года назад мы переписали все на Roslyn.
— Пару лет назад вы сделали ставку на Roslyn (на тот момент еще сырой). Как вы думаете, сыграла ваша ставка?
— Основные желаемые плюшки мы получили: удалось избежать двойного разбора кода (а это двойные вычисления и память). Плюс, сейчас мы стали спокойнее воспринимать новые фичи в C#, обрабатывать их стало проще. Не нужно самостоятельно фиксить свои алгоритмы разбора кода, автоматом получается парсер и резолвер. Почти вся «рутина» сделана, остается только писать новые фичи. Тут сложно говорить о выигрыше, думаем, время покажет.
Мы сравнивали версии CodeRush (с Roslyn и без него) — Roslyn версия забирает чуть больше оперативной памяти, но это не критично. То есть, Roslyn действительно жрет много памяти, но при обработке синтаксических и семантических деревьев мы используем лишь его ресурсы, сам CodeRush теперь ничего не добавляет. Когда мы начинали переход, иммутабельное дерево вызывало много вопросов. Предполагалось, что managed компилятор будет тормозным. Но выяснилось, что деревья можно обрабатывать в нескольких потоках, что ускоряет вычисления. По поводу же «сырого» Roslyn — на тот момент проекту уже было несколько лет, писала его команда отличных спецов, и видно было что MS его улучшает. «Незнакомый» — может быть, но это поправимо. И да, когда мы серьезно взялись за переработку CodeRush, студия уже вовсю крутилась на Roslyn и была вполне стабильной.
— Что насчет идеи разделения UI и компилятора (как в Rider)?
— У JB есть платформа для написания IDE. Популярная, одна из лучших. Есть соответствующие спецы. У нас таких условий нет, так что этот вариант мы серьезно не рассматривали. На наш взгляд, .NET и MS неразделимы. Поддерживать свой компилятор — задача трудоемкая, и мы решили последовать за MS.
Если вы прочитали эти интервью и вам мало — приходите на DotNext 2016 Moscow. На конференции будем говорить не только про тулзы: пройдемся и по перфомансу, и по многопоточности и много по чему еще:
⬝ .NET Core: State of the art
⬝ Squeezing the Hardware to Make Performance Juice
⬝ Интеллектуальные чатботы и когнитивные сервисы
⬝ Stack Overflow — It’s all about performance!
⬝ Advanced Xamarin.Forms
⬝ C++ через C#
⬝ Продолжаем говорить про арифметику
⬝ ASP.NET SignalR: Why It’s Getting Really Crucial for Web Development
⬝ Exceptional Exceptions in .NET
⬝ Модификация кода .NET в рантайме
⬝ End-to-end JIT
⬝ Performance tuning Stack Overflow tags
⬝ C# Scripting — why and how you can use your C# in places you never thought of before!
⬝ Multithreading Deep Dive
⬝ Собрать всё, или Знакомимся с Cake (C# Make)
⬝ WinDbg Superpowers for .NET Developers
⬝ Overview of the new .NET Core and .NET Platform Standard
⬝ Какие уязвимости находят в .NET платформе и как не повторить их в своих приложениях
⬝ What’s new in C# 7?
⬝ ETW — Monitor Anything, Anytime, Anywhere
