Дивный новый Roslyn: Кому нужны собственные анализаторы кода и скриптинг на C#?
Чтобы исправить это, мы взяли интервью у Filip W, Microsoft MVP, контрибьютора Roslyn и просто одного из наиболее популярных в мире ASP.NET блоггеров. Почему Filip считает, что изменения в новом С# могут пройти незамеченными, зачем писать собственные анализаторы кода, а также почему скриптинг на C# лучше, чем любом скриптовом языке?
JUG.ru Group: Филип, давайте начнем с разогрева. ASP.NET Core сейчас сильно меняется. Как вы относитесь к происходящим переменам как разработчик, работающего с платформой?
Filip W: Конечно, первопроходцы испытали множество проблем: переносы сроков, ад с версионированием, смены названий, проблемы с инструментарием, непоследовательная система работы с проектами и много чего еще, вплоть до изменений самого концепта .NET Standard. Можно ли бы сделать лучше? Определенно да, впрочем ретроспективно все всегда выглядит просто и понятно.
Если же говорить в целом, совершенно точно изменения происходят к лучшему. Просто подумайте, несколько лет назад ASP.NET работал только под Windows и только под IIS. К тому же он основывался на System.Web.dll, который к каждому HTTP-запросу добавлял нелепый оверхед (29Kb в среднем). Сегодня же, ASP.NET Core, если верить бенчмаркам, входит в тройку-пятерку лучших по производительности веб-фреймворков на Linux. С этой точки зрения платформа бесспорно прошла невероятную трансформацию.
JUG.ru Group: То есть ты уже писал .NET приложения под Linux? Расскажи, как обстоят дела со стабильностью таких решений? Готова ли платформа к продакшену?
Filip W: Да, многие мои новые проекты сейчас крутятся в Docker на Debian-based системах. Я столкнулся с некоторыми проблемами с платформозависимым кодом, таким как криптография, или со странными дедлоками, возникающими тут и там, но в целом все меня устраивает. Ну и конечно, преимущества возможности управления всей платформой через Docker Swarm впечатляют.
На самом деле, мы у себя стараемся разрабатывать кроссплатформенный .NET код независимо от того, на какой ОС проект будет развертываться. Как результат, у большинства наших проектов есть билд-агенты для Windows, macOS и Linux. Таким образом, я могу разрабатывать что-то на своем Mac и иметь возможность развернуть это хоть в Docker, хоть в Azure Web App с гарантией того, что все будет корректно работать.
JUG.ru Group: Что насчет C#? В версии 7.0 у нас будут кортежи, pattern matching и много других фич. Будут ли эти нововведения полезны для тебя, как для разработчика?
Filip W: Вообще, как и в случае с C# 6.0, изменения незначительны, так что вполне вероятно, что многие разработчики в своей повседневной работе не заметят перехода на новую версию. Лично для меня точно полезными окажутся кортежи, поскольку в текущем виде они реализованы из рук вон плохо. Надеюсь, это поможет резко сократить количество вспомогательных классов, с которым мы сталкиваемся сейчас, когда для десериализации или чтения одного-двух полей из БД разработчик вынужден создавать новый класс.
Меня немного расстраивает, что синтаксис паттерн-матчинга не будет основан на expression-ах. Вместо этого будет акцент на is и switch, впрочем, я понимаю рациональность того, что нововведения приходят шаг за шагом. К тому же, более экспрессивные элементы помогают писать лаконичный код, а C#, как мы знаем, может быть очень «многословным», так что подобные изменения тоже к лучшему.
C# vs Powershell — 1:0
JUG.ru Group: На прошлом DotNext ты рассказывал о скриптинге под C#. Как по-твоему, доклад «зашел»? Востребован ли такой сценарий использования C# среди .NET-разработчиков?
Filip W: О, я получил невероятный отклик аудитории! Мне кажется, скриптинг — одна из наиболее классных сторон Roslyn, поскольку она открывает доступ к множеству интересных юзкейсов, недоступных ранее в экосистеме .NET. Конечно, раньше можно было пользоваться Powershell, однако возможность писать скрипты на C# — совсем другое, учитывая насколько он близок .NET-разработчикам. Сейчас можно наблюдать резкий рост использования скриптов на C# в коммерческих проектах: на них реализованы Azure Functions, расширения для игр и многое другое. Прибавить к этому языковые сервисы и поддержку intellisense/дебаггинга для C#, которые можно получить в каком-нибудь легком редакторе, типа VS Code, и вы получаете очень приятный процесс разработки. Забавно, что C#, будучи нескриптовым языком, получил настолько мощное окружение, что вряд ли какой-либо из скриптовых языков может поспорить с ним в плане продуктивности.
В Москве в дискуссионной зоне мы почти два часа обсуждали сложности и способы применения C# скриптов: для безопасности, управления памятью, расширения приложений (системы плагинов, основанные на скриптах) и даже удаленный REPL для управления исполняемыми процессами. Это было круто!
Разработка собственных инспекций кода под Roslyn
JUG.ru Group: Кроме скриптинга, ты занимаешься еще и статическим анализом кода. Расскажи, кому может понадобиться разработка собственного анализатора, учитывая, что на рынке есть VS и Resharper?
Filip W: Собственный анализатор обычно нужен тимлидам, которые занимаются code review и вообще отвечают за качество кода в команде. Здесь важно понимать, что в процессе разработки мы сталкивается с какими-то своими проблемами и шероховатостями, актуальными только в контексте нашего проекта. И Решарпер, и VS являются универсальными инструментами, рассчитанными на широкую аудиторию, но что делать, если вам надо обеспечить применение какого-либо конкретного паттерна или соответствие кода вашим корпоративным гайдлайнам? Например, установить правила именования классов/переменных, убедиться в том, что ваш внутренний API используется только так, как это задумывалось, что код документируется в соответствии с вашими стандартами, или что HTTP endpoints разрабатываются в соответствии с установленным стандартом. Иногда встречаются и странные вещи, — я как-то работал в проекте, где на уровне компилятора запрещалось использование табов и #region-директив.
Впрочем, даже если забыть о написании собственного анализатора, важно понимать, как они работают «под капотом». Как и в других областях программирования, даже если у вас руки не дойдут до написания своего анализатора, очень полезно понимать те принципы, которые лежать в их основе, а также как работает API компилятора, обеспечивая работу анализатора кода.
JUG.ru Group: Говоря о компиляторе, какие Roslyn Compiler API облегчили вашу жизнь по сравнению с предыдущим?
Filip W: Это вопрос с подвохом? По факту, старый компилятор не позволял делать ничего, кроме как скармливать ему код, а на выходе получать DLL/EXE файлы. Так что для меня наиболее важным в Roslyn стало то, что это настоящий Сompiler-as-a-Service, где каждый шаг пайплайна имеет внешний API, который можно использовать по-своему. Также удивительно то, что до Roslyn не было официальной C# AST библиотеки (можно было найти только сторонние варианты).
JUG.ru Group: Кстати, а что с обратной совместимостью? Какова вероятность, что мой самописный анализатор развалится при следующем релизе Roslyn?
Filip W: Ну, то, что команда Roslyn уделяет огромное внимание обратной совместимости, я знаю наверняка! Если копаться в коде компилятора, можно найти невероятные примеры этому. Например, если поискть в исходном коде компилятора, можно обнаружить строки «DELIBERATE SPEC VIOLATION». Что это? Выясняется, что код старого компилятора CSC, из-за багов или каких-то недопониманий, в некоторых местах нарушает спецификации C#. В то же время, команда Roslyn не планировала делать никаких изменений, способных что-то поломать, и таким образом мы получили новый компилятор, в некоторых местах которого разработчики сознательно нарушали спеку C# и документировали это как deliberate spec violation:) Ссылка.
Я понимаю, что обратная совместимость компилятора и его API это разные темы, однако мой пример хорошо показывает менталитет команды. Я и сам контрибьютил кое-что в Roslyn и могу сказать, что один из наиболее утомительных аспектов code review — это то количество внимания, которое уделяется разбору каждого «публичного» API — именно потому, что оно будет поддерживаться в Roslyn в течение длительного времени. Так что, если честно, я не переживал бы насчет обратной совместимости.
JUG.ru Group: Как ты вообще пришел к тому, что начал исследовать Roslyn API? Какие именно проблемы ты хотел решить изначально?
Filip W: Изначально я попал в сообщество Roslyn из-за работы со скриптами, мы делали проект Scriptics, один из тех проектов, которые помогли нам сформировать всю эту историю со скриптами на C# 10 лет спустя. Тогда я попал в проект OmniSharp, который добавляет intellisense и языковые сервисы C# в редакторы типа emacs, vim или Atom. Хотя конечно крупнейший и наиболее узнаваемый «потребитель» OmniSharp в .NET сообществе это Visual Studio Code. Там я и начал разработку инструментов для анализа кода, рефакторинга и многих других языковых фич уровня IDE.
JUG.ru Group: Скажи, что будет со статическим анализом кода в ближайшем будущем? Чего стоит ждать ближайшие 1–3–5 лет?
Filip W: Думаю, что мы увидим много «живых» диагностик. Josh Varty, один из моих друзей, построил крутейший аддон к Visual Studio под названием (сюрпиз!) Alive, который выполняет блоки вашего исходного кода и моментально сообщает вам, как будет работать ваш метода или ваш цикл, а также предупреждает об ошибках, которые могут произойти в рантайме. Это все находится за гранью статического или семантического анализа кода, все построено на базе Roslyn.
Так что в общем, на мой взгляд, мы столкнемся со все более продвинутыми аналитиками, такими как поиск ссылок на null через символьные вычисления. На данный момент сообщество пока еще просто разбирается с теми возможностями, которые дает Roslyn. Кроме того, я надеюсь увидеть более плотную интеграцию анализаторов Roslyn в сторонних инструментах, таких как OmniSharp или Resharper. Подобные анализаторы уже существуют для Visual Studio Code, но их работа пока далека от идеальной.
JUG.ru Group: Спасибо, Филип, до встречи на DotNext!
Filip выступит с докладом «Building code analysis tools with the .NET Compiler Platform (Roslyn)» на грядущей конференции в Петербурге, на одной сцене с Jon Skeet, Sasha Goldshtein и другими MVP. Подробности о спикерах и докладах доступны на сайте DotNext 2017 Piter
P.S. Напоминаем, что до конца февраля действует ранняя регистрация и пока можно зарегистрироваться, сэкономив пару тысяч.
Комментарии (6)
Tantrido
20 февраля 2017 в 20:38
0↑
↓
Сегодня же, ASP.NET Core, если верить бенчмаркам, входит в тройку-пятерку лучших по производительности веб-фреймворков на Linux.
Ну допустим пока на 10-м месте. Ну неужели php опережает, причём значительно, что удивительно. Однако количество ошибок — 1,272 — настораживает. Java пока тоже опережает по скорости. Но всё равно очень интересно, допилили бы mono до вменяемого состояния: многих удобств .Net или VS ещё нет.20 февраля 2017 в 22:02
0↑
↓
Так и mono и .net core развиваются и берут друг у друга лучшее;-)
-
Tantrido
20 февраля 2017 в 23:12
–1↑
↓
Через ж… конечно делали: Java изначально кроссплатформенная и таких проблем не имела, а моно кучу лет допиливают и всё никак до вменяемого состояния не дойдёт. Может хоть с net core ситуация изменится.20 февраля 2017 в 23:23 (комментарий был изменён)
0↑
↓
Java изначально кроссплатформенная
А т.е. я могу ее запустить даже на iOS?
Моно — это опенсорс, за которым не стояли гиганты вроде Microsoft, Oracle или Sun. Он развивался силами Xamarin с прицелом на мобильные платформы.
20 февраля 2017 в 22:05
0↑
↓
10 место в рейтинге отдачи статики!
jugru вообще совести не имеют.
Еще пару недель назад публиковали пост о 10 месте, которое всего лишь за статику — то есть мягко говоря этот рейтинг никому не инересен…
А уже сегодня пишут 3–5 место…
kekekeks
20 февраля 2017 в 23:04
0↑
↓
Там основной прирост не сколько от рантайма, сколько от нормальных веб-сервера и конвеера обработки запросов. На Mono тоже достаточно шустро работает.
