C++-техрадар: что разработчики действительно готовы брать в работу

В мае на конференциях C++ Russia и HolyJS мы предложили участникам оценить технологии, инструменты и инженерные практики, с которыми они работают или за которыми следят. Так появились данные для двух технических радаров: по экосистеме C++ и по JavaScript.

Сырые цифры сами по себе рассказывают немного, поэтому мы отдали результаты на разбор эксперту. Виктор Новиков, руководитель группы разработки в «Лаборатории Касперского», посмотрел на распределения голосов и поделился своим мнением, почему CMake уверенно побеждает, а PostgreSQL раскалывает аудиторию пополам. В этой статье — его анализ C++-части исследования. Про техрадар JavaScript мы расскажем в другой статье.

Посмотреть радар и принять участие в голосовании можно на странице проекта.

Откуда взялись данные и как устроен радар

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

Участники оценивали каждую технологию по четырем категориям. Adopt: используем и считаем надежным рабочим выбором. Trial: готовы пробовать в реальных задачах, но пока с оглядкой. Assess: технология интересна, за ней стоит следить и ее стоит изучать. Hold: сейчас не рекомендуем внедрять или развивать без веской причины.

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

Важная оговорка: Hold не обязательно означает, что инструмент плохой. Он может не подходить конкретному типу проектов, требовать слишком дорогого перехода, относиться к другой области разработки или просто не входить в повседневный контур большинства опрошенных. В случае с плюсами это особенно заметно, ведь он используется в очень разных сферах: embedded, бэкенд, десктоп, финтех, игры, highload, системная разработка, библиотеки, внутренние инструменты. Поэтому считать такой радар просто списком победителей и проигравших было бы неправильно.

В нашем случае голосовали в основном C++-разработчики. По каждой технологии есть как итоговое кольцо, так и распределение голосов по четырем вариантам. И вот эти распределения интереснее финальной оценки. Если у технологии 90% голосов в Adopt, то это настоящий консенсус. Если Adopt и Hold идут почти рядом, перед нами раскол аудитории. Это значит, технология сильно зависит от контекста применения.

Именно в расколах радар становится по-настоящему любопытным. Git, Linux и код-ревью в Adopt мало кого удивят. А вот почему PostgreSQL делит аудиторию пополам, CMake побеждает, а Bazel оказывается в Hold — уже живой разговор о том, как C++-разработка устроена на практике.

C++-повседневность: что почти все считают базой

Самая скучная часть радара оказалась самой показательной. В уверенный Adopt попали Git, Linux, CMake, Bash, GDB, VS Code, код-ревью, юнит-тесты, интеграционные тесты, статический анализ и CI/CD. Обычный рабочий набор, без которого проект трещит по швам. Цифры говорят сами за себя: Git набрал 103 голоса в Adopt из 106, Linux — 99 из 103, код-ревью — 105 из 117, юнит-тесты — 98 из 112. Если команда пишет на C++ без Git, ревью и тестов, вопрос уже в том, как этот проект вообще выживает.

Заметно, что сильный Adopt собирается вокруг простого цикла: написал код, собрал, проверил, отладил, отправил на ревью, прогнал в CI. Git закрывает историю и совместную работу, CMake — сборку, Linux с Bash и GDB — среду, автоматизацию и отладку. Тесты, статический анализ и CI/CD следят, чтобы изменения не разваливали проект, а ревью остается человеческим фильтром, который пока сложно заменить автоматикой.

Радар получился очень в духе языка: в других экосистемах часть этих решений идет из коробки или хотя бы выглядит стандартизованной. В C++ рабочую среду почти всегда приходится собирать из разрозненных деталей: компиляторы, платформы, флаги, ABI, зависимости, старый код, странные окружения, разные IDE и CI. Поэтому инструменты, дающие хоть какую-то опору, быстро становятся необходимыми.

CMake набрал 88 голосов в Adopt из 102. Его знают, поддерживают IDE, под него написано огромное количество проектов, он нормально встраивается в CI и привычен разработчикам. О синтаксисе и наследии можно спорить долго, но когда нужно собрать реальный проект на нескольких платформах, CMake остается самым понятным общим знаменателем.

Похожая история с Bash. Он набрал 87 голосов в Adopt из 101. Bash не выглядит как технология, которую хочется торжественно заносить в радар, но он присутствует везде: скрипты сборки, запуск тестов, подготовка окружения, простая автоматизация, glue code между инструментами. В C++-проектах достаточно много такой бытовой инженерии. Она не попадает в красивые архитектурные схемы, зато или каждый день экономит время, или, наоборот, его отнимает.

VS Code и GDB тоже в сильной зоне: 85 голосов из 104 и 83 голоса из 102 соответственно. Любопытна сама связка легкости и универсальности. VS Code не претендует на роль единственно правильной среды для C++, зато его легко поставить, расширить и приспособить к проекту. GDB старый и местами суровый, однако для связки Linux и C++ это базовый инструмент выживания: когда что-то падает не там, не сразу и только под нагрузкой, красивые абстракции заканчиваются и наступает время отладчика.

Код-ревью, юнит- и интеграционные тесты, CI/CD и статический анализ получили сильную поддержку по понятной причине: плюсы не прощают хаос. Ошибка может жить долго, проявляться странно, зависеть от платформы, сборки, оптимизаций или срока жизни объекта. Зрелые команды могут ставить несколько сеток подряд: тесты ловят одно, статический анализ другое, ревью третье, а CI хотя бы гарантирует, что все это запустится.

Code coverage на этом фоне выглядит осторожнее: 60 голосов в Adopt, 20 — в Trial, 13 — в Assess и 18 — в Hold. И это здраво. Покрытие показывает, куда тесты вообще заходили, но молчит о том, проверили ли они важное. В плюсах легко получить красивый процент и все равно пропустить ошибку владения памятью, гонку или хитрый платформенный баг.

JSON и Markdown тоже попали в уверенную рабочую зону. На первый взгляд мелочь, но именно на них держится коммуникация между людьми и инструментами: JSON живет в конфигурациях, API, тестовых данных и промежуточных форматах, Markdown — в README, документации и заметках к проекту. Без этой обертки проект превращается в набор знаний, которые существуют только в головах пары старожилов.

Если обобщить, сильный Adopt в этом радаре означает недоверие к магии. C++-разработчики голосуют за воспроизводимость: возможность собрать проект, понять чужой патч, отловить падение, прогнать тесты и не держать весь процесс на честном слове.

Стандарты, сборка и зависимости: где C++ осторожен

В стандартах языка заметен почти каноничный переход: что уже стало базой, а что переживает ранний этап становления. C++17 выглядит самым спокойным вариантом: 78 голосов в Adopt из 97. Многие команды уже прошли боль перехода, обновили компиляторы, привыкли к возможностям языка и перестали считать стандарт чем-то новым.

C++20 тоже попал в Adopt, но картина мягче: 62 голоса — Adopt, 16 — Trial, 9 —Assess и 9 — Hold. Стандарт явно в работе, хотя еще не у всех. Кому-то мешают старые компиляторы, кому-то платформы, а кто-то попросту не видит смысла тащить новые возможности ради самих возможностей. Для части проектов C++20 все еще требует проверки на своем коде, сборке и ограничениях.

С C++23 интереснее: 38 голосов — Adopt, 17 — Trial, 21 — Assess и 20 — Hold. Если смотреть только на максимум голосов, победил Adopt. Распределение рассказывает другую историю: часть сообщества пробует, часть изучает, а часть не спешит. Честнее назвать это ранней стадией перехода, чем победой стандарта.

C++26 ожидаемо оказался в Assess: 6 голосов — Adopt, 9 — Trial, 23 — Assess и 24 — Hold. Для будущего стандарта нормальная картина: за ним следят, его обсуждают, прикидывают, что может пригодиться, но в реальную работу массово не несут. Между «стандарт принят» и «можно спокойно использовать в проде» в плюсах всегда лежит длинный путь.

На другом конце C++14: формально 66 голосов Adopt из 93, но при этом 25 — Hold. Классический пример старой базы, которая одних все еще устраивает, а других уже тормозит. В больших легаси-проектах C++14 остается стабильным компромиссом, однако после C++17 или C++20 возвращаться к нему неприятно: многие привычные способы выразить мысль требуют заметно больше кода.

Boost в похожей зоне: 61 голос — Adopt, 10 — Trial, 2 — Assess и 26 — Hold. Когда-то Boost был почти лабораторией будущего плюсов, откуда идеи попадали в стандарт и формировали привычки разработчиков. Сегодня отношение изменилось. В одних проектах Boost закрывает реальные задачи и давно встроен в кодовую базу. В других его воспринимают как тяжелую зависимость, от которой хочется держаться подальше, особенно если можно обойтись стандартной библиотекой или более узким инструментом.

Со сборкой ситуация еще жестче. Сильный Adopt у CMake показывает, насколько миру плюсов нужен общий язык сборки. Результаты Bazel, Conan и vcpkg показывают, как трудно этот язык заменить или расширить.

Bazel получил 77 голосов Hold из 96. У него есть сильные стороны: масштаб, воспроизводимость, кэширование, монорепозитории, строгие зависимости. Но за них приходится платить высокой ценой входа: менять устройство проекта, привычки команды, CI, локальную разработку, иногда даже само мышление о зависимостях. Если у команды уже есть CMake со своими скриптами, пакетами и набором платформ, Bazel выглядит лишним усложнением.

Пакетные менеджеры тоже не получили доверия по умолчанию: у Conan — 19 голосов Adopt и 45 голосов Hold, у vcpkg — 11 голосов Adopt и 58 — Hold. На бумаге они решают всем известные боли: зависимости, версии, сборку под разные платформы, бинарные артефакты. На практике у каждой команды свои компиляторы, флаги, ABI, патчи, внутренние библиотеки и требования к поставке и безопасности, и универсальное решение быстро упирается в локальную специфику.

Здесь хорошо видна разница между пользой и принятием технологии. Пакетный менеджер может быть отличным выбором в новом проекте и почти невозможным в старом. Bazel способен спасти огромный монорепозиторий и задавить небольшую команду. CMake может раздражать, оставаясь при этом самым дешевым способом договориться с людьми, IDE, CI и платформами. С плюсами так часто бывает: побеждает инструмент, который можно внедрить без остановки проекта. Сообщество не отвергает новые сборочные системы и менеджеры зависимостей, просто знает, что цена перехода в C++ почти всегда выше, чем кажется из презентации.

Инфраструктура и платформы: где начинается контекст

С инфраструктурой картина резко меняется. Linux и Docker выглядят как часть базового набора: 99 голосов Adopt из 103 и 74 голоса из 99 соответственно. Связка понятная: Linux для C++ служит средой сборки, отладки, тестов и продакшена, Docker добавляет воспроизводимость: можно зафиксировать окружение и не обучать каждого нового разработчика особым заклинаниям установки.

Дальше начинается контекст: PostgreSQL собрал 42 голоса Adopt и 39 — Hold, почти пополам. Для бэкенд-команды база данных — обычная часть продукта. В embedded, SDK, десктопном приложении, компиляторе или библиотеке она зачастую вообще не входит в зону ответственности C++-разработчика.

Windows делит аудиторию похожим образом: 53 голоса Adopt и 43 — Hold. Для одних это целевая платформа с пользователями, драйверами, Visual Studio и реальной работой. Для других, особенно в бэкенде, Windows просто не та среда, где живет продукт. macOS уходит в контекст еще сильнее: 36 голосов Adopt и 55 — Hold. В C++ лишняя платформа редко бывает бесплатным дополнением: каждая тянет за собой компиляторы, системные API и отдельные классы проблем.

С инструментами разработки та же логика. VS Code и GDB легко встраиваются в разные сценарии, поэтому оба в уверенном Adopt. Visual Studio получила 44 голоса Adopt и 56 — Hold: в мире Windows/C++ она может быть главным рабочим местом, а в Linux-first-проекте вокруг CMake, Clang, GCC и консольной автоматизации превращается в лишний инструмент.

WinDbg на этом фоне выглядит несправедливо обиженным: 18 голосов Adopt и 79 — Hold. На мой взгляд, это один из лучших отладчиков для Windows, особенно когда речь заходит о дампах и системных проблемах. А TTD там вообще выглядит как магия: в моей практике были кейсы, где возможность откатываться назад по исполнению реально спасала часы, а иногда и дни расследования.

Плюс WinDbg заметно развивается и уже смотрит в сторону сценариев за пределами классического Windows-only-мира, умеет подключаться к gdbserver и открывать линуксовые корки. Хочется верить, что со временем WinDbg сможет на равных спорить с GDB в части Linux-проектов. Но пока для большинства C++-разработчиков это все еще не ежедневный инструмент, а что-то из параллельной реальности.

Kubernetes, Terraform, Vault, ClickHouse и Nix собрали много Hold: у K8s — 58 голосов из 97, у Terraform — 64 из 78, у Vault — 75 из 102, у ClickHouse — 79 из 100, у Nix — 49 из 67. Это не бойкот инфраструктуры: мне кажется, разработчики просто не хотят считать ее частью своей основной работы по умолчанию. Команде, которая пишет сервисы и сама отвечает за эксплуатацию, K8s, Vault и Grafana нужны каждый день. Тому, кто пишет библиотеку, низкоуровневый компонент, GUI или embedded, тащить их в каждый проект незачем.

WSL, QEMU, VMware, VirtualBox и Wireshark тоже зависят от сценария. WSL полезен Windows-разработчику, которому нужен Linux-like workflow. QEMU важен в embedded, виртуализации и системной разработке. Wireshark незаменим там, где есть сеть, протоколы и странные интеграционные проблемы. Общим стандартом эти инструменты не становятся из-за слишком специфических точек применения.

Закономерность простая: чем ближе технология к циклу «сборка, запуск, проверка, отладка», тем больше согласия. Linux и Docker помогают почти всем, поэтому они в базе. PostgreSQL, Windows, K8s, Terraform, Vault, QEMU, Wireshark и Grafana бывают критически важны, но только в конкретных проектах. Радар как раз показывает, насколько сильно применение зависит от домена.

Спорные технологии

Самое интересное живет там, где консенсус не достигнут. По результатам видно, что C++ объединяет несколько разных профессий под одним синтаксисом.

Хороший пример — feature flags: 46 голосов Adopt и 39 — Hold. В сервисной разработке это почти гигиена: можно выкатывать изменения постепенно и отключать опасные ветки. В библиотеке, embedded-прошивке или продукте с редкими поставками флаги превращаются в лишние ветвления, которые надо тестировать и помнить. Похожая история с телеметрией и Grafana: сервису, живущему в проде 24/7, наблюдаемость необходима. При этом в проектах другого типа это чаще всего ответственность соседней команды.

Dependency injection расколол аудиторию: 41 голос Adopt и 44 — Hold. Где-то DI помогает тестировать код и развязывать компоненты. Где-то быстро вырастает в фабрику фабрик, за слоями которой прячется реальная логика. В C++ цена такой абстракции высока: усложняется сборка, замедляется компиляция, отладка становится труднее.

Monorepo получил 42 голоса Adopt и 57 — Hold. С хорошими инструментами монорепозиторий дает атомарные изменения, общий граф зависимостей и единые правила сборки. Без них превращается в чемодан без ручки, набитый лишним. Для плюсов это особенно болезненно, потому что сборка и зависимости в языке и так непростые.

Fuzzing и динамический анализ ушли ближе к Assess: у фаззинга 27 голосов Adopt, 16 — Trial, 23 — Assess и 45 — Hold, у динамического анализа 33 голоса Adopt и 49 — Hold. Дело не в отношении к качеству, базовые практики как раз в Adopt. Просто надо эти инструменты встраивать в процесс, разбирать находки, бороться с шумом и поддерживать окружение.

С языками вокруг C++ работает та же логика. Си все еще держится рядом с системным уровнем и embedded, но 30 голосов в Hold выдают усталость от наследия. Rust получил 10 голосов Adopt, 7 — Trial, 19 — Assess и 62 — Hold: между интересом и внедрением встают сборка, обучение команды и вопрос, что именно мы переписываем и зачем. JavaScript и PowerShell полезны в своих мирах, но для большинства C++-разработчиков остаются инструментами по необходимости.

Общая закономерность спорной зоны: чем сильнее технология требует совпадения процесса, домена и культуры команды, тем больше разброс голосов. Feature flags, DI, monorepo, телеметрия, Rust, Qt, фаззинг и Architecture as Code бывают отличными решениями, если попали в правильную задачу и правильную команду.

Что в итоге показал радар

C++-сообщество голосует за контроль. В сильном Adopt оказались технологии, которые каждый день помогают писать, собирать, проверять и отлаживать код: Git, Linux, CMake, тесты, ревью, CI/CD, GDB, Bash. Сенсации не случилось, зато получился честный портрет разработки на языке, где цена ошибки высока, а магия заканчивается при первом падении под нагрузкой.

Hold при этом не список отстающих. Terraform, Vault, ClickHouse, Nix, K8s, WinDbg, Rust и JavaScript могут быть отличными на своем месте, просто они не выбор по умолчанию для всей аудитории. Уместность здесь ключевое качество: C++-разработка слишком разнообразна, чтобы одна технология одинаково хорошо ложилась на бэкенд, embedded, десктоп, системный код и библиотеки.

Самые полезные результаты дали расколы. PostgreSQL, Windows, feature flags, dependency injection, monorepo, телеметрия, Wireshark, Visual Studio показывают, насколько разными бывают проекты на одном языке. Эти технологии где-то база, а где-то лишний слой, способный все усложнить и даже сломать сборку.

Напомним, что текущий радар — срез по ответам участников C++ Russia. Чем больше разработчиков примет участие в следующей волне голосования, тем точнее будут видны различия между направлениями C++-разработки и тем надежнее будет итоговая картина.

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