Привет! Я — Дмитрий Коркин, 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. Распространение в сторы
Нынче есть проблемка, для которой одной маскировки, увы, не хватает, важно ещё и пройти ревью. И тогда на помощь приходят обфусцированные скрипты, которые помогут подменить приложение банка на калькулятор. И это избавляет не только от боли с выгрузкой в сторы, но и от ряда других, связанных с дизассемблированием кода или потенциальными атаками в виде инъекций.
Итого
В мобильном банкинге тренды сменяются так быстро, что можно подумать, будто попал в супермаркет со скидками — хочется схватить всё и сразу! В этой статье я рассмотрел лишь верхушку айсберга, но даже она полна крутыми практиками, которые уже применяют крупные компании. Так что берите на вооружение и адаптируйте под свои задачи. А ещё делитесь своими мыслями или идеями в комментариях — обсудим, кто что использует или только планирует.
