Перенести банковское приложение на Flutter в одиночку и сохранить свои нервы: миссия невыполнима?

Дмитрий, Flutter-разработчик DexSys, в кроссплатформенной мобильной разработке уже больше 3х лет. В этой статье расскажем, как он переносил функционал банковского приложения с нативного на кроссплатформу, поделимся проблемами, вставшими на пути, и заглянем внутрь проекта «Мобильный банкир». Передаем слово Диме:)

«Пара слов о продукте:

Мобильный банкир — это система дистанционного обслуживания клиентов. Позволяет отслеживать заявки на доставку банковских продуктов или документации.

МБ работает на двух платформах:

Мобильное приложение для сотрудников или партнёров банка — обеспечивает процесс доставки.
Web-приложение, в котором можно настроить систему и мониторить доставку.

Команда проекта: 1 product owner, 2 системных аналитика, 3 back-разработчика, 1 front-end разработчик, 1 iOS/Android разработчик, 2 тестировщика, 1 flutter-разработчик, 1 собственный специалист поддержки пользователей.

Зачем нужна кроссплатформа?

Бизнес-заказчик дал нашей команде задачу не увеличивая количество человек уменьшить время на реализацию и выпуск идей/обновлений.

Технический лид проекта увидел во Flutter-е возможность для увеличения скорости разработки. Сначала команда проверила эту гипотезу на разработке зарплатного проекта для внешних агентов банка. Далее, с помощью разработчика Flutter начали выравнивать сроки разработки для Web-версии и мобильного приложения.

Так что же такое Flutter, и с чем его едят?

Flutter уверенно занимает ТОП-1 в кроссплатформенных языках. Он сокращает время на разработку, и, соответственно, на доставление продукта конечному пользователю. Если говорить бизнесовым языком, то «скорость выше и платишь меньше».

Едят Flutter вместе с языком Dart. На вкус такой же аппетитный, как и JavaScript.

Начав писать на Flutter, можно прочувствовать на себе следующие моменты:

Нервные клетки исчезают гораздо реже;
Появляется больше свободного времени;
Повышается самооценка:)

Чуть больше деталей:

Под капотом свой графический движок Skia и рантайм Dart VM. Написано на C/C++. Соответственно, запускать код ты можешь прямо из консоли, без всяких IDE`шек;
Очень хорошо поддерживаются 2 платформы – iOS/Android, чуть меньше – WEB, и потихоньку встает на ноги поддержка MacOS/Windows/Linux.

Как переводил? С чего начинал?

Я пришел на проект, когда нативные версии были в проде уже более 5-ти лет. А flutter-копия только училась ходить — был написан функционал одной роли. Всего в приложении их три:

Курьеры: доставляют банковские продукты
Кредитные специалисты на административных пунктах и сотрудники в банковских отделениях - осуществляют выдачу дистанционно одобренных продуктов

Архитектура:

Изначально я хотел переписать всё на BLoC, так как это чистая и всеспособная архитектура. Но любовь к трудностям победила — я решил оставить текущую реализацию, MobX.

Для начала я отрефакторил структуру папок, переписал некоторый код для лучшей производительности и приступил к двухфакторке. Она необходима для верификации пользователя и для нее используются стандартные http запросы.

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

Привести мысли в порядок помогли размышления о том, что у Flutter большое растущее комьюнити и наверняка для grpc-запросов уже есть готовые библиотеки. И я не ошибся! Мои нервные клетки сохранились:)

Но ненадолго… Вскоре после переписывания функционала, в связи с безопасностью тестовых сред, grpc-запросы отменили. Пришлось откатывать все обратно до http-запросов.

Функционал ролей

Если вам когда-либо потребуется работать с распределением ролей, рекомендую использовать абстракцию. Благодаря ей:

сильно сокращается время багофиксов и изменений;
один элемент может использоваться в 5-ти местах, не нарушая функциональность каждого из них

Но продумать такую абстракцию за раз невозможно, поэтому лучше привести виджеты к универсальному виду, так как они могут понадобиться в новых ролях. А если это невозможно, то поделить на разные виджеты. Ведь универсальность — это, конечно, хорошо, но и чистоту кода нужно сохранять.

Решением стал MobX. На нём можно сделать «обозреваемый геттер», который будет смотреть и следить за заданными условиями. Если условие поменялось – геттер сразу его подхватит и обновит информацию. Так мы оставляем чистый код и не переносим все условия на UI.

Перенос функционала курьеров:

В приложении курьеру нужно иметь карту с пакетами и список пакетов и договоров на доставку. По каждому договору нужны:

Детальная информация
Договоренности
Реквизиты новой карты
Печатные документы
Фото клиента
Фото залога и чек-листа
Фото основного пакета документов

Расскажу подробнее о некоторых пунктах:

Реквизиты:

На этом этапе реализовали для курьеров возможность ввести банковский счет, где мы используем overlay.

Печатные материалы:

У dart’а есть возможность запускать ссылки. Просто вставляешь в метод (launchUrl) диплинк для почты и вуаля: для того, чтобы отправить печатные материалы на почту, нужно нажать всего одну большую кнопку по центру экрана – трудно промахнуться.

Фото клиента/залога/документов:

Этот функционал используется для идентификации клиента. Основная задача заключалась в том, чтобы сделать единую, но при этом адаптивную схему фотографирования, так как UI и техническая часть не везде одинаковые. Также у самих фотопакетов могли различаться состояния.

Решение: Разграничили state на следующие части: у каждого фотопакета есть своя view model с одинаковой структурой, у каждого сегмента/формы — отдельный state, в котором хранится основная информация по сегменту/форме + специфическое взаимодействие с сервером.

Таким образом, мы получаем примерно такую структуру:

PackageDetails -> ClientPhotoSegment -> ClientPhotoStore -> ClientPhotoVM.

Также, в приложении «Мобильного банкира» есть функционал обращений. Каждый из пользователей приложения может задать любой интересующий вопрос тех. поддержке, скорость ответа на который особенно важна для выездных курьеров. В переписке должна быть реализована возможность выбрать готовые темплейты, помогающие быстрее получить ответ, и, для того чтобы UI не выглядел деревянно,— нужно была анимация.

Решение: за ним далеко идти было не нужно, т.к. из коробки Flutter у нас уже есть подходящий SliverAnimatedListView

Что в итоге?

Убедившись в положительном результате, за 11 месяцев мы переписали все функциональные блоки приложения, которые команда писала на нативных приложениях с 2016 года, и, несмотря на сложности в процессе переноса, скорость разработки оказалась в 2 раза выше чем у нативных версий, а нервные клетки команды стали исчезать гораздо реже.

Таким образом, мы освободили еще и ресурс тестировщика — теперь не нужно тестировать две платформы. Появилось время на автотестирование и улучшение процессов.

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

Рекомендации всем, кто хотел бы вникнуть во Flutter:

1) Очень советую пробежаться по официальной документации, ибо она написана какими-то невероятными гениями.

2) Можно глянуть ютуб канал разработчиков.

3) Ну и напоследок: чистая архитектура + BLoC понятным языком»