В прошлой статье мы рассказали, почему Compo Soft решила уйти от привычного PHP‑стека и перейти на Java ради выхода в сегмент Enterprise. Но если кто‑то подумал, что за этим решением последовал массовый найм Java‑разработчиков — нет. Мы пошли по куда более хардкорному пути: взяли всю свою PHP‑команду и начали переобучать ее на Java. Полностью c нуля. И без отрыва от производства.

В этом материале — честная и подробная история о том, как это происходило. Почему выбран формат интервью — вместо обычного повествовательного рассказа о кейсе. Тут все просто, прямая речь от первого лица всегда интереснее и ярче, плюс не надо оттачивать формулировки и превращать их в скучный корпоративный текст. Поэтому — интервью с Владимиром Гантуриным, техническим директором Compo Soft, без купюр, с примерами и парой нелицеприятных фраз про Hibernate. В общем, слоган «Невозможное — возможно» оказался вполне рабочим.

Поехали.

С какой точки стартовали, и кто переобучался

Владимир Гантурин (В.Г.): Переобучение было для всей команды и началось вовсе не с обязательного «Всем пройти первый уровень JavaRush до конца недели». Процесс шел волнами, если так можно выразиться. Сначала была первая волна — четверо сеньоров, которым было интересно и которые готовы были экспериментировать в поисках наиболее эффективного процесса обучения. Потом — вторая, третья, четвертая волна: это были все остальные разработчики, в зависимости от своей мотивации, загруженности и желания вписаться в новую архитектуру.

Важно: переобучение шло параллельно с поддержкой проектов на PHP. Приходилось выделять отдельные полные дни на обучение, лавируя между дедлайнами. То есть полдня пишешь на PHP, полдня учишься писать на Java. Привет, раздвоение личности.

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

Кто хотел расти и пробовать новое — вписывался в Java‑направление. Такой подход позволил сохранить мотивацию, команду и плавно запустить миграцию технологий без ломки всей компании через колено.

Как готовились к учебе, и кто менторил

(В.Г.): Самым важным оказалось не техническое, а ментальное переобучение. Команде открыто объяснили: через год, а скорее полтора — хотим, чтобы весь стек был на Java, и если хотите — включайтесь. Без прессинга, на добровольной основе. Многие подключились — и это сработало лучше любого KPI.

Был внутренний ментор — и это был я, Владимир Гантурин. Я и лекции читал, и архитектуру показывал «на пальцах», и обучение курировал индивидуально — подстраиваясь под опыт и специализацию. Позже появился core‑team — ядро Java‑команды, где каждый отвечал за свое направление: безопасность, поиск, eCommerce, данные. Остальные могли обращаться за консультациями — по модели «техподдержка 2.0».

Плюс я как CTO активно общался с коллегами из других сфер — е‑коммерции, банков, производств. Реальные кейсы и опыт людей из отрасли — лучший метод обучения.

Сообществам — отдельное спасибо за поддержку

(В.Г.): К слову, менторство не замыкалось внутри команды. Мы активно взаимодействовали с сообществом, и в некоторых случаях это дало даже больше, чем книжки и официальная документация.

Особая благодарность Т1 — за технологические конференции, в частности Angular Meetup. Благодаря этим мероприятиям мы познакомились с крутыми инженерами, обсудили подходы, проверили идеи и убедились, что движемся в правильном направлении. Это общение в итоге определило выбор Angular как фронтенд‑стека.

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

Что касается бэкенда, здесь не обошлось без:

• pro.jvm — крупнейшее сообщество JVM‑разработчиков на русском языке;

• конференций Joker — с реальными кейсами и глубоким разбором технологий;

• материалов и курсов от OTUS — как бесплатных, так и платных.

Когда ты можешь в любой момент найти разбор настоящих кейсов от практиков, а не листать условный туториал «Как сделать REST API за 5 минут» — переобучение перестает быть абстракцией. Оно становится реальной инженерной практикой.

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

Использовали ли курсы, книги, воркшопы?

(В.Г.): Жесткой методички у нас точно не было. Формат обучения — адаптивный: кто‑то любит читать документацию, кто‑то — смотреть онлайн‑уроки. Использовали все:

• Java Core (теория + практика);

• Spring и Spring Boot — основа всей архитектуры;

• Hibernate (а к нему мы еще вернемся);

• Elasticsearch — потому что поиск в Enterprise должен быть быстрым;

• CI/CD, менеджеры пакетов, Angular — все, что нужно для жизни.

Воркшопы делали сами: разбирали кейсы, писали небольшие модули, обсуждали ошибки

Где было больно: что самое сложное — язык, экосистема, архитектура?

(В.Г.): Воркшопы делали сами: разбирали кейсы, писали небольшие модули, обсуждали ошибки — не Java. Язык, экосистема, даже Spring — все заходит, если ты не первый день в разработке. Особенно если устал от хаоса, который приносит динамическая типизация PHP.

Самым сложным делом была организация рабочего дня у участников обучения. Когда ты утром фиксишь баг в PHP‑монолите, днем учишься писать микросервис на Java, а вечером деплоишь все на staging — мозг начинает греться.

Было ощущение, что работаем в двух реальностях одновременно. Но никто не уехал в направлении «Канатчикова дача» (москвичи и любители творчества В.Высоцкого поймут). Хотя моментами было близко к этому.

Сколько времени занял путь от “Java for Dummies” до “Пишем прод”

(В.Г.): Первые пробные шаги в сторону Java мы начали делать еще в 2018 году. Тогда это были скорее эксперименты: изучение экосистемы, «пробы пера» с микросервисами, попытки разобраться, как вести проекты без привычного PHP‑монолита. Никто не ставил задачу «запустить в прод к НГ 2019». Это была плавная разведка боем.

Но уже в 2020 году мы вышли в прод с первым клиентским решением на Java. То есть от первых экспериментов до полноценной продакшен‑системы прошло около 1,5 лет. И это при том, что:

• никто не сидел на курсе Java с утра до вечера — обучение шло параллельно с проектной работой;

• команда одновременно поддерживала и развивала проекты на PHP;

• стек и архитектура рождались прямо на месте — не по шаблону, а по живым требованиям платформы.

Сравните: типичный онлайн‑курс по Java для начинающих (например, в США на Coursera) рассчитан на 3–6 месяцев при условии нескольких часов в неделю. Bootcamp'ы и коммерческие интенсивы — на 4–9 месяцев при полной занятости. После этого человек, в лучшем случае, выходит на уровень «я джун».

У нас же разработчики не просто «выучили язык», а начали писать рабочие сервисы в связке с фреймворками (Spring, Hibernate, Kafka), настраивали CI/CD, проектировали API. По сути, за это время они выросли от опытных PHP‑разработчиков до Java‑инженеров уровня middle и выше, но с пониманием предметной области, архитектуры и уже работающим продом за плечами.

Также можно сравнить, что типичная карьера Java‑разработчика до уровня самостоятельной разработки в проде занимает 1,5–2 года после переобучения. Мы этот путь прошли быстрее — за счет вовлеченности, правильного менторства и задач, которые с самого начала были реальными.

Так что «полтора года до прода» — это интенсивный, но достижимый производственный цикл переобучения команды с сохранением качества, темпа и получения искомого бизнес‑результата.

Какие практики оказались наиболее полезными

(В.Г.): Оказалось, что лучшее, что можно сделать — это вести базу знаний. Не в духе «поместим все в Confluence и забудем», а именно живую, с:

• архитектурными схемами,

• примерами кода,

• типовыми решениями задач,

• граблями и обходными путями.

А еще — вовлекать людей через практику. Самый крутой способ обучения: берешь задачу «из песочницы» и делаешь рабочий модуль.

Как устраняли разрыв между динамической (PHP) и статически типизированной (Java) разработкой

(В.Г.): Для наших PHP‑разработчиков, уставших от ошибок типа Call to undefined method stdClass, переход в мир строго типизированных классов был скорее облегчением. Да, нужно больше писать. Но и IDE подсказывает больше, и багов на ровном месте меньше. Так что никакого «культурного шока» не случилось — скорее наоборот: наконец‑то можно наводить порядок.

Мысль простая: если ты долго работаешь с динамической типизацией, то к определенному моменту у тебя появляется устойчивая аллергия на магические баги. На переменные, которые «иногда массив, а иногда строка», на null, который прополз в самое неожиданное место, или на →name, который сработал на одном окружении, но не на другом.

В Java такие трюки не пройдут: если метод не существует — он даже не скомпилируется. И это оказалось не тормозом, а наоборот — опорой. Да, код становится иногда больше бойлерплейта. Зато IDE (будь то IntelliJ IDEA или Eclipse) понимает весь типовой граф, автодополнение работает как надо, и можно быть уверенным, что если компилируется — то оно, скорее всего, работает.

Мы подошли к вопросу прагматично:

• Разбирались в core‑принципах типизации: наследование, интерфейсы, generics;

• Учились правильно использовать аннотации и валидацию на уровне моделей (например, @NotNull, @Size, @Pattern);

• Обращали внимание на такие вещи, как DTO vs Entity, чтобы не городить бесконечно мутирующие объекты, как это часто происходит в PHP;

• Стали по‑новому относиться к ошибкам — они теперь всплывают раньше, на этапе компиляции, а не в проде (баги особенно любят всплывать ночью).

Один из наших разработчиков после нескольких месяцев на Java написал в командный чат: «Раньше я боролся с багами после релиза. Теперь они не дают мне собрать проект».

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

Отдельный бонус — тестируемость. С жесткой типизацией стало проще писать unit‑тесты и «мокать» зависимости. Компилятор стал нашим первым «ревьюером».

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

Вывод: в PHP ты просто надеешься, что переменная содержит то, что надо. В Java ты уверен, потому что компилятор тебя не пустит дальше.

Что использовали из фреймворков

(В.Г.): Тут трудно быть оригинальными:

• Spring Boot — база всей архитектуры.

• Spring Security, Spring Data, Spring Cloud — как по нотам.

• Немного Quarkus — пробовали на легких сервисах.

• Hibernate — тут еще скажу ниже.

Вот как‑то так.

А песочница была?

(В.Г.): Обучение не было отвлеченным от практики. Песочница — это наш боевой тренажер, где каждая задача выглядела как мини‑проект. Разработчик учится, но при этом пишет компонент, который позже идет в прод. Это экономило время и сразу окупало обучение.

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

Сразу договорились: обучение — это не просто «посмотри курс и поставь галочку», а включение в реальную разработку. Поэтому в программу входили конкретные практические задачи — например, сделать законченный модуль ядра платформы. Не «в вакууме», а с настоящим API, базой данных, бизнес‑логикой и UI.

Пример из песочницы:

Одна из типовых задач — модуль управления производителями. Это, казалось бы, простой CRUD‑список (create/read/update/delete), но с деталями:

• фильтрация, сортировка, пагинация;

• типовой интерфейс;

• бизнес‑валидация;

• интеграция с системой конфигураций;

• частичная генерация кода (через внутренний генератор);

• остальное — руками, чтобы разобраться в архитектуре.

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

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

Как оценивали готовность разработчиков

(В.Г.): Сначала — этим экзаменатором был я как CTO. Потом — core‑team. По‑домашнему: без сертификаций и тестов. На деле все видно по диалогам, code review и архитектурным решениям. Если разработчик говорит «давайте вынесем этот сервис в отдельный контейнер и повесим circuit breaker» — это уже не джун.

Как изменилась структура команды после обучения

(В.Г.): Java‑архитекторы не пришли снаружи — они выросли из core‑команды, которая участвовала в создании платформы с нуля. Границы между ролями размыты: если ты эксперт в части платформы, ты и отвечаешь за ее развитие. Все по‑честному.

Рыбацкие истории о том, что пошло не так 

(В.Г.): Hibernate. Он может быть полезным, а может — устроить ад. Без глубокого понимания, как он работает внутри, можно получить неочевидные проблемы с производительностью. Нам пришлось пересматривать стратегию его использования, обучать разработчиков более глубоко и внедрять ограничения.

Учитесь на чужих ошибках: Hibernate — не магия, а инструмент. Используйте его с умом.

Итог: стоит ли повторять наш путь?

«Ха‑ха, лучше не ходить по этой дорожке», — улыбается CTO Compo Soft.

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

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

Заключение

Переход с PHP на Java в Compo Soft был не просто сменой языка. Это была смена мышления: от скриптов к архитектуре, от костылей к контрактам, от «лишь бы работало» — к «это можно масштабировать и сопровождать».

И если вы стоите перед выбором — менять стек или нет — подумайте не только о технологиях. Подумайте, готовы ли вы и ваша команда расти вместе с системой. Если да — идите не оглядываясь, и все получится.