Мобильное приложение KoronaPay уникально по трем аспектам:
Даже на этапе MVP в приложениях была выбрана архитектура, которая позволяла добавлять новые возможности, быстро реагировать на изменения. Разработчики понимали, что нужно выйти на рынок быстро, но все равно проинвестировали усилия в создание надежной базы. Время выиграли на переиспользовании наработок из приложений, которые уже существовали в компании.
Еще одно решение — минимизация количества сторонних решений в приложениях. «Денежные переводы» создается уже шесть лет, и по планам компании будет существовать еще долго. Команда разработчиков говорит, что не может положиться на third party со временем жизни в три-четыре года.
Стек технологий выбирается таким образом, чтобы минимизировать внешние зависимости и обеспечить максимальную безопасность приложения. Для iOS это Swift и SDK, для Android — Kotlin, Coroutine и Jetpack Compose.
Приложение «Денежные переводы» единое для всех стран. Поэтому с точки зрения разработки оно адаптировано к финансовым системам в разных странах. Где-то популярны переводы по реквизитам на банковский счет. Где-то люди привыкли получать переводы наличными или зачислять на карты национальных или международных платежных систем.
В некоторых странах закон требует, чтобы пользователь подтверждал личность каждый раз, когда достигает лимита по переводам. Все это нужно учитывать на этапе работы над фронтом и бэком приложения: добавлять системы списания и «приземления» денежных средств, модули для распознавания документов пользователя.
Особое внимание при разработке уделяется безопасности сервиса. Кроме службы информационной безопасности в этот процесс вовлечены и разработчики. Для этого создана инициатива Security Ninja. Фактически, Security Ninja — это игровая форма подхода к SDLC-разработке.
За активное участие разработчики получают Ninja Coins, которые обменивают на особый мерч. Он подчеркивает то, что сотрудники помогли усилить безопасность продукта. Для некоторых разработчиков роль Security Ninja — это возможность расширить свой кругозор и инженерные навыки в ситуациях, когда им кажется, что они уже достигли своего максимума и стремиться более не к чему.
Типовая команда состоит из семи человек. Это два Android-разработчика, два iOS-специалиста, тестировщик, бэкенд-разработчик и бэкенд-тестировщик. Такой юнит сбалансирован и способен выполнить задачу полностью. Но есть и целиком платформенные команды, состоящие, например, только из Java-разработчиков. Такие команды могут прийти на помощь, если фича требует доработок на платформе, или берут те задачи, где не нужны изменения в мобильных приложениях.
Каждый специалист может развиваться горизонтально и вертикально. Это значит наращивать техническую экспертизу в смежных платформах, становиться T-shape специалистом, либо углубляться в рамках своей платформы и становиться техлидом. Перейти из одной роли или команды в другую также возможно — для этого в компании существуют внутренний конкурс вакансий и карьерное консультирование. Все зависит от желания и возможностей человека.
Эти задачи имеют понятную бизнес-ценность и направлены на развитие продукта. Инфраструктурные команды тесно работают с командами разработки, выявляют потребности в инструментах, формируют архитектурные подходы для дальнейшего развития приложения, поддерживают конвейеры CI/CD. Задачи у таких команд направлены на повышение технического совершенства продукта и инструментов.
Источник: devby.io