userver — что мы узнали за полгода в open-source

Прошло больше полугода с момента выхода фреймворка для C++ 🐙 userver в open-source. За это время мы многое узнали, на многом настрадались, а главное — получили много приятных сюрпризов.

И мы решили об этом написать. Рассказ будет полезен тем, кто ведёт или планирует вести свой open-source проект или занимается контрибьютами. Остальным будет интересно почитать про чужое набивание шишек и что вообще open-source даёт проекту.

Неожиданная помощь

Чтобы анонс о выходе фреймворка в open-source прошёл более гладко, мы выложили исходники чуть заранее и плотно занялись обустройством на GitHub: настройкой CI, оформлением, тестированием и выкладкой документации. В итоге ко времени анонса у нас уже был готовый к использованию шаблон сервиса на основе фреймворка userver со всеми настроенными CI и сборками.

Однако, чего мы совсем не ожидали, так это то, что репозиторий с исходниками найдут ещё до анонса. Совсем неожиданно, что некоторые сторонние разработчики нашли нетривиальные места для оптимизаций глубоко в недрах драйверов и подсказали более производительные решения. Мы ответили им той же монетой: в течение нескольких часов неожиданно всё улучшили и выразили благодарности в changelog.

Beta — это хорошо

Потребности компании зачастую совершенно не совпадают с пожеланиями пользователей из open-source. То, что успешно используется годами в продакшене внутри компании, может не подойти новому пользователю из-за фактора, которого просто нет в корпоративной среде.

Мы ожидали, что понадобятся доработки после выхода в open-source, но не догадывались, что именно запросят наши новые пользователи. Разумеется был и технический долг: некоторые вещи требовали доработки, но было непонятно, какие именно долги больше всего мозолят глаза.

Чтобы подчеркнуть, что мы знаем, что есть над чем работать, мы выложили фреймворк в статусе беты. Решение себя оправдало: многие сообщения от пользователей попадали под регулярку «А как вы вообще выкладываетесь без технологии s+. А, хотя это бета, тогда ОК!»

Анонс

Итак, анонс.

Для нас было важно из анонса понять основные боли при попытке воспользоваться фреймворком, основные пожелания по развитию и осознать, что мы упустили. Ну и показать себя с лучшей стороны, конечно же.

Разумеется, не обошлось и без курьёзов. Например, мы отдали в отдел PR материал с общим посылом: «Сегодня мы анонсируем выход в open-source фреймворка userver для создания высоконагруженных IO-bound приложений на C++». Материал после некоторых трансформаций отправился в публикацию как «Анонсируем выход первого в мире набора инструментов, который позволяет создавать высоконагруженные приложения». К счастью, удалось вовремя остановить процесс.

У нас есть доска с от руки нарисованными ачивками за сомнительные достижения — эта появилась как раз после этой истории

C++ сборка — это очень, очень мучительно

Первое, с чем стали приходить люди после анонса выхода в open-source — проблемы со сборкой.

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

И тут мы простого решения для open-source не придумали, поэтому пошли по сложному пути: поддержать по мере сил и возможностей все конфигурации, которые интересны нашим активным пользователям. Отдельное спасибо тем, кто принёс готовые правки под свои любимые платформы!

Roadmap и Changelog

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

Показать, что мы настроены серьёзно, помогло следующее:

• Настройка автоматической синхронизации коммитов из внутреннего репозитория на GitHub. В результате, зайдя репозиторий, можно увидеть, что последний коммит сделан ~2 часа назад. Это знак того, что проект активно развивается.
• Changelog. Смысл тот же, что и у прошлого пункта — показать темпы развития проекта.
• Roadmap. Помогает людям понять, что у проекта есть план развития, мы движемся в сторону релиза и он близок.
• Каналы поддержки в Telegram. Они позволяют нам прислушиваться к желаниям новых пользователей и оперативно дорабатывать фреймворк под их нужды.

Бенчмарки — это полезно

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

• Задачу для бенчмарка не получилось реализовать лаконично? Значит, что-то в интерфейсах фреймворка можно улучшить и обобщить, сделать приятнее в использовании.
• Проиграли в производительности? А что за решение у лидера? А, хм, занятно, попробуем сделать нечто похожее, но вот тут ещё подускорим...
• Всё хорошо, но сложно подобрать оптимальную конфигурацию? А ведь и не в бенчмарках люди с этим сталкиваются! Давайте делать автотюнинг параметров, чтобы конфигурировать намного меньше вещей.

Бенчмарки — это бесполезно

О, раз бенчмарки такие полезные, может фреймворк прям по ним и выбирать? Вот, например, нам в компании понадобился фреймворк на Go/Kotlin/NodeJS/… Давайте возьмём топовый из бенчмарков!

Идея интересная, но на практике не работает:

• Во многих фреймворках из топа есть уязвимости, и авторы не особо торопятся их исправлять, потому что починка ударит по производительности и результатам в бенчмарке.
• Все без исключения фреймворки в бенчмарках работают иначе, чем в проде. Например, во всех фреймворках отключается логирование, а оно весьма прожорливо на проде и крайне сильно влияет на времена ответов, latency и jitter.
• Многие фреймворки обладают минимальной функциональностью, только тем что необходимо для бенчмарка. Хотите поработать с другой базой данных, записать метрики или воспользоваться многопоточностью — не получится.

И наконец, мой любимый фактор — простота написания и поддержки кода. На каком из этих фреймворков вы хотели бы писать:

Документация

Нельзя просто взять и написать отличную документацию. В зависимости от настроения, задачи и предпочтений разработчикам нужны разные стили документации:

• Первое знакомство с проектом. Нужно описание используемых подходов, почему они эффективны и какие ограничения накладывают.
• Написание первых сервисов (или для нетерпеливого разработчика). Тут нужны туториалы с полноценными и понятными примерами кода.
• Для опытного пользователя. Нужна справочная часть, где расписаны детали различных методов и классов.
• Специфичная задача. Нужен раздел документации под конкретную проблему, советы и варианты подходов к решению задачи.

При этом все люди разные, и материалы желательно преподносить и в разных формах, например, как видео-лекции и как текст.

Документация — это не разовая задача. Надо прислушиваться к запросам пользователей и покрывать бо́льшим количеством примеров те части фреймворка, по которым возникают частые вопросы. Или же упрощать это место во фреймворке, чтобы вообще не надо было документировать.

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

Взаимовыгодное обучение

Отдышавшись после анонса и поправив основные недочёты, мы с запозданием осознали интересный момент. В Яндексе множество обучающих проектов, например, Школа бэкенд-разработки. Многие из этих активностей предполагают написание выпускной работы — некоторого игрушечного сервиса. Он знакомит студента с промышленной разработкой и в публичный доступ, как правило, не выкладывается.

Но ведь если хорошо поработал, хочется этим похвастаться! Показать код, указать строчку в резюме со ссылкой на сделанную работу.

Мы подключились к части инициатив с предложением: «А давайте выпускным проектом будет написание реального кода для userver». В итоге, если хорошо поработал, точно будет чем похвастаться и что показать.

Правда, тут возникли заминки: нас завалило кодом, и мы до сих пор занимаемся его подмерживанием в userver.

Кстати, оказалось весьма полезным разметить feature requests на GitHub как «Хорошая задача для начинающих» и отдельно разметить «Большая фича для продвинутых». Мы сразу получаем набор задач внешних активностей на 2—4 дня и набор проектов для больших многомесячных курсов, например, как «Код для всех».

Так зачем же open-source?

Вопрос: «А зачем вы выложили в open-source?» не даёт покоя многим людям в чатиках и на форумах. Ну что ж, давайте честно на всё ответим и разберём все мифы.

Миф 1: чтобы люди разрабатывали фреймворк за нас

Увы, это так не работает. Подавляющее большинство коммитов у нас идёт от внутренних разработчиков. Я, конечно, втайне надеюсь, что это изменится. Но, как показывает опыт с Boost C++ Libraries, даже очень популярные открытые проекты очень долго выходят на подобную модель развития и очень мало у кого получается.

При этом PR от стороннего пользователя — это маленький праздник! Ведь значит ещё кому-то проект стал интересен и полезен.

Миф 2: чтобы люди тестировали фреймворк за нас

Не без этого :) Но как и с разработкой, здесь подавляющее количество багрепортов идёт изнутри. Многие внешние багрепорты связаны со сборкой или функциональностью, которые в компании редко используется.

Если вдруг у вас небольшой проект с достаточно узкой функциональностью (например, небольшая библиотека), то open-source вам явно поможет лучше тестироваться. Для больших фреймворков всё несколько сложнее.

Для чего же userver выложили в open-source на самом деле

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

Для больших компаний open-source — это ещё и развитие технологического бренда компании. Так можно показать людям интересные и полезные решения, которые мы пишем в рабочее время. Ну и при найме это полезно: если вы вдруг выбираете между разными отделами Яндекса, у вас есть возможность заранее увидеть технологии, с которыми вы будете работать, и выбрать себе код по вкусу.

А ещё open-source даёт возможность использовать привычный набор инструментов в партнёрских проектах: например, теперь есть шанс воспользоваться userver при коллаборации с CERN, или при автоматизации сталелитейных заводов.

Ближайшие планы

Мы готовимся к первому релизу фреймворка в этом году. А пока релиз ещё в работе, мы с радостью готовы рассказать о фреймворке (и не только) на конференциях Saint HighLoad++ и HighLoad++ Serbia.

А если вам самим есть о чём рассказать, приходите к нам на C++ Zero Cost Conf с идеей доклада. У нас тепло, весело и международно! В этом году конференция пройдёт в двух странах — в России и в Сербии. Ждём ваши заявки!

P.S.

Спасибо всем, кто контрибьютил и багрепортил в userver. Вы лучшие!

Автор: Antony Polukhin

Источник