company_banner

Немного технической лирики о C++ Tools от JetBrains, и при чем тут единороги

    Начну не с моего типичного “Привет, Хабр! У нас тут очередной крутой релиз”, а с “Привет, меня зовут Настя, я ПММ в JetBrains и я отвечаю за наши инструменты для C++”. Или нет, попробую еще раз, вот так: “Привет, пишет вам C++ разработчик с 8-летним стажем, который 5 лет назад нашел-таки себе применение в любимой и знакомой компании мечты – JetBrains, а потом в сутках внезапно закончились часы, а идеи всё прут”.

    Нет, это не традиционный пост о поисках кандидатов на вакансию. Я попытаюсь рассказать про то, почему инструментов для 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 гарантирован!
    JetBrains
    519,50
    Делаем эффективные инструменты для разработчиков
    Поделиться публикацией

    Комментарии 40

      0
      Спасибо за интересную статью! ️
        +1
        Рада, что понравилось. Не проходи мимо — приводи заинтересованных друзей) Нам очень нужны люди!
        +3
        В общем, у нас и продуктов несколько, и парсеров много.

        Распыляете ресурсы, получается? :)

        работаю с девелопер-адвокатами и сообществом.

        Прочитал штук пять статеек и ответов на вопрос «кто такой developer advocate», но так и не понял. Зато я теперь точно знаю: человек, который в суде распинается перед присяжными, что программист не виновен в багах — это НЕ девелопер-адвокат.
          +1
          Ну, продукты разные, архитектуры разные, да и парсеры разные пробуем. Задача ведь не свой самый любимый парсер холить и лелеять, а сделать лучшее решение для конечного пользователя. А тут без экспериментов никак!

          Девелопер-адвокатов мы раньше называли евангелистами, но как-то нам все же хотелось в названии позиции больше «девелоперского», потому что это так и есть про этих людей.
            +3
            С евангелистами-то как раз понятнее было: ежели человек с нездоровым блеском в глазах топит за какую-то технологию — это он, сектант-евангелист. Здрасьте, проходите к микрофону, а чтобы было удобнее, мы вам рукавчики на спинке завяжем…
              0
              У нас вся команда такая ;) Да что там, вся компания!
          0
          Картинка «Because C++» видать по мотивам: «Потому что, гладиолус !»

          Раз у вас в дальнейшем будет углубляться поддержка embedded, то планируется ли какая-либо интеграция с системами Mender, SWUpdate, RAUC и прочими системами firmware update?
            0
            Пока в первых планах самые общие задачи по embedded. Дальше будем более конкретно смотреть. Можно создать реквест тут и мы рассмотрим.
            Elmot может что-то еще добавит?
              0
              Нет, на данный момент вряд ли добавит. Заводите тикеты, плюсуйте их, самые популярные будем имплементировать.
              0
              Про картинку, там долгая история) Но полностью текст с because C++ видно на промо-видео (если кликнуть по картинке — там ссылка на YouTube).
              +8
              Хм, я уж было подумал, что Вы про единорога PVS-Studio будете рассказывать.
                0
                Постоянно пользуюсь CLion, но почти не видно развития среды. Разве что проекты с каждом релизом грузятся всё дольше и дольше.

                Вот вы говорите, что метите в embedded, но в то же время никак не запилите поддержку Makefiles (уже 5 лет обещаете), не говоря уже про другие системы сборки (до поддержки какого-нибудь IAR я думаю, что и не доживу даже).
                  0
                  Забавно, а некоторые пользователи нам наоборот говорят, что все слишком быстро меняется) И движок альтернативный на кланге появился, и remote dev режим добавился, и профиляторы появились, и кстати про проектные модели — compilation database. Это все за последний год где-то.

                  Makefiles сейчас можно использовать через compilation database. Вот здесь небольшой туториал. Планируется в ближайшее время такой подход еще чуть автоматизировать, чтобы меньше надо было руками делать.

                  IAR тоже в планах, может и в этом году даже, как elmot будет успевать)
                    0
                    а некоторые пользователи нам наоборот говорят, что все слишком быстро меняется
                    Да где ж быстро? Почти пять лет не можете исправить относительно тривиальный баг.
                      0
                      Баг платформенный и не такой тривиальный. Там даже было пару попыток с патчами, но они все создавали больше проблем, чем решали. Но мы еще раз посмотрим, в чем там конкретно проблема. Спасибо за напоминание.
                  0
                  На linux вариантов не много- а зачем их должно быть много? Хотя таки там достаточно IDE на все вкусы и случаи жизни.Я вот искренне пытаюсь понять, зачем все это, зачем постоянно какие то новые стандарты программирования, какие то новые инструменты? Не изобрети велосипед, как говорится.Что вы можете предложить, к примеру такого, чего нет в qt creator?
                    0
                    Когда я говорила, что на Linux вариантов не много, я как раз к тому, что там мало хороших альтернатив. Qt Creator действительно одна из лучших.
                    Если сравнивать с qt creator, то рефакторинги, которых гораздо больше, код анализ, который умеет показывать гораздо больше всяких проверок, чем просто ошибки компиляции и clang analyzer / clang-tidy (хотя и они тоже есть), больше действий навигации (go to symbol / base class / derived class), больше опций кодогенерации, ну и множество функционала из платформы — от встроенного VCS и local history до разнообразных плагинов (Rust, например, или Vim-emulation mode).

                    А новые стандарты языка они придумываются, потому что разработчикам нужны языковые средства, которых еще нет в языке, поэтому они пишут библиотеки, а потом пытаются это стандартизировать, чтобы все работали с общим/единым подходом, а не каждый со своей библиотекой локальной. Инструменты же обычно создаются для облегчения каких-то ежедневных задач, когда вы устаете делать одну и ту же задачу постоянно вручную.
                      0
                      К сожалению на больших проектах (несколько миллионов строк кода) Clion практически перестает работать, а QtCreator бегает довольно шустро.
                        0

                        Подтверждаю… Пользуюсь одновременно CLion и QtCreator… Стараюсь при этом сидеть на EAP и репортить в багтрекер всё что мешает. Только последнее время почти всё что сообщаю оказывается дубликатами уже известных проблем…
                        При этом не ощущается, что CLion становится быстрее. На большом проекте банальное переключение Header/Source может занять… целых 10 минут, А Find References зависнуть, намекая о внеплановом кофе или даже обеде.


                        А при открытии cpp-ков с тестами (gtest) IDE вообще умирает.

                          0
                          Switch header/source платформенный экшен, который надо переделать по-другому (с учетом C++ специфики). Оно in progress) Надеюсь, будет уже в 2019.2

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

                            Спасибо. Будем надеяться :)


                            А еще просто жутко бесит, что CLion может в фоне непонятно что делать (даже без уведомления в Background Tasks). Даже сборка в CLion раза в два замедляется по сравнению со сборкой в терминале… Типа такого: https://youtrack.jetbrains.com/issue/CPP-15627


                            И да, нет нативной поддержки ninja в 2019 году :(

                              0
                              Да уж, отсутсвие ninja, кроме как через custom build target, удручает. Даже в Visual Studio! ninja работает из коробки.
                                0
                                С ninja история в том, что если поддерживать Ninja генератор, то нам не хватает информации нужной в получаемых файлах. Есть вариант через CMake server их поддержать и мы думали так сделать, но пока просто банально ресурсов на такую задачу не хватает.
                                  0

                                  У вас уже есть поддержка compile_commands.json. Сделайте гибридный какой-то режим в виде cmake -GNinja -DCMAKE_EXPORT_COMPILE_COMMANDS=1.
                                  Чтобы хотя-бы была возможность выбирать цели для сборки.

                                    0
                                    Можно сейчас и так сделать Custom Build Target, который будет использовать -GNinja, а потом Custom Run/Debug Configuration, чтобы запускать сборку таргета с Ninja.
                                      0

                                      Тут проблема в том что эти цели нужно создавать руками (что не очень удобно). Плюс теряются удобные фишки в виде запуска тестов просто из контекстного меню CPP-ка (не зная даже Build Target-а)

                                        0
                                        Так а чем гибридный режим поможет?
                                          0

                                          Если хотя бы список целей заполнится уже плюс будет большой…

                                            +1
                                            Да, соглашусь. У нас вообще есть идея как это поскорее заимплементировать. Осталось ресурс на это найти (человеческий =) ).
                                              0
                                              «Нет, мы не распыляемся, мы эспериментируем!» (ц) :)))
                                                0
                                                Ну, есть языковая часть команды. Им надо экспериментировать, иначе тулинг не будет улучшаться. А есть люди, которые отвечают за другие компоненты. Кажется, это понятная структура для любого разработчика)
                                    0
                                    Интересно как он в Visual Stuio работает, через CMake Server?

                                    Если будете делать CMake Server, постарайтесь оставить текущее окошко «Projects» без изменений. То как оно сделано в QtCreator (показывает только файлы из CMake проекта) не удобно, постоянно приходится переключаться между «Projects» и «File System».
                                      0
                                        0
                                        Да, это как раз вариант, который мы хотем попробовать вместо имплементации CMake server ;)
                                        0
                                        Я не уверена, что VS парсит аутпут генератора в случае CMake + Ninja. Сложно сказать.
                                      0
                                      На тикет про сборку посмотрим еще раз. Вообще не должно быть такого, конечно. Заводите такие вещи в трекере, заранее спасибо.
                            0
                            Тыкал палочкой CLion пару лет назад. Во-первых, на кодовой базе хромиум (CentOS 7.2, 8 core, 32 Gb) он умер. Во-вторых, проект поменьше он распарсил через 15 минут, но лагает даже при передвижении курсора. В-третьих на темплейтном коде он подчёркивает полностью всё после ошибки. Нетбинс все проекты поднимает на раз и там можно свободно работать. Кстати, у них свой парсер, он понимает примерно 80% с++14/17 кода и не тормозит. Если апач не сольёт с++ плагин, то лучше ничего не надо.
                              0
                              Netbeans C++ увы всё, не развивается. Eclipse CDT тоже полумертвый. Вся надежда на clangd.
                                0
                                Хромиум — это и правда тяжко пока, но это самое «худшее», что можно открыть в C++ IDE, с точки зрения перфоманса) Такой референсный тест. Мы у нему стремимся, безусловно.

                                Сейчас кстати я уверена, что с шаблонами там все ок, потому что красится код нашим вторым парсером на базе Clangd.

                                Парсер в NetBeans все же не так хорош, как вы себе это представляете. И да, у нас работает человек из NetBeans команды, делает как раз парсер на базе Clangd. NetBeans до закрытия всего добра в Апач именно туда тоже и двигался.
                                0

                                Вчера слушал запись твоего интервью в видеоформате. А теперь оно ещё и текстом. Спасибо!

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое