Код
#статьи

Как устроена разработка в большом финтехе: при чём тут Scala и за что не любят Java

Подкастер и руководитель разработки из «Тинькофф Бизнеса» о технологиях, внутренней кухне, отказах «рок-звёздам» и джунах.

Иллюстрация: Rawpixel / Jannoon028 / Creativeart / Freepik / Towobola / Cleanpng / Vladimir Ivanov / Vladimir Ivanov Dev Blog / Tinkoff Bank logo / Wikimedia Commons / Meery Mary для Skillbox Media

Владимир Иванов

об эксперте

Архитектор решений и руководитель разработки в отделе кредитов «Тинькофф Бизнеса». Придумывает, как решать задачи бизнеса с помощью технологий, проектирует системы, ориентированные на облака и мобильные приложения. Автор дорожной карты архитектора и блога про архитектуру решений, соведущий подкастов Mobile People Talks и newpodcast2.


Ссылки


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

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

У «Тинькофф Бизнеса» и всех сервисов для юрлиц крутая миссия. Представим, что у вас успешный бизнес, но вы хотите увеличивать обороты — покупать больше товара, на это нужны средства. Вы приходите к нам, а мы даём вам кредит на развитие. Это выгодно бизнесу.

То есть мы пытаемся помочь, выдаём кредиты, упрощаем сервисы и помогаем вести отчётность. Да, когда ты даёшь деньги бизнесу, это реальная помощь, потому что бизнес заработает сам и принесёт пользу людям. Это классная миссия.

Почему отделу кредитов нужна сильная
IT-команда

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

Решение сложное, потому что выдача кредитов — это многошаговый процесс. Вы подаёте заявку, а мы находим вас в ЕГРЮЛ и других системах. Если данных не хватит, мы просим дать больше информации.

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

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

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

Как устроены фронтенд и разработка мобильных приложений

Наш фронтенд построен на TypeScript и Angular. Чтобы быстро создавать новую функциональность, у нас есть самописный фреймворк, который называется Frame Manager.

Несколько разработчиков из «Тинькофф» имеют статус Google Developer Expert по Angular, поэтому на «Хабре» мы часто публикуем о нём статьи — например, как мы перешли к микросервисам и разбили фронтенд на 100 приложений.

Мобильные приложения у нас многомодульные — «модные и молодёжные». Android-версия написана на Kotlin, Dagger 2 и RxJava. Сейчас неспеша обкатываем корутины. Приложение для физлиц собирается с нуля за 40 минут, а наше — за 10. Пока мы релизимся каждые две недели, но скоро будем в два раза чаще.

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

Тут и выручает импакт-анализ — с его помощью мы можем понять, какие именно тесты надо запустить. Недавно на конференции Mobius об этом рассказывал наш разработчик Максим Щепалин.

Как работает бэкенд сервиса выдачи кредитов

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

На ближнем бэкенде мы используем Scala, Akka и Cats Effect. Скоро хотим реализовать подход API First, но пока не получается. Основная база данных — PostgreSQL, но в общебанковских решениях есть и Oracle, потому что она популярна в финтехе.

Глубокий бэкенд — микросервисы на Kotlin, Spring и Spring Boot, в качестве BPM-движка стоит Camunda.

Раньше на бэкенде вместо Kotlin был Java, но года три назад от него отказались. На все 15 сервисов остался только один или два файла на Java. Ребята любят Kotlin, потому что он быстрый, удобный и отлично развивается. У него хорошая интеграция со Spring и по умолчанию есть все нужные библиотеки и инструменты.

Часть сервисов написаны на Node.js. Как и у всех, стоит система очередей Apache Kafka. Где-то используем базу данных Cassandra, до неё была Infinispan, но мы её выпилили.

Scrum, Kanban и четыре разных IDE на один отдел

У меня в отделе семь команд, в сумме 47 человек. Все ведут задачи в Jira, но остальные инструменты выбирают для себя сами. Главное — чтобы процессы были эффективными.

В мобильной команде работают по методологии Scrum, потому что система хорошо подходит под двухнедельные релизы. В BPM-командах у нас Kanban — раз в неделю мы проводим планирование для приоритизации бэклога на ближайшее время, а дальше ребята просто закрывают задачи. Релизы там каждый день, поэтому они выкатывают функцию и релизят её на продакшен.

Пишем код мы в основном в платной IntelliJ IDEA от JetBrains. В Android-команде ребята пользуются Android Studio, все iOS-разработчики пишут в Xcode — насколько я знаю, никто из них не пользуется AppCode от JetBrains.

Почти все фронтендеры пишут код в WebStorm, но кто-то работает в VS Code. Когда я сам писал на Node.js, тоже пользовался WebStorm — она очень удобная.

Как два программиста за месяц накодили новый банковский продукт

У нас есть налаженный процесс, как быстро запустить продукт или добавить в него новую функцию. Product owner ставит нам задачу, мы собираем требования, ищем решение, договариваемся и берём задачу в разработку. Только в группе компаний владельцев продукта почему-то называют технологами.

Например, технолог говорит: «Нужно сделать кредитные линии под исполнение контракта. Если человек выиграл госзакупку, мы будем давать ему деньги». Наш архитектурный комитет думает, как это реализовать, какие системы затронет новый продукт и в чём риски.

Когда мы находим несколько решений, обстоятельное и долгое с одной стороны и быстрое костыльное — с другой, мы показываем их технологу. Выбираем в зависимости от бизнес-ситуации. Если время есть, то идём по обычному процессу с нормальным тестированием, аналитикой и документацией. Если выбрали костыли, то считаем, во сколько обойдётся их переписать в будущем.

Иногда нужно сделать MVP — например, если мы не понимаем, насколько продукт или функция пригодится клиентам. Чтобы проверить гипотезу, мы не тратим много ресурсов: рисуем принципиальную схему, выделяем двух человек и делаем всё за месяц.

Так мы запустили кредиты для продавцов с «Яндекс.Маркета». В личном кабинете у них появилась кнопка «Хочу кредит от „Тинькофф“». Если её нажать, человек попадает на наш лендинг и оставляет заявку с номером телефона, фамилией, именем и отчеством.

Дальше наша система обращается к «Яндекс.Маркету» и говорит: «К нам пришёл человек, покажи его обороты». Их сервер делится статистикой, и мы решаем, давать ли кредит. Если всё хорошо, мы оформляем человеку счёт в «Тинькофф Бизнесе» и перечисляем туда деньги. А на них человек покупает товар и зарабатывает на «Яндекс.Маркете» больше.

Мы решили сделать всё быстро, потому что в пандемию интернет-торговля выросла, туда ушло много продаж из офлайна. Проект тестировали сразу на продакшене, причём отдельного тестировщика не было, всем занимались двое программистов. Часть интеграций с «Яндекс.Маркетом» я даже писал сам.

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

Какие фейлы случаются в банковских системах и как мы с этим боремся

Банковский бизнес большой, поэтому IT-продукты здесь тоже сложные. Когда одну систему разрабатывает несколько команд, что-то всегда может пойти не так:

Бывают проблемы с API. Например, за мобильную разработку в кредитах у нас отвечает одна команда, другая делает фронтенд и бэкенд. Чтобы о чём-то договориться, нужно специально собираться. Бывает, что все определились с API, а потом кто-то сделал опечатку и назвал поле иначе. Выясняется это уже к финальному тестированию.

В 2022 году мы построим кросс-функциональные команды: выделим мобильных Android- и iOS-разработчиков, фронтендеров, бэкендеров, тестировщиков, архитектора и системного аналитика. У них не будет таких проблем.

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

Отключаются легаси-сервисы. У нас как-то внезапно отключился старый сервис, который отвечал за движение заявки на кредит по стадиями проверки. Мы хотели его со временем переписать, но как-то в пятницу он внезапно умер.

Ребята пытались его поднять, но к 18:00 у них это так и не получилось. Часть процессов мы уже перевели на новый движок, поэтому мы решили экстренно его допилить. Команда взяла овертайм, справилась и получила за это оплату.

Ошибается скоринг. Хоть все решения принимаем мы, скоринговую модель пишет другой отдел. Её составляют риск-аналитики, а команда разработки это кодит. Мы общаемся с ними по API, и любая ошибка на их стороне сильно влияет на нас.

Из-за такой ошибки мы отказали многим клиентам в кредите. Система скоринга рассчитывает вероятность дефолта компании и выдаёт числа вроде 0,10 или 0,15. Но запятую и точку перепутали и формат числа поменялся. Некоторые проверки не срабатывали, и кто-то не получил кредиты.

Проблема в том, что сервис не может всегда отдавать одинаковый результат — для отказов есть распределение вероятности. Плотность заявок за день и неделю отличается. Нельзя сказать, что 100 отказов в день — плохо. Долю отказов нужно смотреть нарастающим итогом, а это относительно сложный мониторинг. Зато он у нас теперь есть, осталось только подключить уведомления.

Почему в «Тинькофф Банке» кандидаты проходят четыре собеседования

Процесс найма общий для всей группы компаний, поэтому мы в «Тинькофф Бизнесе» почти не проводим технические интервью. Это помогает оценивать людей объективно, чтобы в одном подразделении кандидату не предложили зарплату в X рублей, а в другом — 10X.

Этапы собеседования стандартизированы. Например, Java-инженеры, особенно сеньоры и выше, проходят через три интервью:

Прикладное. На нём убеждаются, что человек знает язык, ориентируется в инструментах, знаком со Spring, умеет обращаться к базе данных из Java-приложения и так далее.

Алгоритмическое. Здесь не будет никаких задач с LeetCode, кандидату дают относительно простую задачу на пару if и циклов for. Если ты давно пишешь код, это относительно несложно.

Системное. Если человек доходит до этого этапа, ему описывают систему и просят нарисовать её дизайн — например, спроектировать Twitter. Никто не докапывается до деталей, но, если вы хотите устроиться сеньором, желательно собрать все требования и учесть их в готовом дизайне.

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

Зачем отказывать «рок-звёздам» и брать в команду джунов

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

Опытный программист. Вдохновляет всех изнутри. Без него мне придётся чересчур опекать команду, а это её демотивирует.

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

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

С «рок-звёздами» я стараюсь не работать, потому что часто они токсичные. Лучше взять человека послабее, у которого всё хорошо с софт-скиллами.

Ещё я очень верю в формулу из книги «Идеальный командный игрок» — у правильного кандидата есть три качества: hungry, humble и smart.

КачествоОписание
Hungry (проактивный)Ему нужнее всех: он не сидит на попе ровно, а хочет чего-то добиваться.
Humble (простой)Он не смотрит на других людей свысока, а общается с ними на равных. Это критически важно, потому что иначе с ним не захотят иметь дело и эффективной работы в команде не получится.
Smart (осознанный)Умеет договариваться с людьми, не ругается с ними, может поставить себя на чужое место и понять, почему человек себя так ведёт.

Я стараюсь нанимать только тех, у кого есть эти качества. Если я вижу, что чего-то не хватает, лучше я упущу хорошего кандидата, чем найму плохого

Как «Тинькофф» запылесосил весь рынок Scala-программистов СНГ

На Scala пишут почти во всём банке. Я работаю здесь только с февраля 2021 года и не знаю, почему выбрали именно его. Наверное, кто-то решил, что из-за иммутабельности и других плюсов Scala хорошо подходит, чтобы писать бизнес-логику.

К сожалению, мы запылесосили почти весь рынок Scala-разработчиков СНГ и найти новых очень трудно. Расти дальше тяжело, поэтому мы будем писать новые сервисы на Node.js и TypeScript, а некоторые старые перепишем со Scala на другие языки или просто оставим на поддержке. Если кому-то интересно, приходите.

Мы стараемся поощрять людей, когда они учат новые технологии. Кто-то начинал с фронтенда и выучил Scala, чтобы перейти в бэкенд. Другие, наоборот, пишут на Scala, но им интересно попробовать что-то ещё.

Наши Scala-разработчики не считают себя аристократами, для них не зазорно перейти на TypeScript или Kotlin. Я стараюсь, чтобы атмосферы элитизма не было, потому что это не нормально, когда одни программисты смотрят на других свысока.

За что я люблю TypeScript и почему не хочу писать на Java после Kotlin

Лично мне нравится писать на TypeScript — это быстро, и при этом у него нет проблем JavaScript, где ты в любом месте можешь выстрелить себе в ногу. В TypeScript есть очень хорошая проверка на типы, и я научился на неё полагаться. Что-то переименовывать вообще не боюсь, потому что редактор мне сразу подсветит, где чего не хватает.

Ещё я нежно люблю Kotlin — я писал на нём, пока занимался мобильными приложениями. После него Java вызывает у меня некоторый дискомфорт.

В сентябре мы сделали так, что, если у любого клиента «Тинькофф Банка» есть ИП или ООО, в приложении физлица у него появляется раздел с кредитами для бизнеса. Это мегапопулярная штука, туда заходят 40% пользователей. Я помогал всё реализовать, но на том проекте в основном пишут на Java. Основное впечатление: «Как на этом языке вообще писать после Kotlin?»

Поэтому TypeScript и Kotlin — ван лав. Я могу писать на Java, но мне уже не нравится. Раньше я кодил на C#, было прикольно, но с 2013 года я его не трогал. А больше я особо ни на чём не пишу.

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

Главное отличие финтеха от других отраслей — регуляции. Есть требования Центрального банка, Финмониторинга и законодательства (тот же «Закон о персональных данных»). Мало того, что всё это нужно соблюдать, требования регулярно меняются.

Например, ФСБ приходит и говорит: «Ребята, электронную подпись теперь нельзя хранить в облаке, можно только на флешках. Срок — первое января». И все бегают с горящими задницами, чтобы успеть. Это дизрапшен: рынок меняется внезапно, и продукт нужно быстро переделывать.

До «Тинькофф» я работал в ЕРАМ, там мы делали систему управления заказами для большого ретейлера. Она помогала заказчику понять, в какие магазины какой товар везти. Раньше для этого использовали Excel, но это было неудобно — люди ошибались, теряли файлы, не могли их нормально импортировать в другие системы.

Мы же сделали для них платформу, которая превратила Excel-таблицы в программный продукт — у менеджеров появился веб-интерфейс. Он автоматически исправлял ошибки и выгружал файлы куда нужно. Никаких регуляций не было, главное — чтобы система работала.

Я трудился в разных сферах и могу сказать, что меня привлекает не сам финтех, а миссия, которую я здесь выполняю. То, насколько моя работа помогает людям. В этом плане я чувствую себя очень комфортно и верю, что мы всё делаем правильно. Мы не просто зарабатываем деньги, но и помогаем людям жить лучше и меняем общество в хорошую сторону.

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

Учись бесплатно:
вебинары по программированию, маркетингу и дизайну.

Участвовать
Школа дронов для всех
Учим программировать беспилотники и управлять ими.
Узнать больше
Понравилась статья?
Да

Пользуясь нашим сайтом, вы соглашаетесь с тем, что мы используем cookies 🍪

Ссылка скопирована