Red Hot Chili Apples’23

Red Hot Chili Apples — это ежегодное мероприятие, которое собирает в нашем уютном питерском офисе креативных ребят из ЮMoney и других крупных российских компаний. В этом году спикеры из Сбера и Вконтакте выступали у нас с докладами о платформенных командах и автоверсионировании. А ребята из ЮMoney рассказали о кодогенерации из OpenAPI и мобильных SDK.

Все приложения ЮMoney взаимодействуют с сервером через REST API. Есть модели данных, которые мы описываем сначала для бэкенда, затем — для всех клиентских приложений iOS и Android. Раньше данные нужно было описывать и тестировать вручную для каждого клиента. Это делали наши разработчики, что, естественно, занимало много времени. Но мы попробовали кодогенерацию из OpenAPI — и с тех пор всё изменилось. В своём докладе рассказываю, с какими проблемами ручной реализации мы столкнулись и как кодогенератор из OpenAPI помог нам сократить время генерации кода для всех клиентских приложений.

01:03 — С какими проблемами ручной реализации кода мы столкнулись в команде и что решили с этим делать
04:03 — Как выглядит OpenAPI-спецификация, что в ней можно описать и какие инструменты позволяют разработчику упростить работу с ней
05:41 — OpenAPI Generator: по каким критериям мы выбирали генератор, почему остановились на решении от OpenAPI Tools и как с ним работать
07:14 — Зачем нам понадобилась кастомизация: три причины
08:42 — Как работает OpenAPI Generator
09:34 — Как выглядит код генератора, который готов к использованию, и несколько методов, которые покажут, как легко сконфигурировать генератор или итоговый код
12:31 — Mustache-шаблон: что это такое и для чего он нужен
13:23 — Тестирование: как генератор избавил нас от необходимости писать тесты для каждого отдельного проекта и что мы делаем теперь
14:03 — Автоматизация: что можно автоматизировать и как это устроено в ЮMoney
15:40 — Итоги: у нас появился единый источник правды (спецификация), сократилось время реализации кода, мы выработали единый подход к работе с кодом API и документацией, автоматизировали процесс генерации

Сегодня в Сбере более 200 мобильных команд, 50 мобильных приложений и релизы продуктов каждые две недели. Первые годы мы работали в режиме стартапа, но бизнес рос очень быстро, фич становилось больше, разработчиков — тоже. Вместе с этим стали появляться проблемы в коммуникации: начались споры по поводу выбора стандартов разработки и переиспользования кода. Чтобы решить их, в Сбере сформировали платформенную команду, которая стала следить за скоростью попадания кода в текст сборки, за обновлением технологического стека, культурой комьюнити и многими другими вещами. В своём докладе рассказываю о компетенциях платформенной команды, об 11 ошибках, с которыми мы столкнулись в своей работе, и о том, чему они нас научили.

02:15 — Team Topologies: книга про платформенные команды, которую я рекомендую
03:42 — Как Сбер вырос из стартапа в корпорацию
04:37 — Что ждёт команды, которые стремительно растут
10:17 — Как в Сбере появилась платформенная команда и какие у неё задачи
14:12 — Компетенции платформенной команды
15:22 — 11 ошибок платформенной команды Сбера и чему они нас научили
28:39 — Результаты, которые принесли Сберу платформенные команды

Однажды я поймал в приложении баг, но не мог понять, из какой он версии. Три месяца у нас не было релизов, а я не помнил, когда поставил приложение на телефон — неделю или месяц назад. Нужно было решить вопрос версий приложения раз и навсегда, и сделать это нашей команде помогло автоверсионирование. Рассказываю, почему так важно отделять одну версию от другой, как в этом помогает автоверсионирование, в чём разница между маркетинговой и внутренней версией приложения и как сделать идеальную полную версию независимо от того, какие есть препятствия.

01:19 — Как выглядят маркетинговая, внутренняя и полная версия приложений iOS и macOS
02:15 — Как устроено базовое версионирование
02:40 — Какие требования к маркетинговой и внутренней версии у Apple
03:21 — Чего нет в требованиях Apple, но на что надо обратить внимание
07:15 — Зачем нужно версионирование и автоверсионирование
09:16 — Почему я считаю, что лучший формат привязан к дате коммита
11:04 — Критерии идеальной полной версии
12:37 — Варианты того, как сделать маркетинговую версию приложения
16:12 — Что может помешать нам сделать идеальную версию и как с этим быть
18:25 — Как выглядит идеальная внутренняя версия
20:16 — Имплементация, или Как сделать хорошо, чтобы переделывать пришлось только один раз
24:21 — Полезный код для разработчика

Для приёма платежей через ЮKassa мы разработали мобильное платёжное SDK. Оно содержит в себе необходимые сценарии и интерфейсы, чтобы наши клиенты могли как можно быстрее начать принимать платежи в своих приложениях. На скорость и простоту интеграции SDK влияет то, каким образом спроектировано API SDK, поддерживается ли API&ABI-совместимость, насколько удобна документация, существует ли наглядное демо-приложение.

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

А ещё в своём докладе я приведу пример использования дизайн-паттернов для упрощения восприятия API и поддержки его стабильности при добавлении нового функционала.

01:35 — Платёжный SDK ЮKassa: поддерживать как можно больше популярных менеджеров зависимости и иметь несколько способов интеграции
03:17 — Принципы в разработке, которые делают API проще
05:42 — Как мы применили эти принципы к нашему модулю токенизации
07:47 — Как мы использовали дизайн-паттерны для упрощения API
09:47 — Что такое демо-приложение, для каких SDK оно нужно и почему это необходимая фича
10:50 — SwiftUI-готовность
12:00 — Какие бывают форматы дистрибуции мобильного SDK
15:00 — Кастомизация: почему важно дать клиенту SDK, адаптированный под его фирменный стиль
16:05 — Опенсорс: почему в ЮKassa выбрали этот формат распространения SDK
17:20 — Как опубликовать код в опенсорсе и какие есть этапы публикации
19:57 — Документация к SDK: как должна выглядеть и какие разделы есть в нашей
22:05 — Итоги: идеи спринтов для разработчиков, которые делают SDK прямо сейчас