Red Hot Chili Apples’23

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

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

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

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

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

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

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

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

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

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

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