В учебном проекте мы собрали все технологии, которые используем в ежедневной работе. Естественно, это традиционный для enterprise-отрасли стек: GitLab, Spring Boot, Web, Swagger, PostgreSQL, JPA, Kafka, docker. Временами туда включаются более экзотические вещи, например gRPC или RSocket. Количество технологий, глубина и сложность поставленных задач подбирается таким образом, чтобы реализация всего проекта с нуля занимала примерно от одного до двух месяцев.

Кроме погружения в технологии, цель учебного проекта — познакомить junior-разработчика с нашими процессами: как ведутся задачи в JIRA, как следует оформлять коммиты, какими принципами мы руководствуемся во время код-ревью, и т.п. Эта часть онбординга новичка гармонично вписывается в работу предполетной подготовки: сотрудник не просто читает описание процессов в условном «документе онбординга», а сталкивается с ситуациями в работе и учится их решать. Кроме того, здесь мы пытаемся заложить умение делать декомпозицию и оценку задач.

Наставники

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

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

Часть 1. Функционал микросервиса

В первой части ученику нужно создать с нуля новый сервис для работы вымышленной транспортной компании. Придумать и реализовать API для работы с товарами на складе, расположения их на полках, поиском; покрыть e2e-тестами (используем Testcontainers).

Для менторов важно провести обучаемому экскурс по работе с базой данных, передать часто используемые у нас практики (e.g.) и показать встречающиеся подводные камни (e.g.). На некоторых этапах наставники делятся с курсантом заранее заготовленными сниппетами кода, чтобы дело шло быстрее. Кроме того, настраиваем CI, чтобы в каждом MR было видно, не сломались ли тесты, и исключить фактор: «Но это работает на моём ПК!».

Часть 2. Взаимодействие между микросервисами

Во второй части легенда дополняется тем, что субподрядчики не успели в срок сделать дополнительные сервисы, данные из которых важны для основного (цены и рейтинг). Обучаемому необходимо создать их упрощенные аналоги, чтобы можно было закончить свою часть с интеграцией. Именно здесь всплывают разные способы коммуникации микросервисов (начинаем с REST-а, далее Kafka и т.п.). Попутно также приходится решать вопросы хранения и разработки общего кода (DTO).

Часть 3. Development

Относительно недавно появилась третья часть. В ней мы акцентируем на том, что именно разработчик отвечает за то, как работает приложение в реальности. Здесь мы упаковываем приложение в docker-образ, пушим в приватный registry, при помощи gitlab-runner и docker-compose разворачиваем на специально выделенный виртуальный стенд. Имеются уже подготовленные prometheus + grafana, настраиваем дашборд с основными показателями приложения. Производятся попытки «ужать» приложение в ресурсах (cpu, memory). Ученик готовит тест-план в JMeter и пытается воспроизвести нагрузку на API, чтобы понять, какой возможен максимальный RPS и где что идет не так.

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

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