В 2018-м, когда с помощью Android Pay возможно оплатить даже шаверму, смартфон оказывается для пользователя главным финансовым инструментом. Теперь люди хотят решать с его помощью вообще все вопросы, связанные с деньгами. А значит, соответствующие мобильные приложения стали особенно актуальны.
У финансовых приложений, разработанных в компании ЦФТ для различных заказчиков, суммарное число установок исчисляется миллионами — то есть немногие могут похвастаться таким опытом в этой сфере. Воспользовавшись тем, что компания присутствовала на нашей конференции Mobius, мы задали руководителю группы разработки Android приложений Михаилу Емельянову несколько вопросов о том, как в ЦФТ выглядит Android-разработка.
— Для начала расскажите кратко о «ЦФТ» для тех, кто раньше не слышал этого названия.
— Компания работает на рынке финтеха уже больше 25 лет: когда она появилась, не было даже понятия «финтех», но уже тогда она производила продукты и сервисы, которые теперь называют именно так. Собственно, само название «Центр Финансовых Технологий», появившееся в начале 90-х, до сих пор остаётся актуальным и говорит само за себя.
Конечно, за прошедшее время многое изменилось (кто в 1991-м мог представить себе Android?), но суть осталась той же: ЦФТ развивает и разрабатывает IT-решения и технологические сервисы, которые делают простыми и удобными финансовые операции (в том числе денежные переводы и платежи).
Компания появилась в новосибирском Академгородке, и её главный центр разработки по-прежнему находится там. Но сейчас, кроме него, есть офисы во многих других городах России, а также в Кишинёве, Алматы и Душанбе. Рост продолжается: постоянно появляются новые сервисы и подразделения, активно развивается R&D-направление.
— А сколько человек занимаются конкретно мобильной разработкой, и можете ли привести примеры разработанных в ЦФТ приложений?
—У нас распределённая мобильная команда в Новосибирске, Томске и Санкт-Петербурге. Сейчас это более 50 человек, но планы в мобильной разработке у компании такие, что мы должны расти в два раза быстрее, чтобы им соответствовать.
Наши самые популярные приложения для iOS и Android — это «Денежные переводы» (более 1,3 млн скачиваний в Google Play), платёжные кабинеты карт «Билайн» и «Кукуруза».
Также более 100 кастомизированных мобильных приложений для iOS и Android есть у нашего провайдера онлайн-банкинга Faktura.ru. Всего командой Faktura.ru реализовано 340 проектов внедрения онлайн-банкинга для корпоративных и частных клиентов. А вообще на этой технологической платформе работают порядка 130 банков
— У работы с финансами есть своя специфика — чем Android-разработка в ЦФТ отличается от «среднестатистической» компании?
— Поскольку мы работаем с личными данными и финансами пользователей, одно из главных правил — строгие требования к защите информации. Мы регулярно имеем дело с такими темами, как обеспечение безопасности мобильного банкинга на уровне API и при передаче данных, биометрическая аутентификация, Keychain, SSL-пиннинг и т.д. Накопили много соответствующего опыта, поэтому на Mobius как раз и представили доклад «Основы безопасности мобильного приложения».
Но при этом мобильная разработка в финтехе не превращается в сплошное соответствие требованиям безопасности, оторванное от желаний живых людей. Конечными пользователями всё-таки являются миллионы обычных рядовых граждан. Сейчас все управляют со смартфона денежными операциями — оплачивают услуги, переводят деньги. И наши конечные продукты ориентированы именно на таких людей.
Поэтому в финтехе достаточно интересно заниматься как раз мобильной разработкой: там конечные пользователи — это, по сути, мы с вами. Так что приложения должны быть не только безопасными, но и простыми, максимально технологичными. Мы создаём не что-то в вакууме, а продукт для потребителя.
— Помимо защиты информации, вам ещё и нужно быть особенно стабильными: если у стартапа в продакшн могут пролезать ошибки, то от финансов ждут надёжности. Но при этом превратиться в медлительный «водопад» и согласовывать всё по полгода тоже нельзя. Как вы решаете эту задачу?
— В первую очередь архитектурным подходом. Мы приняли за стандарт идею чистой архитектуры, и её принципы отрабатываем на реальных приложениях. Новые приложения делаем в рамках деления на слои, одиночной ответственности и слабой связанности сущностей.
Профит: использование различных технологий без необходимости переписывать весь код, высокое качество за счет тестов, а главное — простая масштабируемость, что для нас очень важно.
Также у нас строжайшее кодревью, в нём участвует практически вся команда, и большинство сложных моментов мы засекаем именно на ревью-этапе, так что до продакшна они не доходят.
Ну и, разумеется, тестирование — практически везде всё покрываем юнит-тестами, часть разработчиков пишут код по методологии TDD. Конечно, UI не по TDD, но и о UI-тестировании тоже не забываем: совместно с командой тестировщиков поработали над тем, чтобы они как можно эффективнее использовали Espresso.
— Поскольку финтех требует консервативности, в каких-то случаях это может мешать использовать новые технологии. Поэтому интересно спросить так: что нового в Android вы попробовали за последний год? И какие технологии, кстати, вообще используете?
— Довольно многое пробуем. Когда Google выпустил версию Android Architecture Component, мы решили поэкспериментировать и внедрили её в один из новых проектов. Но наткнулись на грабли: например, не увидели в её ViewModel достаточно эффективного средства решения задачи жизненного цикла для нашего проекта. А вот LiveData нам показалась полезной для слоя представления.
После того, как результат AAC не оправдал ожидания, мы выпилили её, заменив более эффективным подходом. Благодаря чистой архитектуре нам не потребовалось переделывать все приложение, достаточно было доработать слой представления. Есть и другой пример с использованием новой ORM Room.
Мы сейчас активно разрабатываем на Kotlin. На Mobius многие задавались вопросом «почему повсюду Котлин», но это же напрашивается. Он даёт больше возможностей, чем Java, «из коробки»: кода стало гораздо меньше, функциональности — больше. Многое можно сделать одной строчкой кода, например, объявление классов. Сейчас также пробуем корутины в одном из проектов.
В общем, нам нравится, как Kotlin развивается, и радует, что его сообщество растет. А поскольку он стал настолько распространённым, сейчас, чтобы на нём не разрабатывать, надо иметь очень жёсткие убеждения и принципы.
А ещё мы используем RxJava/RxKotlin, популярные Retrofit и Dagger 2, гугловский Data Binding, планируем попробовать RxBinding, долго можно всё перечислять. В общем, финтех не мешает вовсю играться с различными технологиями.
— Вам Android Architecture Components не подошли — а можете ли при этом рекомендовать их другим? Насколько ресурсозатратна оказалась миграция на них: давно существующим проектам стоит думать об этом, или это лучше оставить новым?
— Хотя AAC и не оправдали наши ожидания, они хорошо решают некоторые задачи: например, сохранение и восстановление данных при смене ориентации экрана. Так что, если в проекте с кучей legacy-кода неэффективно реализована поддержка смены ориентации, то стоит задуматься об использовании AAC. Но внедрить это нахрапом не получится, предварительно нужно подготовить архитектуру, исправить критические ошибки и найти точки интеграции, чтобы не перерабатывать все приложение.
— Упомянутый выше Room — довольно свежая технология, которую многие ещё не успели попробовать. Поэтому интересно: каков оказался ваш опыт с ней?
— Room нас порадовал. С помощью аннотаций можно легко описать создание таблиц, определить транзакции и т.д. Есть встроенная поддержка Kotlin, Rx, LiveData. Из минусов в текущей стабильной версии (1.1.0) — отсутствие команд для очистки БД и необходимость настраивать связи вручную. Еще были неудобные мелочи при использовании Room в Kotlin, но они постепенно решились с выходом новых версий. Например, дефолтные методы Transaction в интерфейсах стали поддерживаться только в 1.1.0-alpha2.
В общем, с Room работать с базами данных стало гораздо удобнее и эффективнее.
— Есть точка зрения «все эти ваши ORM от лукавого, абстракции всё равно протекают и приходится спускаться на уровень SQL» — что вы думаете об этом?
— В любой технологии для решения нетривиальных задач приходится писать код, даже SQL. Главное, чтобы это не превращалось в оверхэд. В Room тоже можно писать SQL-запросы руками (например, миграция или сложные запросы), но через аннотации это делать значительно удобнее. Например, можно вытащить данные из нескольких таблиц при помощи Relation.
— Поскольку ЦФТ старше самого Android, для вас наверняка актуален вопрос легаси. Часто ли занимаетесь рефакторингом?
— Конечно, в любом проекте будет существовать legacy-код. Да и популярное утверждение «любой код, написанный сегодня, завтра становится legacy» вполне справедливо.
Так и у нас. Есть приложения, которые выпустили несколько лет назад. Если есть объективные причины менять весь код (баги, низкая масштабируемость, отсутствие эффективных технологий и т. п.), то мы делаем это. Проводим поэтапный рефакторинг, параллельно выпускаем фичи, где по компонентам, слоям или просто экранам осуществляется переработка кода.
Также и в использовании технологий. Например, в одном из наших проектов в качестве http-клиента использовали Volley. Технология не новая, и мы хотели перейти на OkHttp + Retrofit. Для этого мы проанализировали связи в проекте с rest-клиентом, подготовили архитектуру к переходу и за один раз переехали на него, не тратя на это много времени.
— У ЦФТ есть курсы, в том числе Android — а чему там учите? И чего, по вашему опыту, больше всего не хватает начинающим Android-разработчикам?
— Да, в ЦФТ есть несколько образовательных проектов. Для студентов младших курсов — Школа ШИФТ, в рамках которой мы провели курс базовой Android-разработки на базе НГУ. А для студентов старших курсов и джунов — проект Focus Start, где есть 6 разнонаправленных курсов, в том числе и мобильная разработка (Аndroid и iOS). В программе курса Android дают углубленные знания по Android, Java, Kotlin, Rx. Выпустили уже несколько наборов, некоторые из лучших выпускников стали нашими сотрудниками.
Зачастую начинающим Android-разработчикам не хватает опыта применения ООП, принципа SOLID. Некоторые не понимают отличие паттернов MVC – MVP – MVVM и принципов Clean Architecture, из-за этого неправильно понимают бизнес-логику.
Также встречаются пробелы в Android SDK, Java, понимании многопоточности и, как она реализуется в Android. Ну и базовые: понимание Rx, Dagger, Retrofit. Многие не стараются читать документацию различных технологий.
Но наша практика показывает, что обучающие интенсивы закрывают пробелы достаточно оперативно и качественно для работы в IT.
