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

Почему отделу кредитов нужна сильная
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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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