Чем ты занимался до БКС?
До БКС я работал в ВТБ на нескольких крупных проектах и был одним из первых разработчиков ПО под Android в штате банка. Остальные разработчики находились на аутсорсинге. С моим участием банк как раз начал решать задачу по переводу проектов в инхаус-разработку.
Я начинал с приложения «ВТБ Онлайн» для физических лиц. Позже перешел в проект для среднего и малого бизнеса, где занимался созданием нового приложения. Построил базовую архитектуру и выбрал нужные технологии.
В БКС я пришел в марте 2020 года. Это было интересное время, самый разгар пандемии.
Какую задачу тебе поставили при приходе в БКС? Была какая-то глобальная цель?
Я приходил работать лидом Android-разработки в приложение «БКС Премьер». Сначала моей задачей было нанять разработчиков в штат, потому что часть сотрудников предоставляли нам компании по аутсорсингу персонала.
Так как на тот момент версия приложения на Android систематически отставала от версии для iOS, и не было четкого релизного цикла, второй важной задачей стало наладить процессы, устранить отставание, выровняться по функционалу.
Пока я решал эти задачи, к концу моего испытательного срока, стало известно, что принято решение объединить наш проект с другим приложением БКС. Тогда оно называлось «Мой брокер», а позже получило название «БКС Мир инвестиций» и сейчас является основным.
Конечно, с новыми вводными задача существенно усложнилась, но мне это было интересно. Нужно было объединить два разных проекта в единое целое, заставить их работать вместе, начать выпускать релизы. Я занимался этим на протяжении всего 2020 года. Это было большой, интересной и глобальной задачей.
Если абстрагироваться от БКС, в последние годы есть отход от аутстаф- и аутсорс-разработки. Чем это обусловлено?
Раньше существовало твердое убеждение, что разработчики, привлеченные на аутсорс, — это профессионалы, которые качественно и быстро делают свою работу, так как они сотрудники профильной компании. Это справедливо и сегодня. Но я считаю, что такой формат лучше подходит для проектов, где скорость изменений некритична. Когда требуется гибкость и высокая скорость реакции на внешние вызовы, работать на аутсорсинге становится сложнее. Настроить эффективный процесс взаимодействия удается немногим. В результате бизнес может начать отставать от конкурентов.
Другая причина отхода от аутсорсинга, на мой взгляд, — это мотивация и развитие сотрудников. Когда все находятся в штате, система поощрений может быть значительно эффективнее. К тому же появляется больше возможностей для роста и развития экспертизы.
Ну и последний аспект — стоимость. Иногда построить внутреннюю команду разработки может быть дешевле.
Финансы кажутся глобальной устойчивой областью. Можно ли сказать, что в ней не так важна скорость, как надежность?
Если мы говорим про классический банкинг, то здесь в первую очередь важна надежность банка. В банковском приложении все меняется небыстро. Важнее, чтобы оно работало стабильно и без сбоев.
С брокерским бизнесом немного другая история. Здесь изменения происходят быстрее. Это связано с тем, как стремительно развивается брокерское направление в последние годы. Люди интересуются финтехом, а в обществе формируется спрос на инвестиции как продукт. Поэтому здесь нельзя выпустить приложение и год его не трогать. Так не получится.
Вернемся к разработке. Как объединить два приложения с разными архитектурами и подходами? По-моему, это не очень тривиальная задача.
Конечно, было много тонкостей. Начиная с того, что один проект был многомодульный, а другой — монолит, и нам потребовалось немного «распилить» сингл-модуль, чтобы забрать оттуда хоть что-то.
Самое сложное, пожалуй, было с DI в плане архитектуры, потому что переходы между изолированным функционалом еще можно настроить без особой боли, а вот зависимости передавать тяжело.
Другая проблема была в том, что приложения были в совершенно разном дизайне. У них были различные клиентские пути, они использовали разные бэкенды для того, чтобы получать данные.
В итоге мы частично все это переписали: забрали из одного приложения хорошие идеи и подходы, вынесли их в библиотеки и смогли применять в объединенном приложении.
К счастью, в БКС оказалось несложно донести все до менеджмента и детально объяснить, что мы делаем. Я подготовил большую схему — план перехода. Удалось объяснить необходимость больших трудозатрат. Параллельно коллеги изменили дизайн, чтобы достичь однородного внешнего вида. А потом мы уже занялись более глубоким рефакторингом архитектуры.
Какая сейчас команда Android-разработки в компании?
В нашей команде 20 Android-разработчиков разного уровня. Всего в проекте «БКС Мир инвестиций» работает более двухсот человек.
На нашем проекте нет аутсорса. Аутстафф присутствует, но это люди, которые полностью интегрированы в нашу команду и процессы.
С командой мы более-менее поняли: много всех и очень хороших. Какие технологии вы используете сейчас? Сам стек технологий меняется в течение времени? Насколько Android-разработка пластична, насколько в ней появляются новые инструменты?
Мы переходим и в основном уже перешли на такой стек: Dagger 2 для DI, Retrofit и Okhttp для сетевых вызовов. Кроме того, у нас очень много сокетов, поэтому активно используем Stomp. Presentation-слой построен на MVVM-архитектуре с применением Live Data и ViewModel. Для построения UI используем подход Adapter Delegate, у нас есть своя библиотека для этого. Естественно, пишем только на Kotlin. Для CI используем GitLab.
Я считаю, что у нас достаточно гибкий проект с учетом его размеров. Каждый спринт мы выпускаем довольно много функционала. У нас есть планы по дальнейшей миграции на более новые технологии и подходы. В частности, хочется попробовать перейти с RX на Flow. Или попробовать Compose. Но сначала хочется выровнять стек, чтобы не осталось legacy, и все было примерно в одном подходе.
В конечном счете мы же строим архитектуру не потому, что хотим применить новые технологии или выступить с докладом, а для того чтобы решать бизнес-задачи за приемлемое время. Когда мы перешли на MVVM и на recycler-based-подход, у нас сильно выросла скорость разработки. Хотелось бы получать похожий эффект и от будущих преобразований.
В Android Broadcast недавно говорили о переходе с Dagger на Koin, с Koin на Dagger обратно. Насколько в вашем случае оправданы такие переходы? Как вы оцениваете новые технологии?
У нас свой процесс поиска технологий. Сначала мы смотрим, что в принципе есть, и проводим простой сравнительный анализ. Делаем чек-лист — большую таблицу, в которую выписываем все плюсы и минусы решения. Стараемся обязательно проверить, чтобы текущие недостатки какого-то решения в новом были ликвидированы.
Если мы понимаем, что новая технология объективно лучше и не является просто модой и хайпом, то переходим к этапу внедрения. Во-первых, смотрим на архитектуру: насколько нам нужно вносить изменения в текущий подход, чтобы прикрутить что-то новое. Во-вторых, оцениваем трудозатраты. Это тоже обязательный пункт в нашем чек-листе. Потом мы берем какую-то не самую важную фичу и делаем в ней эксперимент.
Выкатываем это все в прод и смотрим на поведение новой технологии, есть ли баги, проблемы и так далее. По результатам анализа проводим ретроспективу и пытаемся понять, насколько новая технология нам подходит, стараемся измерить совокупный профит от решения. Если нас все устраивает, постепенно распространяем решение на весь проект.
В принятии новых технологий у вас есть, как у стартапа, «северная звезда», основная метрика, которая решает все? Или это всегда совокупность факторов, которые влияют на принятие новых технологий?
Повторюсь, мне бы хотелось, чтобы это была совокупность факторов. Например, в случае с DI, когда мы переходили с Kodein на Dagger, была одна простая ключевая метрика: попадем мы в рантайм или нет. С этим было легче. Но в целом сейчас мы стабилизируемся в стеке. И дальше уже все-таки решаем по совокупности факторов, потому что просто так заводить новые технологии — бездумно. Ни у кого нет желания это делать. Есть другие задачи, которые можно решить.
Есть какие-то особенности разработки у финтех-компаний?
Есть два аспекта. Во-первых, мы брокер. То есть, мы предоставляем физическим и юридическим лицам доступ к бирже. Соответственно, прежде всего, мы должны быстро реагировать на изменения внешних площадок (бирж), с которыми контактируют наши системы. Это, конечно, накладывает свой отпечаток на процесс. Мы должны уметь оперативно подвинуть планы под что-то очень важное, что делают такие площадки, и имплементировать это. Иначе проиграем конкурентам.
И вторая особенность — это Центральный банк (ЦБ). Иногда у нас появляются задачи, связанные с требованиями регулятора. Если ЦБ вводит новые требования для инвесторов, мы должны в срочном порядке доработать наши приложения и фронт/бэк-системы таким образом, чтобы эти требования удовлетворить. То есть в нашей работе действительно присутствуют некоторые особенности.
Безусловно, у нас есть особый контроль безопасности, в том числе и статические анализаторы, которые регулярно применяют коллеги ко всем нашим кодовым базам. Но я бы сказал, что это обычно для финтехов и банков: все стандартные процедуры присутствуют.
Кого вы сейчас ищете? У вас открыты вакансии? Какие требования выдвигаете?
В первую очередь мы ищем опытных разработчиков, которые бы помогли нам развиваться. Конечно, сейчас трудно найти специалиста, который идеально подойдет по всем параметрам. Поэтому мы исходим из реальности и стараемся перестраиваться вместе с рынком.
Кроме того, мы ищем талантливых middle-разработчиков. Здесь больше важен образ мышления и способность к обучению, чем накопленные знания.
BCS Coding Days — это задачи для системных аналитиков, Android и Java-разработчиков с призовым фондом 1 500 000 рублей. Соревнование пройдёт с 4 по 5 декабря онлайн.
А есть у вас какой-то любимый вопрос с собеседования?
Тут я, наверное, всех удивлю, но один из моих любимых вопросов связан с тем, какие у человека планы, чего он хочет добиться, какой видит свою карьеру.
Как вы видите себя через пять лет?
Да, только я спрашиваю не про 5 лет, а про 3 года. Я действительно считаю это важным, потому что если у человека нет планов, и он просто хочет писать код, то, скорее всего, либо уже выгорел, либо с ним это скоро произойдет.
Ведь мы нанимаем разработчиков по всей стране. А в работе на удаленке есть один минус: с человеком тяжелее поддерживать связь. Сложнее понимать, какие у него проблемы и есть ли трудности. Ведь нет живого общения. И такие люди, не имея дополнительной мотивации и амбиций, с высокой долей вероятности, встретив трудности, уйдут от нас.
Кроме того, у нас есть ключевые вопросы по технике. Мы стараемся понять, насколько человек разбирается в процессах, которые происходят в Android и в Kotlin, как работает вся эта инфраструктура и какие есть взаимосвязи между базовыми элементами. Мне кажется, если человек понимает процессы, то и со всем остальным разобраться ему будет гораздо проще.
Что на горизонте трех лет будет в Android-разработке? На что смотреть, в какие направления идти?
Во-первых, нужно все-таки переходить на Kotlin-based-библиотеки. Потому что часть нашего стека в том числе написана на Java. И сейчас уже появились аналоги, которые полностью написаны на Kotlin.
Из глобального, наверное, это Compose. Все очень давно ждут это решение. Мы сейчас используем Adapter Delegate как промежуточный шаг к тому, чтобы описывать UI из кода. Дальнейшее развитие идеи без Compose невозможно.
Второе важное направление — Kotlin Multiplatform и в целом кроссплатформенные решения. Много лет все говорят, что сейчас появился новый кроссплатформенный фреймворк, и нативных разработчиков можно увольнять. Но пока ни один из них не взлетел. Непонятно, получится ли сделать рабочее решение. Если получится, наверное, многие пойдут в эту сторону. Все больше вижу Flutter-вакансий сейчас. Значит кто-то нашел применение этой технологии в своей нише.
А у вас КММ используется где-нибудь?
У нас пока нет. Коллеги с моей прошлой работы потратили какое-то время на исследование, поделились результатами. Мне кажется, пока эта технология не полностью готова к использованию.
Если взять Swift UI — он старше Compose, но до сих пор имеет определенные проблемы. Насколько декларативный подход будет готов к таким большим приложениям, как БКС?
Как раз мы говорим о горизонте трех лет. Я думаю, что через год-полтора, может два, он станет уже полностью готов, и его можно будет спокойно использовать. Как раз к тому моменту мы разберем текущий технический долг и сможем начать переход. На ближайший год планов хватает. Дальше будем смотреть.