Нет, это не традиционный пост о поисках кандидатов на вакансию. Я попытаюсь рассказать про то, почему инструментов для C++ у нас несколько и какие есть идеи и планы у нас на их счет, а еще почему вы не забудете C++, если перестанете писать на нем как разработчик, а станете PMM-ом (спойлер, если вы не член комитета стандартизации языка C++, то у вас большие шансы узнать язык даже лучше). А если после этого вам захочется поучаствовать в этом в роли PMM-а, то я буду рада вашим резюме на anastasia.kazakova@jetbrains.com.
Почему нельзя просто так взять и сделать IDE для C++?
Многим кажется, что из компилятора языка C++ очень легко сделать парсер для IDE. На конференциях ACCU, C++Now и CppCon пару лет назад я стала рассказывать, почему все не так просто. Например, можно посмотреть записи с 2017 года с ACCU (A look at C++ through the glasses of a language tool) и CppCon (New standards to the rescue: the view through an IDE’s glasses). Основные тезисы: чем умнее среда, тем тяжелее в случае C++:
- поддерживать хорошую производительность (и отзывчивость) редактора,
- уметь работать с некорректным кодом (компилятору-то что — он просто ошибку выдаст и прекратит работу), и
- “думать” не в единицах трансляции (TU), а в масштабах всего проекта (потому что Rename вы хотите именно контекстного символа, а не просто совпадающего по имени, и именно на всем проекте).
Так что в далеком 2014 году у нас зародились не одна, а целых 2 (или даже правильнее сказать 3) среды для разработки на C++. Причем все случилось довольно внезапно. Просто мы делали Objective-C в AppCode, а потом оказалось, что мы пишем парсер C++. И понеслась! Эту забавную историю, кстати, я рассказала в интервью на недавно прошедшей в Москве конференции C++ Russia 2019:
В итоге, часть команды решила делать IDE на основе платформы IntelliJ Platform — CLion. А другая часть стала реализовывать иной подход в другой архитектуре — ReSharper C++, расширение для Visual Studio. А потом еще появился дополнительный парсер на базе clangd. В общем, у нас и продуктов несколько, и парсеров много.
Трехголовый дракон, и как его продавать
При этом у наших продуктов для C++ несколько разная аудитория.
CLion — ориентирован на кросс-платформенную разработку на C++, то есть на тех, кто хочет запускать IDE на нескольких платформах (включая Linux, где вариантов вообще немного). Это отдельностоящая полнофункциональная среда, в которой множество интеграций (напрямую и через плагины, как сторонние, так и наши) с другими инструментами (Valgrind Memcheck, Google Sanitizers, DTrace, Perf, Conan) и языками (Python, Rust, Swift, Kotlin/Native). Именно в CLion мы сейчас работаем в сторону поддержки рынка Embedded-разработки. IDE популярна в финансовом секторе, на рынке разработки self-driving cars и других областях. Недавно нас даже показали в рекламе BMW.
ReSharper C++ — расширение для Visual Studio, предназначено для тех, кто занимается разработкой в Windows-окружении и ориентируется на соответствующий тулчейн (msbuild, MSVC). Здесь мы не пытаемся реализовывать те возможности, которые и так есть в Visual Studio, но стараемся сделать более удобной, быстрой и продуктивной работу с кодом, особенно с современным C++. Поэтому в продукте много классных гиковских фич, которые могут сделать вас гуру разработки на C++. Сейчас можно заметить активную работу, которую мы делаем в ReSharper C++ в сторону поддержки разработчиков игр на Unreal Engine. Это вполне логично, так как основная аудитория таких игр разрабатывает именно на Windows, в MS-окружении. Поэтому мы занялись оптимизацией производительности и специальными возможностями именно для игр на UE4.
Также C++ поддержка из CLion присутствует в AppCode (где она, собственно, и зародилась) и Android Studio (которую делает Google на основе нашей платформы IntelliJ Platform).
А чтобы это все как-то объяснять пользователям, мы придумали маркетинговую кампанию, которую назвали Because C++. Если вы хоть раз видели наш стенд на конференциях по C++, или смотрели записи с конференции C++Now (которую мы поддерживаем как видеоспонсоры), или брали в качестве раздатки зеленые бутылочки или значки C++, вы точно поймете, о чем речь:
А что же единороги?
Единорог на всем этом разнообразии сейчас один — это я. Если вы еще не знакомы с концепцией “единорог в JetBrains”, то вот вам пост от abreslav, в котором довольно точно описывается позиция PMM в JetBrains. А еще мы когда-то вложили много сил (душевных и физических) в PMM Summer School и осознали многое про себя, пока рассказывали другим, кто мы и что мы делаем. paullarionov вот тут на Хабре рассказывал, как это было (заодно есть ссылки на слайды лекций). Взгляд участника не из JetBrains, если кому интересно.
Я человек не из маркетинга изначально. Пришла в JetBrains из разработки на С/C++: 5 лет в embedded-аутсорсе, 3 года в Yota/Roox/Scartel (названий много, суть одна) делала PCRF и оптимизировала все, что плохо летало (а потом писала про это на Хабре), а потом вдруг… На самом деле, с C++ я меньше пересекаться не стала. Я, конечно, не пишу на нем готовые коммерческие системы, но копаюсь в тонкостях языка, ломаю поддержку в IDE вместе с нашими доблестными QA, потом описываю это все в блогах продуктов. Оцениваю, насколько технические писатели хорошо описали тот или иной сценарий использования очередной фичи, постоянно общаюсь с конечными пользователями (то есть разработчиками на C++) и показываю им всякие “интересные случаи”. Обсуждаю планы продукта и текущие проблемы с командой, работаю с девелопер-адвокатами и сообществом. К тому же, мы стали более тесно общаться с комитетом по стандартизации и ездить на его встречи. А еще я люблю поговорить про C++ и его экосистему на конференциях и организую встречи сообщества C++ в Питере.
Но на продуктах для PMM-а есть и менее технические задачи — рекламные кампании, подготовки конференций, различные маркетинговые материалы и прочее. Это все тоже сейчас в моем постоянно растущем TODO-листе.
Если вы дочитали до этого места и поняли, что работа мечты, вероятно, вот тут совсем рядом с вами, то у нас есть две вакансии, которые по сути про одно и тоже. Я не планирую покидать JetBrains, но время в сутках стремительно заканчивается, поэтому мне нужна еще одна голова, которая поможет мне реализовывать множество существующих идей и принесет нам новые идеи. Задачи будут во многом по ReSharper C++ и, конечно, общие тоже. Because C++, как у нас говорят ;)
P.S. Пишите смело вопросы в комментарии — я люблю отвечать на Хабре!
И приходите, будет весело! The Drive to Develop гарантирован!
Комментарии (40)
berez
13.05.2019 19:51+2В общем, у нас и продуктов несколько, и парсеров много.
Распыляете ресурсы, получается? :)
работаю с девелопер-адвокатами и сообществом.
Прочитал штук пять статеек и ответов на вопрос «кто такой developer advocate», но так и не понял. Зато я теперь точно знаю: человек, который в суде распинается перед присяжными, что программист не виновен в багах — это НЕ девелопер-адвокат.
anastasiak2512 Автор
13.05.2019 19:54+1Ну, продукты разные, архитектуры разные, да и парсеры разные пробуем. Задача ведь не свой самый любимый парсер холить и лелеять, а сделать лучшее решение для конечного пользователя. А тут без экспериментов никак!
Девелопер-адвокатов мы раньше называли евангелистами, но как-то нам все же хотелось в названии позиции больше «девелоперского», потому что это так и есть про этих людей.berez
13.05.2019 20:23+2С евангелистами-то как раз понятнее было: ежели человек с нездоровым блеском в глазах топит за какую-то технологию — это он, сектант-евангелист. Здрасьте, проходите к микрофону, а чтобы было удобнее, мы вам рукавчики на спинке завяжем…
KonstantinSpb
13.05.2019 21:43Картинка «Because C++» видать по мотивам: «Потому что, гладиолус !»
Раз у вас в дальнейшем будет углубляться поддержка embedded, то планируется ли какая-либо интеграция с системами Mender, SWUpdate, RAUC и прочими системами firmware update?anastasiak2512 Автор
14.05.2019 00:18Пока в первых планах самые общие задачи по embedded. Дальше будем более конкретно смотреть. Можно создать реквест тут и мы рассмотрим.
Elmot может что-то еще добавит?
Elmot
14.05.2019 09:42Нет, на данный момент вряд ли добавит. Заводите тикеты, плюсуйте их, самые популярные будем имплементировать.
anastasiak2512 Автор
14.05.2019 00:19Про картинку, там долгая история) Но полностью текст с because C++ видно на промо-видео (если кликнуть по картинке — там ссылка на YouTube).
moncruist
14.05.2019 00:26Постоянно пользуюсь CLion, но почти не видно развития среды. Разве что проекты с каждом релизом грузятся всё дольше и дольше.
Вот вы говорите, что метите в embedded, но в то же время никак не запилите поддержку Makefiles (уже 5 лет обещаете), не говоря уже про другие системы сборки (до поддержки какого-нибудь IAR я думаю, что и не доживу даже).anastasiak2512 Автор
14.05.2019 00:31Забавно, а некоторые пользователи нам наоборот говорят, что все слишком быстро меняется) И движок альтернативный на кланге появился, и remote dev режим добавился, и профиляторы появились, и кстати про проектные модели — compilation database. Это все за последний год где-то.
Makefiles сейчас можно использовать через compilation database. Вот здесь небольшой туториал. Планируется в ближайшее время такой подход еще чуть автоматизировать, чтобы меньше надо было руками делать.
IAR тоже в планах, может и в этом году даже, как elmot будет успевать)
borisxm
15.05.2019 10:15а некоторые пользователи нам наоборот говорят, что все слишком быстро меняется
Да где ж быстро? Почти пять лет не можете исправить относительно тривиальный баг.anastasiak2512 Автор
15.05.2019 14:39Баг платформенный и не такой тривиальный. Там даже было пару попыток с патчами, но они все создавали больше проблем, чем решали. Но мы еще раз посмотрим, в чем там конкретно проблема. Спасибо за напоминание.
Bratak
14.05.2019 06:41На linux вариантов не много- а зачем их должно быть много? Хотя таки там достаточно IDE на все вкусы и случаи жизни.Я вот искренне пытаюсь понять, зачем все это, зачем постоянно какие то новые стандарты программирования, какие то новые инструменты? Не изобрети велосипед, как говорится.Что вы можете предложить, к примеру такого, чего нет в qt creator?
anastasiak2512 Автор
14.05.2019 06:49Когда я говорила, что на Linux вариантов не много, я как раз к тому, что там мало хороших альтернатив. Qt Creator действительно одна из лучших.
Если сравнивать с qt creator, то рефакторинги, которых гораздо больше, код анализ, который умеет показывать гораздо больше всяких проверок, чем просто ошибки компиляции и clang analyzer / clang-tidy (хотя и они тоже есть), больше действий навигации (go to symbol / base class / derived class), больше опций кодогенерации, ну и множество функционала из платформы — от встроенного VCS и local history до разнообразных плагинов (Rust, например, или Vim-emulation mode).
А новые стандарты языка они придумываются, потому что разработчикам нужны языковые средства, которых еще нет в языке, поэтому они пишут библиотеки, а потом пытаются это стандартизировать, чтобы все работали с общим/единым подходом, а не каждый со своей библиотекой локальной. Инструменты же обычно создаются для облегчения каких-то ежедневных задач, когда вы устаете делать одну и ту же задачу постоянно вручную.
Daffodil
14.05.2019 18:06К сожалению на больших проектах (несколько миллионов строк кода) Clion практически перестает работать, а QtCreator бегает довольно шустро.
dion
14.05.2019 21:44Подтверждаю… Пользуюсь одновременно CLion и QtCreator… Стараюсь при этом сидеть на EAP и репортить в багтрекер всё что мешает. Только последнее время почти всё что сообщаю оказывается дубликатами уже известных проблем…
При этом не ощущается, что CLion становится быстрее. На большом проекте банальное переключение Header/Source может занять… целых 10 минут, А Find References зависнуть, намекая о внеплановом кофе или даже обеде.
А при открытии cpp-ков с тестами (gtest) IDE вообще умирает.
anastasiak2512 Автор
15.05.2019 01:15Switch header/source платформенный экшен, который надо переделать по-другому (с учетом C++ специфики). Оно in progress) Надеюсь, будет уже в 2019.2
Вообще перфоманс — это самая клавная сейчас задача. Там много всего большого переделывается, в том числе архитектурно, чтобы принципиально вопрос решить. При этом в каждом релизе есть какие-то улучшения, видимо просто вам пока не везет( Надеюсь, до вас улучшения тоже скоро дойдут!dion
15.05.2019 10:26Спасибо. Будем надеяться :)
А еще просто жутко бесит, что CLion может в фоне непонятно что делать (даже без уведомления в Background Tasks). Даже сборка в CLion раза в два замедляется по сравнению со сборкой в терминале… Типа такого: https://youtrack.jetbrains.com/issue/CPP-15627
И да, нет нативной поддержки ninja в 2019 году :(
Daffodil
15.05.2019 13:16Да уж, отсутсвие ninja, кроме как через custom build target, удручает. Даже в Visual Studio! ninja работает из коробки.
anastasiak2512 Автор
15.05.2019 14:44С ninja история в том, что если поддерживать Ninja генератор, то нам не хватает информации нужной в получаемых файлах. Есть вариант через CMake server их поддержать и мы думали так сделать, но пока просто банально ресурсов на такую задачу не хватает.
dion
15.05.2019 14:54У вас уже есть поддержка compile_commands.json. Сделайте гибридный какой-то режим в виде
cmake -GNinja -DCMAKE_EXPORT_COMPILE_COMMANDS=1.
Чтобы хотя-бы была возможность выбирать цели для сборки.anastasiak2512 Автор
15.05.2019 15:01Можно сейчас и так сделать Custom Build Target, который будет использовать -GNinja, а потом Custom Run/Debug Configuration, чтобы запускать сборку таргета с Ninja.
dion
15.05.2019 15:05Тут проблема в том что эти цели нужно создавать руками (что не очень удобно). Плюс теряются удобные фишки в виде запуска тестов просто из контекстного меню CPP-ка (не зная даже Build Target-а)
anastasiak2512 Автор
15.05.2019 15:06Так а чем гибридный режим поможет?
dion
15.05.2019 15:10Если хотя бы список целей заполнится уже плюс будет большой…
anastasiak2512 Автор
15.05.2019 15:20Да, соглашусь. У нас вообще есть идея как это поскорее заимплементировать. Осталось ресурс на это найти (человеческий =) ).
berez
15.05.2019 15:47«Нет, мы не распыляемся, мы эспериментируем!» (ц) :)))
anastasiak2512 Автор
15.05.2019 17:41Ну, есть языковая часть команды. Им надо экспериментировать, иначе тулинг не будет улучшаться. А есть люди, которые отвечают за другие компоненты. Кажется, это понятная структура для любого разработчика)
Daffodil
15.05.2019 15:38Интересно как он в Visual Stuio работает, через CMake Server?
Если будете делать CMake Server, постарайтесь оставить текущее окошко «Projects» без изменений. То как оно сделано в QtCreator (показывает только файлы из CMake проекта) не удобно, постоянно приходится переключаться между «Projects» и «File System».Daffodil
15.05.2019 15:50Смотрели ли вы на cmake.org/cmake/help/v3.14/manual/cmake-file-api.7.html?
anastasiak2512 Автор
15.05.2019 17:42Да, это как раз вариант, который мы хотем попробовать вместо имплементации CMake server ;)
anastasiak2512 Автор
15.05.2019 17:44Я не уверена, что VS парсит аутпут генератора в случае CMake + Ninja. Сложно сказать.
anastasiak2512 Автор
15.05.2019 14:45На тикет про сборку посмотрим еще раз. Вообще не должно быть такого, конечно. Заводите такие вещи в трекере, заранее спасибо.
yuriv
14.05.2019 21:24Тыкал палочкой CLion пару лет назад. Во-первых, на кодовой базе хромиум (CentOS 7.2, 8 core, 32 Gb) он умер. Во-вторых, проект поменьше он распарсил через 15 минут, но лагает даже при передвижении курсора. В-третьих на темплейтном коде он подчёркивает полностью всё после ошибки. Нетбинс все проекты поднимает на раз и там можно свободно работать. Кстати, у них свой парсер, он понимает примерно 80% с++14/17 кода и не тормозит. Если апач не сольёт с++ плагин, то лучше ничего не надо.
Daffodil
14.05.2019 22:20Netbeans C++ увы всё, не развивается. Eclipse CDT тоже полумертвый. Вся надежда на clangd.
anastasiak2512 Автор
15.05.2019 01:18Хромиум — это и правда тяжко пока, но это самое «худшее», что можно открыть в C++ IDE, с точки зрения перфоманса) Такой референсный тест. Мы у нему стремимся, безусловно.
Сейчас кстати я уверена, что с шаблонами там все ок, потому что красится код нашим вторым парсером на базе Clangd.
Парсер в NetBeans все же не так хорош, как вы себе это представляете. И да, у нас работает человек из NetBeans команды, делает как раз парсер на базе Clangd. NetBeans до закрытия всего добра в Апач именно туда тоже и двигался.
merhalak
14.05.2019 21:43Вчера слушал запись твоего интервью в видеоформате. А теперь оно ещё и текстом. Спасибо!
paullarionov
Спасибо за интересную статью! ?
anastasiak2512 Автор
Рада, что понравилось. Не проходи мимо — приводи заинтересованных друзей) Нам очень нужны люди!