Привет! Я — Дмитрий Коркин, CEO Joy Dev и бывший iOS-разработчик. Давно, конечно, не кодил… Но стараюсь поддерживать технические скиллы. В этой статье я собрал тренды и бессмертную классику в финтех разработке, а также рассказал про своё видение идеального мобильного приложения для банков.
Постараюсь не душнить, но пойду от самой базы в глубину и покажу ТОП-10 технологий, которые мы с коллегами внедряли последние несколько лет. Посмотрим, что из этого вышло!
1. Yamaha среди архитектур
Гадюка подус��ала, тренд на VIPER отошёл в прошлое, как что-то неповоротливое, и оброс большим числом зависимостей. MVVM и MVP — уже какой-то олдскул. Но MVVM (+ C) и MVP (+C) вырываются вперёд словно Yamaha. И всё благодаря Clean-архитектуре и удобному быстрому в разработке паттерну с координатором.
Офтопик: Впервые я познакомился с MVP на проекте UBERа ещё на старом, но не добром Objective-C. Это было в 2013 или 2014 году. Не только жив курилка, но ещё и обматёрил.
Поэтому MVVM с трендом Apple кажется, да и не только кажется, — самая популярная архитектура мобильной разработки.
2. PODS организация и 3rd party решения
Использовать 3rd party решения просто как есть — подобно смерти в хакерской войне. Что тогда можно сделать? Всё просто: форк версии, рефакторинг и адаптация open source решений под нужды банка. Да, товарищи разрабы, теперь вы — настоящие защитники критической инфраструктуры. Так что без факапов, ребята! А если вы не льёте в мастер, значит, у вас уже есть свои велосипеды для работы с сетью, шифрования клиентских данных, DI и так далее.
Dev Pods всегда отлично работали, при этом их можно предкомпилировать в статические зависимости, закешировать и носить за собой, а обновлять только в случае необходимости, например, когда вносятся правки в основной POD.
3. DI и Scaffolding
Кодогенерация модуля, автогенерация или шаблон модуля — всё про одно и тоже. Никто уже не регистрирует сервисы при старте приложения сразу на контейнер в координаторе. Вместо это есть модное Assembly, которое применяется при варке модуля. Да, надо сделать так, чтобы подменялась реализация и с легкостью отлаживалась на моковых данных. Продвинутые ребята могут применять ИИ еще на этапе аналитики, чтобы генерировать API и модели по описанию и документации, как это делает GRPC, существенно сокращая время разработки при дальнейшей поддержке. Да и никто не мешает идти дальше и составлять модели и обработку.
4. Тестирование
Пальма первенства принадлежит snapshot-тестам, а процент покрытия Unit-тестами уже не так важен. Snapshot тестирование на два размера экрана и две темы устраняет множество болей. А TBD и всякие старые подходы Kiwi для тестирования контекста, пожалуй, только вдохновили на что-то великое, но сами куда-то пропали с радаров best-практик.
5. Кеширование пользовательских данных
Быть или не быть, вот в чём вопрос… Если всё же быть, тогда нужно писать шифрованные обертки для сохран��ния на файловую систему или UserDefaults. Но можно вполне хранить данные на оперативе или обновлять через реактивные хранилища (Reactive Storage). Всякое видали.
Ещё в начале своих аудитов приложений и на заре становления Storyboards я всем говорил, что это ерунда, которая замедляет сборку и усложняет командную разработку и мерджи. Надо мной, конечно, часто смеялись и и иногда даже спрашивали, что я курю. Ведь это же Apple создали и рекомендуют! Это правда, но почему-то многие забывали, что они же придумали использовать в основе MVC архитектуру, а первые проекты с ViewController были от 1000 строк кода. А ещё и SwiftUI, чтобы больше людей могли писать сомнительный код с точки зрения производительности и масштабирования.
6. Сборка проекта
Здесь буду краток: следует следить за структурами и протоколами. А когда использование класса даёт большую производительность на выходе, чем структуры? Да, проект в проект — это как пакет с пакетами.
7. BackEnd DrivenUI
Эту технологию точно используют топовые банки. И не зря, ведь она полезна сразу в нескольких аспектах:
Маскировка приложения;
С Feature Toggle прекрасно дружит для АB тестирования;
Подходит для нелинейных и поведенческих воронок (иначе говоря, теперь мы точно знаем, кому и как нужно показать предложение по кредиту).
Для BackEnd DrivenUI есть два варианта реализации:
HTML-нотации — дёшево и очень популярно среди редакторов, например, для табличной вёрстки. Тем более базовых HTML-парсеров очень много.
Slack-нотации — изящно и дорого, но зато со своим мета-программированием и большим количеством часов для написания своего движка по сборке UI.
Для ТОП-5 банков на самом деле штука весьма нужная, этот ваш бекенд дривен ЮаЙ! Он обеспечивает гибкость в управлении интерфейсом и оперативное внедрение новых функций. А если вы ещё не перешли на этот подход — пишите мне. Разберём все подводные камни.
Также я уверен, что разработчики должны дружить как с бизнесом, так и с маркетингом. Иначе зачем вообще нужен продукт, если его метрики не отслеживаются, а конверсия не повышается? Поэтому советую не считать, например, AB-тесты, Remote Feature Toggles, геймификацию или сегментацию — лишней магией. Они помогают продукту расти.
8. Оптимизация UI
Да, банк – это не TikTok, но я считаю, что следить здесь за FPS, отслеживать метрики и работу анимаций стоит хотя бы раз в квартал. И если вы делаете такие съёмы в комплекте с прогоночными тестами и скриптами — это очень хорошо и значит, что вы — почти гуру iOS-разработчик!
9. Качество кода SwiftLinter
Мы в Joy Dev топим за качество кода, поэтому шкодерам можно и МР подпортить, автофиксы предложить или что подсветить. Всё, зависит от уровня гуманности и толерантности Core-команды.
10. Распространение в сторы
Нынче есть проблемка, для которой одной маскировки, увы, не хватает, важно ещё и пройти ревью. И тогда на помощь приходят обфусцированные скрипты, которые помогут подменить приложение банка на калькулятор. И это избавляет не только от боли с выгрузкой в сторы, но и от ряда других, связанных с дизассемблированием кода или потенциальными атаками в виде инъекций.
Итого
В мобильном банкинге тренды сменяются так быстро, что можно подумать, будто попал в супермаркет со скидками — хочется схватить всё и сразу! В этой статье я рассмотрел лишь верхушку айсберга, но даже она полна крутыми практиками, которые уже применяют крупные компании. Так что берите на вооружение и адаптируйте под свои задачи. А ещё делитесь своими мыслями или идеями в комментариях — обсудим, кто что использует или только планирует.
