Как я стал Scala-разработчиком в Иннополисе

Привет, Хабр! Я Иван Лягаев, Staff Scala Developer в Т-Банке. Живу и работаю в Иннополисе — самом молодом городе России, — рядом с Казанью.

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

Казань и Иннополис для нас — важная точка на ИТ-карте. В регионе сильная образовательная база: Университет Иннополис, КФУ, ИТИС, ИВМиИТ и другие технические школы. Здесь сформировался конкурентный рынок, работают крупные ИТ-компании, а вокруг развивается активное профессиональное сообщество.

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

В статье рассказываю, как так получилось

Университет Иннополис: фундамент, практика и первый Scala-код

Мой путь начался с Иннополиса. В 2016 году я поступил в Университет Иннополис, в бакалавриат по направлению «Информатика и вычислительная техника». Это был второй полноценный набор на программу, а сама программа оставалась единственной в университете.

Я выбрал Иннополис по нескольким причинам:

1. Университет предлагал необычный для России образовательный опыт. Обучение на английском языке, большая часть преподавателей из-за рубежа, а в программе сильный упор на практику: лабораторные, домашние задания, командные проекты, реальные инженерные задачи.

2. Материальная сторона. В то время университет предлагал высокие стипендии — от 12 до 36 тысяч рублей в зависимости от успеваемости. Для студента это возможность закрыть базовые потребности, не зависеть от родителей и сфокусироваться на учебе.

Был и нюанс: обучение проходило на грантовой основе. Грант предполагал обязательство отработать год в компаниях-резидентах или партнерах особой экономической зоны Иннополиса. Список таких компаний был широким, поэтому на трудоустройство это почти не влияло. Я, например, проходил отработку в Т-Банке.

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

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

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

Классические инженерные навыки — Git, Docker, CI и другие инструменты — мы часто осваивали самостоятельно, по ходу проектов. При этом у нас было довольно много свободы в выборе языков программирования. За время обучения я успел попробовать разные языки, но основными для меня стали Java, Python и Scala.

Scala полюбилась больше всего. Я познакомился с ней на курсе «Современные парадигмы программирования», где мы изучали функциональное программирование. На тот момент Java казалась мне слишком многословной: даже для небольшой программы приходилось писать много кода. Python, наоборот, не нравился из-за динамической типизации: ошибку можно было допустить легко, а узнать о ней — только во время запуска.

Scala оказалась где-то посередине: лаконичный синтаксис, строгая типизация, выразительная модель работы с данными и функциями. Для меня это стало очень удачным сочетанием.

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

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

Переход в Т-Банк: ВЭД, сложный домен и первая большая система

В Т-Банк я пришел в 2019 году, в начале четвертого курса, на позицию Middle Scala Developer. Моей первой командой была команда сервисов для внешнеэкономической деятельности (ВЭД) в Т-Бизнесе.

Трудоустраивался я тоже в Иннополисе, в один из первых ИТ-хабов Т-Банка. Тогда офис занимал две небольшие комнаты, а работало в нем всего 15 человек. Сейчас в Иннополисе более 150 специалистов, и хаб продолжает расти. Было интересно наблюдать, как вместе с хабом меняется и рабочая среда: появляется больше команд, экспертизы, внутренних мероприятий, возможностей для роста.

ВЭД — сложный домен, и в него пришлось долго погружаться. Нужно было разобраться в нетривиальных бизнес-процессах, документах, ограничениях и регуляторных требованиях. Мне понадобился примерно год, чтобы начать уверенно ориентироваться в предметной области.

Небольшое погружение в ВЭД: юридическое лицо, которое занимается импортом или экспортом товаров и услуг, должно проходить валютный контроль по каждому отправляемому или принимаемому платежу. Банк обеспечивает этот процесс через специальный отдел: сотрудники проверяют документы, которые клиент предоставляет по платежам.

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

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

По моей инициативе мы с командой решили спроектировать новую систему, которая будет проще в поддержке и корректнее отразит доменную область со всеми нюансами.

Event Storming: сначала понять домен, потом писать код

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

Для нас описание процесса было критически важным. До переписывания системы нужно было договориться не только о технической архитектуре, но и едином понимании домена. Иначе новая система легко могла унаследовать проблемы старой.

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

При этом переписывание системы с нуля — всегда риск. Особенно если старая система, пусть и неидеально, но работает. В начале проекта мы были очень амбициозны и не до конца оценивали масштаб предстоящих работ.

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

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

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

Почему можно расти в регионе и не переезжать в Москву

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

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

Если хочется большего городского масштаба — рядом Казань.

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

Казань — один из самых быстрорастущих ИТ-рынков в России. Здесь сильная образовательная база, рядом Иннополис и КФУ, а еще — другие технические вузы, с которыми Т-Банк запускает совместные образовательные программы.

Для нас регион важен не только как место найма. Мы системно растим специалистов: участвуем в обучении, поддерживаем студентов, даем им возможность работать над реальными проектами под менторством сотрудников.

В хабе сформировалось сильное профессиональное комьюнити. Здесь много Java- и мобильных разработчиков, QA-инженеров, аналитиков, тимлидов, технических лидов и держателей профессий. Это позволяет не просто работать над крупными продуктами, но и развиваться внутри профессии, не уезжая из региона.

Команды хаба работают с разными направлениями:

• backend-разработка, в том числе Java и Scala;

• mobile — iOS и Android;

• frontend — React и Angular;

• системная и бизнес-аналитика;

• QA для backend, frontend и mobile;

• SRE и инфраструктурная надежность;

• data engineering и BI;

• стажерские и образовательные программы.

Java остается одним из основных стеков: на нем работает значительная часть сервисов и продуктовых систем. Scala — отдельное направление с полноценной инженерной экспертизой. Она используется там, где важны надежность, выразительная модель домена, работа со сложными backend-системами и высокая нагрузка.

Профессиональное сообщество поддерживается не только внутри команд. В Казани и Иннополисе проходят митапы, встречи по направлениям, образовательные форматы для студентов и начинающих специалистов. Например, мы делаем серию встреч о профессиях в ИТ: показываем, как устроены разные роли, чем занимается backend-разработчик, аналитик, тестировщик, мобильный инженер, тимлид. Это помогает студентам раньше понять, какой трек им ближе.

Отдельный большой формат — фестиваль «Сезон кода», который Т-Банк проводит в Казани уже несколько лет. Там рассказывают о разработке и продуктовых практиках, о том, что находится «под капотом». Мероприятие с лаундж-зонами и неформальным общением.

Работа в технической команде: библиотеки как продукт

Еще во время работы в ВЭД у меня появился интерес к общим библиотекам и инструментам. Под конец проекта по переписыванию систем в Т-Бизнесе начала формироваться техническая команда, которая должна была заниматься библиотеками и инструментами для всех команд управления. Мне показалось, что это логичный следующий шаг в карьере, и я перешел туда. В этой команде я работаю до сих пор.

У нас собраны инженеры разных стеков: Java/Kotlin, .NET, Angular и Scala. Главная задача команды — снять с разработчиков сложность инфраструктуры компании.

Мы разрабатываем библиотеки и инструменты, которые дают:

• унифицированную телеметрию для сервисов;

• реализацию паттернов отказоустойчивости «из коробки»;

• интеграции с общими внутренними системами;

• единые подходы к инфраструктурным задачам;

• инструменты контроля технического состояния сервисов.

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

Мы стараемся воспринимать каждую библиотеку как продукт. У нее есть пользователи, сценарии, документация, путь внедрения, обратная связь, метрики использования. Недостаточно просто написать код и опубликовать артефакт. Необходимо объяснить, зачем инструмент нужен, как его правильно использовать, какие проблемы он решает и как безопасно мигрировать с прежнего подхода.

Например, у нас есть Scala-библиотека T-Client для HTTP-взаимодействия с другими сервисами. Кроме базовых функций по отправке самих запросов есть возможность настроить разные аспекты: телеметрию, отказоустойчивость, кэширование, аутентификацию на основе OAuth 2.0 и так далее.

В настройку телеметрии входят:

• структурные логи запросов и ответов, учитывая маскирование данных;

• метрики по корпоративному стандарту;

• трейсинг с указанием дополнительных атрибутов.

В настройку отказоустойчивости входят: 

• таймауты;

• ретраи по выбранным стратегиям;

• ограничение параллелизма.

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

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

Полный список Scala-библиотек:

1. T-Server — библиотека для построения HTTP API по корпоративным стандартам компании.

2. T-Client — библиотека для HTTP-взаимодействия с другими сервисами.

3. T-Client-Integrations — набор готовых HTTP-клиентов на базе T-Client для взаимодействия с общими внутренними сервисами.

4. T-Kafka — библиотека для работы с Kafkа, предоставляет удобное API для построения Producer’ов и Consumer’ов.

5. T-Database — библиотека для взаимодействия с БД.

6. T-Background — библиотека для создания фоновых процессов в приложениях.

7. Futon — набор утилитарных компонентов (метрики, кэши, circuit-breaker и прочее).

8. SIAM — библиотека для межсервисной авторизации для сервера.

9. Alsu — библиотека для работы с системами удаленной конфигурации приложений.

В нашу зону ответственности входит контроль технического ландшафта. Мы собираем информацию о зависимостях, которые используются в сервисах, и на основе правил автоматически формируем отчеты о техническом состоянии проектов. А еще инициируем общие проекты по обновлению или отказу от конкретных библиотек. В Scala, например, отказались от использования библиотеки Akka, потому что та сменила лицензию и стала платной.

Большое внимание уделяем документации и продвижению внутри инженерного сообщества: проводим внутренние доклады, пишем материалы, выступаем на внешних площадках. Например, про одну из библиотек я рассказывал на конференции F[Scala] в 2024 году.

Развитие Scala-профессии внутри компании

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

Я сфокусирован на DevRel и образовании. Scala-сообщество меньше, чем сообщества Java, Python или JavaScript. Поэтому у меня есть личная мотивация делать так, чтобы о Scala знали больше людей: студенты, начинающие разработчики, инженеры из других стеков.

Со стороны может показаться, что Scala в Т-Банке — нишевое направление. На практике у нас большое сообщество Scala-разработчиков: больше 300 человек. На Scala реализовано много систем, в том числе критичных для бизнеса.

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

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

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

Культура хаба: инженерия, локальный контекст и открытость

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

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

В хаб часто приезжают коллеги из других регионов. Это не только рабочие встречи, но и живое общение с командами: open talk, Q&A-сессии, random coffee с руководителями. Такие форматы помогают снижать дистанцию между уровнями управления и быстрее выстраивать горизонтальные связи.

Внутри развиваются профессиональные комьюнити по направлениям: backend, mobile, QA, аналитика и другие. Инженеры регулярно встречаются, обмениваются опытом, обсуждают практики и разбирают реальные кейсы из команд.

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

Культура хаба строится вокруг открытости, живого общения и сильного инженерного сообщества, где легко взаимодействуют стажеры, разработчики, тимлиды и технические лиды.

Что дальше

Казань и Иннополис продолжают расти как инженерные центры. Будут усиливаться backend-направления, mobile, data, SRE, образовательные программы и внутренние профессиональные сообщества. Scala для нас — важная часть технологического ландшафта: мы продолжим развивать инструменты, делиться опытом и растить новых специалистов.

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

Для меня такой точкой стал Иннополис. Здесь я получил базу, выбрал Scala, пришел в Т-Банк и вырос до роли, в которой могу влиять не только на код, но и на инженерную культуру вокруг.

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

В полезных ссылках оставлю ссылки на медиапроекты на Scala в Т-Банке:

• Сезон 1

• Сезон 2