Хабрахабр

«Конечные пользователи — мы с вами»: об Android-разработке в ЦФТ

Теперь люди хотят решать с его помощью вообще все вопросы, связанные с деньгами. В 2018-м, когда с помощью Android Pay возможно оплатить даже шаверму, смартфон оказывается для пользователя главным финансовым инструментом. А значит, соответствующие мобильные приложения стали особенно актуальны.

Воспользовавшись тем, что компания присутствовала на нашей конференции Mobius, мы задали руководителю группы разработки Android приложений Михаилу Емельянову несколько вопросов о том, как в ЦФТ выглядит Android-разработка.
— Для начала расскажите кратко о «ЦФТ» для тех, кто раньше не слышал этого названия. У финансовых приложений, разработанных в компании ЦФТ для различных заказчиков, суммарное число установок исчисляется миллионами — то есть немногие могут похвастаться таким опытом в этой сфере.

Собственно, само название «Центр Финансовых Технологий», появившееся в начале 90-х, до сих пор остаётся актуальным и говорит само за себя. — Компания работает на рынке финтеха уже больше 25 лет: когда она появилась, не было даже понятия «финтех», но уже тогда она производила продукты и сервисы, которые теперь называют именно так.

Конечно, за прошедшее время многое изменилось (кто в 1991-м мог представить себе Android?), но суть осталась той же: ЦФТ развивает и разрабатывает IT-решения и технологические сервисы, которые делают простыми и удобными финансовые операции (в том числе денежные переводы и платежи).


Но сейчас, кроме него, есть офисы во многих других городах России, а также в Кишинёве, Алматы и Душанбе. Компания появилась в новосибирском Академгородке, и её главный центр разработки по-прежнему находится там. Рост продолжается: постоянно появляются новые сервисы и подразделения, активно развивается R&D-направление.

— А сколько человек занимаются конкретно мобильной разработкой, и можете ли привести примеры разработанных в ЦФТ приложений?

Сейчас это более 50 человек, но планы в мобильной разработке у компании такие, что мы должны расти в два раза быстрее, чтобы им соответствовать. —У нас распределённая мобильная команда в Новосибирске, Томске и Санкт-Петербурге.

Наши самые популярные приложения для iOS и Android — это «Денежные переводы» (более 1,3 млн скачиваний в Google Play), платёжные кабинеты карт «Билайн» и «Кукуруза».

Всего командой Faktura.ru реализовано 340 проектов внедрения онлайн-банкинга для корпоративных и частных клиентов. Также более 100 кастомизированных мобильных приложений для iOS и Android есть у нашего провайдера онлайн-банкинга Faktura.ru. А вообще на этой технологической платформе работают порядка 130 банков

— У работы с финансами есть своя специфика — чем Android-разработка в ЦФТ отличается от «среднестатистической» компании? 



Мы регулярно имеем дело с такими темами, как обеспечение безопасности мобильного банкинга на уровне API и при передаче данных, биометрическая аутентификация, Keychain, SSL-пиннинг и т.д. — Поскольку мы работаем с личными данными и финансами пользователей, одно из главных правил — строгие требования к защите информации. Накопили много соответствующего опыта, поэтому на Mobius как раз и представили доклад «Основы безопасности мобильного приложения».

Конечными пользователями всё-таки являются миллионы обычных рядовых граждан. Но при этом мобильная разработка в финтехе не превращается в сплошное соответствие требованиям безопасности, оторванное от желаний живых людей. И наши конечные продукты ориентированы именно на таких людей. Сейчас все управляют со смартфона денежными операциями — оплачивают услуги, переводят деньги.

Так что приложения должны быть не только безопасными, но и простыми, максимально технологичными. 

Поэтому в финтехе достаточно интересно заниматься как раз мобильной разработкой: там конечные пользователи — это, по сути, мы с вами. Мы создаём не что-то в вакууме, а продукт для потребителя.


Но при этом превратиться в медлительный «водопад» и согласовывать всё по полгода тоже нельзя. — Помимо защиты информации, вам ещё и нужно быть особенно стабильными: если у стартапа в продакшн могут пролезать ошибки, то от финансов ждут надёжности. Как вы решаете эту задачу?

Мы приняли за стандарт идею чистой архитектуры, и её принципы отрабатываем на реальных приложениях. — В первую очередь архитектурным подходом. Новые приложения делаем в рамках деления на слои, одиночной ответственности и слабой связанности сущностей.

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

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

Конечно, UI не по TDD, но и о UI-тестировании тоже не забываем: совместно с командой тестировщиков поработали над тем, чтобы они как можно эффективнее использовали Espresso. Ну и, разумеется, тестирование — практически везде всё покрываем юнит-тестами, часть разработчиков пишут код по методологии TDD.

Поэтому интересно спросить так: что нового в Android вы попробовали за последний год? — Поскольку финтех требует консервативности, в каких-то случаях это может мешать использовать новые технологии. И какие технологии, кстати, вообще используете?

Когда Google выпустил версию Android Architecture Component, мы решили поэкспериментировать и внедрили её в один из новых проектов. — Довольно многое пробуем. А вот LiveData нам показалась полезной для слоя представления. Но наткнулись на грабли: например, не увидели в её ViewModel достаточно эффективного средства решения задачи жизненного цикла для нашего проекта.

Благодаря чистой архитектуре нам не потребовалось переделывать все приложение, достаточно было доработать слой представления. После того, как результат AAC не оправдал ожидания, мы выпилили её, заменив более эффективным подходом. Есть и другой пример с использованием новой ORM Room.

На Mobius многие задавались вопросом «почему повсюду Котлин», но это же напрашивается. Мы сейчас активно разрабатываем на Kotlin. Многое можно сделать одной строчкой кода, например, объявление классов. Он даёт больше возможностей, чем Java, «из коробки»: кода стало гораздо меньше, функциональности — больше. Сейчас также пробуем корутины в одном из проектов.

А поскольку он стал настолько распространённым, сейчас, чтобы на нём не разрабатывать, надо иметь очень жёсткие убеждения и принципы. В общем, нам нравится, как Kotlin развивается, и радует, что его сообщество растет.

В общем, финтех не мешает вовсю играться с различными технологиями. А ещё мы используем RxJava/RxKotlin, популярные Retrofit и Dagger 2, гугловский Data Binding, планируем попробовать RxBinding, долго можно всё перечислять.

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

Так что, если в проекте с кучей legacy-кода неэффективно реализована поддержка смены ориентации, то стоит задуматься об использовании AAC. — Хотя AAC и не оправдали наши ожидания, они хорошо решают некоторые задачи: например, сохранение и восстановление данных при смене ориентации экрана. Но внедрить это нахрапом не получится, предварительно нужно подготовить архитектуру, исправить критические ошибки и найти точки интеграции, чтобы не перерабатывать все приложение.

Поэтому интересно: каков оказался ваш опыт с ней? — Упомянутый выше Room — довольно свежая технология, которую многие ещё не успели попробовать.

С помощью аннотаций можно легко описать создание таблиц, определить транзакции и т.д. — Room нас порадовал. Из минусов в текущей стабильной версии (1. Есть встроенная поддержка Kotlin, Rx, LiveData. 0) — отсутствие команд для очистки БД и необходимость настраивать связи вручную. 1. Например, дефолтные методы Transaction в интерфейсах стали поддерживаться только в 1. Еще были неудобные мелочи при использовании Room в Kotlin, но они постепенно решились с выходом новых версий. 0-alpha2. 1.

В общем, с Room работать с базами данных стало гораздо удобнее и эффективнее.

— Есть точка зрения «все эти ваши ORM от лукавого, абстракции всё равно протекают и приходится спускаться на уровень SQL» — что вы думаете об этом?

Главное, чтобы это не превращалось в оверхэд. — В любой технологии для решения нетривиальных задач приходится писать код, даже SQL. Например, можно вытащить данные из нескольких таблиц при помощи Relation. В Room тоже можно писать SQL-запросы руками (например, миграция или сложные запросы), но через аннотации это делать значительно удобнее.

Часто ли занимаетесь рефакторингом? — Поскольку ЦФТ старше самого Android, для вас наверняка актуален вопрос легаси.

Да и популярное утверждение «любой код, написанный сегодня, завтра становится legacy» вполне справедливо. — Конечно, в любом проекте будет существовать legacy-код.

Есть приложения, которые выпустили несколько лет назад. Так и у нас. п.), то мы делаем это. Если есть объективные причины менять весь код (баги, низкая масштабируемость, отсутствие эффективных технологий и т. Проводим поэтапный рефакторинг, параллельно выпускаем фичи, где по компонентам, слоям или просто экранам осуществляется переработка кода.

Например, в одном из наших проектов в качестве http-клиента использовали Volley. Также и в использовании технологий. Для этого мы проанализировали связи в проекте с rest-клиентом, подготовили архитектуру к переходу и за один раз переехали на него, не тратя на это много времени. Технология не новая, и мы хотели перейти на OkHttp + Retrofit.

И чего, по вашему опыту, больше всего не хватает начинающим Android-разработчикам? — У ЦФТ есть курсы, в том числе Android — а чему там учите?

Для студентов младших курсов — Школа ШИФТ, в рамках которой мы провели курс базовой Android-разработки на базе НГУ. — Да, в ЦФТ есть несколько образовательных проектов. В программе курса Android дают углубленные знания по Android, Java, Kotlin, Rx. А для студентов старших курсов и джунов — проект Focus Start, где есть 6 разнонаправленных курсов, в том числе и мобильная разработка (Аndroid и iOS). Выпустили уже несколько наборов, некоторые из лучших выпускников стали нашими сотрудниками.

Некоторые не понимают отличие паттернов MVC – MVP – MVVM и принципов Clean Architecture, из-за этого неправильно понимают бизнес-логику. Зачастую начинающим Android-разработчикам не хватает опыта применения ООП, принципа SOLID.

Ну и базовые: понимание Rx, Dagger, Retrofit. Также встречаются пробелы в Android SDK, Java, понимании многопоточности и, как она реализуется в Android. Многие не стараются читать документацию различных технологий.





Но наша практика показывает, что обучающие интенсивы закрывают пробелы достаточно оперативно и качественно для работы в IT.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть