блог разработчика о насущном
(Not So) Rocket Science учебный Java-проект

Учебный проект в Rocket Science — это проект, который выполняют все, кто приходит к нам работать. И это могут быть
не только джуниоры, но и middle чуваки.
Для нас — кандидат даже с маленьким опытом работы (или вообще без него) при правильном подходе его наставников к обучению может показать очень хорошую скорость роста. Стать как специалистом, так и желанным квалифицированным кадром за относительно короткий срок. Для того чтобы всё получилось, новичку должно быть: а) всё понятно б) не страшно ошибиться. Поэтому каждый junior в Rocket Science сначала делает учебный проект под названием «Предполетная подготовка»
и только потом подключается к официальным кейсам.

В учебном проекте мы собрали все технологии, которые используем в ежедневной работе. Естественно, это традиционный для enterprise-отрасли стек: GitLab, Spring Boot, Web, Swagger, PostgreSQL, JPA, Kafka, docker. Временами туда включаются более экзотические вещи, например gRPC или RSocket. Количество технологий, глубина и сложность поставленных задач подбирается таким образом, чтобы реализация всего проекта с нуля занимала примерно от одного до двух месяцев.
320
часов в среднем занимает учебный проект
29
задач всего. Из них
22 – в основной части
и 7 – в факультативной
12
часов средняя трудоемкость
задачи
15
% времени ментор тратит на ревью и наставничество
Кроме погружения в технологии, цель учебного проекта — познакомить junior-разработчика с нашими процессами: как ведутся задачи в JIRA, как следует оформлять коммиты, какими принципами мы руководствуемся во время код-ревью, и т.п. Эта часть онбординга новичка гармонично вписывается в работу предполетной подготовки: сотрудник не просто читает описание процессов в условном «документе онбординга», а сталкивается с ситуациями в работе и учится их решать. Кроме того, здесь мы пытаемся заложить умение делать декомпозицию и оценку задач.
Советы по работе с проектом для новичка
Кубики джунов

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

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

Кубики джунов
Набор компетенций джуна. Каждый кубик — это некоторый навык, опыт работы с той или иной технологией или с процессом разработки.
Что должен освоить новичок на учебном проекте
Наставники

У каждого курсанта есть ментор. У нас им может быть хоть кто, начиная
с middle. Менторство — это больше общение про проект и технологии, именно как обучающий фактор. Также наставник дает тщательное смысловое ревью, чтобы не упустить мелочи в реализации, заполнить пробелы в знаниях.
Менторить — интересно, но бывает и сложно. Делаешь свои задачи, отвлекаешься, потом надо возвращаться в контекст. А для нас важно иметь долгую держалку в голове, концентрироваться. Но это и здорово: ты даешь человеку знания и при этом учишься чему-то сам. Через менторство я часто открываю для себя неочевидные вещи.
Святослав, Lead Java Developer at Rocket Science
Есть и другая сторона медали. Иногда у ментора с обучаемым начинает что-то не клеиться на регулярной основе. Мы пробовали в таких случаях менять наставника, чтобы понять, в ком из них проблема. Но когда человек наступает на одни и те же грабли снова и снова, проходит полтора месяца, а воз и ныне там, то для нас это сигнал к расставанию. Грустный, но необходимый. Лучше понять это на учебном проекте, чем на коммерческом. Мы очень рады, что такое происходит крайне редко — а это значит, что и процесс найма работает у нас прекрасно.
Предполетная подготовка
На данный момент все задачи
учебного проекта разбиты
на три большие части.
Часть 1. Функционал микросервиса

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

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

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


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


Работа с кафкой. Взаимодействие микросервисов через брокер сообщений

RESTВзаимодействие микросервисов через REST
Часть 3. Development

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


Пример подключения метрик
Многие ребята говорят, что если бы они раньше столкнулись с таким проектом, сейчас бы знали намного больше. Потому что в учебном проекте у тебя есть время изучить технологии, попробовать на практике. Особенно это важно тем, кто приходит с другим стеком. За полтора месяца человеку приходится "перепрограммироваться" и учиться писать на совершенно другом языке.
Так к нам пришла Лера.
Было тяжело. На бэкенде я работала в небольшом коммерческом проекте. Там был код, но уровнем намного ниже и к нему не было жестких требований. Потом ушла в Сбер, работала на Spark-e — frameworkпо работе с Big Data. Это как бы Java, но вообще не про то. Когда пришла в Rocket Science, поняла, что вообще с этим не работала.

От всего учебного проекта я когда-то видела только 20%, т.е. основы я не знала. Но мне очень повезло с ментором. У меня был Кирилл, Lead Java Developer at Rocket Science. Он ставил очень классные задачи. Ему важно было — познакомить как можно с большим количеством технологий. Например, я какую-то задачу решила. Пойди еще реши ее так, ты познакомишься еще с такой темой. Из самого сложного было то, что никогда не работала с докером, кафкой, не писала интеграционные тесты. Несмотря на то, что у меня стек не совпадал — я со всем справилась. Ценно то, что менторы тебя не бросают. Стоит набраться терпения и все получится.
Валерия, Java Developer at Rocket Science
Hard skills
3 штуки, которые больше всего
понравилось ребятам прокачивать
Свой код на GitLab
Здорово, что для учебного проекта ты хранишь свой код на GitLab. Очень удобно, что его можно в любой момент открыть и посмотреть.
Вспомнить — если что-то забыл. Ведь это хорошее подспорье для других проектов. Поскольку механизмы пишешь одинаковые, а код
на проектах разный.

Реактивное программирование
Штука интересна тем, что в обычном программировании — ты нажал на кнопку и ждешь ответ. А реактивное программирование — ты подписался на что-то и оно само там живет.

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