Занятость: 30-40 часов в неделю
Автор: daniil_it_engineer

Language: Русский | English

• Введение
• Как читать роудмап
• Как устроен путь
• Как учиться с AI и AI-туллингом
• Как работать с требованиями
• Как оценивать время
• Источники и инструменты
• Модули
• Заключение
• Контакты

Этот роудмап показывает путь от первых шагов в Java до уровня, с которым можно уверенно идти в backend-разработку и расти дальше.

Он подходит:

• тем, кто начинает с нуля;
• тем, у кого уже есть база, но не хватает системности;
• тем, кто учился, но застрял между "что-то знаю" и "могу делать рабочий проект";
• тем, кто выходит на рынок в более жёстких условиях и хочет учиться не по хаотичным темам, а по внятному маршруту.

Предыдущая версия roadmap по-прежнему актуальна с точки зрения основного набора технологий и может использоваться как справочный материал: версия 1.1. Её ограничение не в "устаревшем стеке", а в более узкой рамке: там меньше внимания к требованиям, runtime-поведению системы, observability, AI-tooling и инженерному контексту принятия решений. Версия 2.0 не заменяет её как "единственно правильную", а расширяет и углубляет маршрут.

Версия 2.0 сохраняет цель первой версии: помочь войти в Java-разработку через понятную последовательность тем и практики. Но рынок изменился, и я вижу, что сейчас мало знать синтаксис Java и пару аннотаций Spring. От backend-разработчика ждут умения:

• собирать и проверять проект: Gradle, тесты, CI, покрытие, style checks;
• работать с данными и инфраструктурой: PostgreSQL, миграции, Docker, Kubernetes, конфигурация;
• проектировать API и сервисы: REST, OpenAPI, микросервисы по доменным границам, распределённые операции;
• обеспечивать надёжность: метрики, трассировки, логи, SLI/SLO, Circuit Breaker, идемпотентность;
• проектировать безопасный параллелизм: держать изоляцию request/message context, безопасно распараллеливать независимые I/O-сценарии и учитывать ограничения runtime, connection pool и внешних сервисов;
• использовать ИИ как инструмент: AI — не замена разработчику, а ускоритель. Навык ставить задачу AI-агенту, верифицировать результат, описывать правила проекта (CLAUDE.md, AGENTS.md, MCP) и нести ответственность за код — ожидаемая компетенция на рынке в 2026 году.

И не только этого. Разработчик, который понимает ценность того, что строит, востребованнее того, кто просто пишет код по спецификации. Бизнес-контекст — не абстракция, он конкретно проявляется в том, как формулируются требования к системе: функциональные — растут из бизнес-потребностей («система регистрирует участника» — это не CRUD, а ответ на вопрос «как организатор управляет записями без ручного отслеживания?»), нефункциональные — из бизнес-ожиданий («p95 latency < 200ms» — это не метрика ради метрики, а «пользователь не ждёт слишком долго»; покрытие тестами — не ради процента, а чтобы регистрация не сломалась после рефакторинга).

Чем больше бизнес-контекста разработчик вносит в решения — почему выбрана эта структура данных, зачем этот индекс, почему здесь Saga, а не синхронный вызов — тем выше его ценность на рынке. Этот roadmap с первого модуля учит связывать технические решения с бизнес-вопросами.

Роудмап разбит на модули. Каждый модуль отвечает на три вопроса:

1. Что нужно изучить.
2. Что должно появиться в проекте после этого шага.
3. Как понять, что модуль действительно пройден.

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

Проходить роудмап лучше по порядку. Если времени мало, некоторые вещи можно изучать параллельно, но основную техническую линию лучше не ломать: база Java → приложение → база данных и транзакции → Spring и runtime HTTP-запросов → микросервисы и fan-out → observability → события и Kafka → карьерный трек.

В основе роудмапа один проект, который развивается от простого к сложному.

Консольное приложение + Java Core + Gradle + локальные проверки + Git и PR-поток
→ более зрелая Java-логика + GitHub Actions + JaCoCo + рекомендуемые ИИ-инструменты
→ контейнеризация и локальный запуск в Docker
→ PostgreSQL + JDBC + транзакции и конкурирующие регистрации
→ REST API на Spring Boot + request-context и безопасный shared state
→ микросервисная архитектура + параллельные вызовы к независимым сервисам
→ Kubernetes и наблюдаемость + trace/метрики для fan-out сценариев
→ Kafka + saga/outbox + consumer parallelism, message-local context и DLQ
→ подготовка к поиску работы

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

ИИ нужен не для замены разработчика, а для ускорения разработки и обучения.

Главный принцип: ИИ не заменяет ответственность. ИИ ни перед кем не отвечает. Отвечает только разработчик.

Как использовать по ходу roadmap:

• Модуль 1: чат (DeepSeek или Qwen Chat), официальный гайд и базовая работа в IDE. Этого достаточно, чтобы разбирать Java Core, ошибки сборки, Git, Gradle и первые тесты.
• Начиная с модуля 2: можно подключать более взрослые ИИ-инструменты: OpenCode, Kilo, Codex или другой CLI/IDE-агент, который видит кодовую базу. Это рекомендуемый слой, а не обязательный барьер для прохождения roadmap.
• На Windows: базовый путь — WSL2 + Java/Gradle/Git внутри WSL + IntelliJ IDEA/OpenIDE как основная IDE. Терминал агента на старте лучше держать прямо в IntelliJ, закрепив его справа как отдельную рабочую панель.

Базовые правила:

• Для чата: задавай вопрос с контекстом, проси объяснение причины и не копируй ответ в проект без проверки.
• Для агента (AI Pair Programming): сначала Plan Mode: цель, контекст, ограничения, критерии готовности. Только после понятного плана агент пишет код. Человек проверяет результат через diff, тесты, сборку и собственное понимание.
• Для правил проекта: AGENTS.md, CLAUDE.md, .rules и skills должны быть короткими. В них хранится стек, команды проверки и ограничения проекта, а не конспект курса. Чем больше постоянных инструкций, тем хуже модель держит фокус.
• Для сессий: новая задача — новая сессия или compact. Не тащи старый шумный контекст в новую работу.
• Если вопрос зависит от версии библиотеки, плагина, конфигурации или внешнего сервиса, ответ нужно сверять через MCP, официальный источник или актуальный web research.
• Итог всегда проверяется через код, сборку, тесты, запуск и логи.

В каждом модуле есть два слоя результата.

Функциональные требования отвечают на вопрос: что система должна уметь делать.
Нефункциональные требования отвечают на вопрос: как качественно и надёжно это должно работать.

Простой пример:

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

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

Оценка задач — часть работы разработчика, а не навык «когда-нибудь потом». На одном проекте задачи могут быть уже оценены, на другом — оценку отдают тебе. Но в любом случае важно понимать, за счёт чего получилась эта оценка, уметь её корректировать и задавать вопросы, если что-то не сходится. Этот roadmap даёт площадку для тренировки — я рекомендую начинать оценивать задачи с первого модуля, даже если оценки пока грубые.

Чтобы не теряться, оценивай модуль не целиком, а по частям:

• анализ требований и бизнес-контекста: что именно нужно сделать и зачем;
• изучение темы;
• настройка среды;
• написание кода;
• отладка;
• проверка результата.

Нормальная схема оценки:

время на модуль = анализ требований + чтение + практика + исправления + проверка + запас 30%

Если коротко:

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

Ниже собраны базовые внешние источники и инструменты, которые полезны по всему roadmap.

Чтобы оценка не была "на глаз", удобно разделять две вещи:

• метод оценки: как понять размер задачи;
• инструмент фиксации: где хранить план, заметки и сроки.

• Хабр: Оценка задач в Story Points
  Хорошее русскоязычное введение в story points, относительную оценку и связь оценки с реальной работой команды.

• Хабр: Покер планирование
  Короткое и понятное объяснение planning poker, если хочешь понять саму механику коллективной оценки.

• Atlassian: Story points and estimation
  Официальная база про относительную оценку, planning poker, сравнение задач между собой и пересмотр прошлых оценок.

• Atlassian Support: Estimate a work item
  Полезно, если хочешь понимать, как оценки живут в реальном трекере задач.

• Atlassian Support: Time estimates
  Нормальный ориентир, когда удобнее оценивать не в относительных единицах, а во времени.

Начиная с модуля 2 roadmap опирается на практику парного программирования из Extreme Programming (XP): два разработчика работают вместе над одной задачей, один ведёт (человек), другой помогает (AI). CLI-агент становится pair programmer — генерирует тесты, рефакторит код, помогает с boilerplate, а человек проверяет результат через метрики покрытия, тесты и сборку.

• Kent Beck: Extreme Programming Explained — классическая книга, где описана практика pair programming и другие XP-практики (TDD, continuous integration, small releases)
• Хабр: Pair Programming — когда два лучше — русскоязычный обзор практики парного программирования

Базовые:

• DeepSeek — универсальный чат для разбора тем, ошибок и быстрых вопросов. Бесплатный, работает в РФ без VPN.
• Qwen Chat — чат-альтернатива для быстрых объяснений и разбора кода.
• OpenCode — open-source агент для терминала, IDE и desktop. Recommended paid path для курса — OpenCode Go: дешёвый старт для Qwen/GLM-планирования и code review.
• Kilo — open-source AI coding agent для JetBrains/OpenIDE, VS Code и CLI. В этом roadmap основной путь — IntelliJ/OpenIDE, а не VS Code.
• Codex — агентный инструмент OpenAI для работы с кодом; может быть доступен через ChatGPT-планы и лимиты аккаунта.

Платные (опционально):

• ChatGPT — платный чат с широкими возможностями; Plus/Codex обычно ориентир $20/мес, лимиты меняются.
• Claude Code — AI-агент для терминала с доступом к кодовой базе, файлам и shell.
• GLM-5 от Z.AI — модель для agentic engineering и длинных агентных задач.

MCP для актуального контекста:

• Context7 — свежая документация библиотек и фреймворков.
• Brave Search MCP — web search для актуальных источников.
• Firecrawl MCP — scraping/crawling страниц документации, pricing и гайдов.
• Инфраструктурные MCP подключаются по мере модулей: PostgreSQL, Docker, Kubernetes, Grafana/Elastic, Kafka. Сначала read-only, write/admin actions — только с явным подтверждением.

Если нужен самый простой вариант, достаточно связки: Obsidian для заметок + Google Calendar для времени. Если нужен визуальный веб-формат в духе Notion, можно использовать Yonote.

Отдельно можно использовать Anki для терминов и понятий, которые у тебя регулярно всплывают и забываются.

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

Если пройти roadmap целиком, ты не просто «изучишь темы». У тебя будет проект, который ты провёл руками от консольного jar-файла до микросервисов с Kafka — через Gradle и тесты, Docker и PostgreSQL, Spring Boot и REST API, Kubernetes и Prometheus, события и outbox. Каждый шаг — не абстрактное упражнение, а ответ на конкретный вопрос: зачем здесь транзакция, почему этот индекс, какую проблему решает Saga, чем помогает Circuit Breaker.

Я строил этот roadmap так, чтобы технические решения не висели в воздухе. Saga нужна не потому, что это «паттерн из микросервисов», а потому что в распределённой операции нельзя оставлять систему в полусломанном состоянии. Circuit Breaker — не ради галочки в Resilience4j, а чтобы сбой одного сервиса не тянул вниз весь пользовательский сценарий. Идемпотентный consumer — не ради «правильной Kafka», а чтобы повторная доставка события не создала дубль регистрации.

Помимо кода и архитектуры, ты получишь:

• инженерную базу: сборка, CI, миграции, контейнеризация, наблюдаемость — то, что отличает проект от «у меня работает»;
• опыт работы с ИИ: от чата для разбора ошибок до CLI-агента как pair programmer — AI не заменяет ответственность, но ускоряет рутину;
• навык оценки задач: с первого модуля и до карьерного трека.

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

• Telegram канал: @mentee_power
• Личный Telegram: @daniil_it_engineer