Внес правки в светлую тему

1. Вернул поиск.
2. Поправил стили.

О созерцании шума ИТ-рынка

Эта статья не про рынок вакансий. Она про то, почему попытка понять ИТ-рынок через вакансии создаёт иллюзию контроля и мешает принимать правильные решения — как разработчикам, так и тем, кто их обучает.

Далее 👉 https://job4j.ru/article/view/11

Testcontainers

Добавил на платформу поддержку интеграционных тестов через docker.socket + testcontainers.

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

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

Раньше я также был большим сторонником модельных (unit) тестов. Однако со временем пришёл к выводу, что в прикладных сервисах правильнее делать упор на интеграционные тесты. Причём они должны начинаться с уровня API — то есть покрывать целостный процесс, а не проверять локальное состояние отдельных компонентов.

Стратегии развития разработчика: пожарный и хранитель процесса

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

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

Но эта статья не про меня. Она про вас — разработчиков, которым нужно понимать:

Далее 👉 https://job4j.ru/article/view/12

Комментарий как след процесса

В своих курсах по Java я много лет настоятельно рекомендовал не использовать комментарии внутри методов. Я прямо говорил: если внутри метода появился комментарий — это code smell.

Логика была простой:

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

Я думал в рамках задач.

Далее 👉 https://job4j.ru/article/view/13

Давайте отделим мух от котлет

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

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

Далее 👉 https://job4j.ru/article/view/14

GoLang, Финтех, какие сложности возникли

В этом видео рассказываю о сложностях, которые возникли у меня в финтехе на стеке GoLang. Рассказываю о переходи на процессинговое мышление.

https://www.youtube.com/watch?v=WqRwWaROees

Запускаю потоки. Почему я меняю формат обучения.

Долгое время обучение в Job4j выглядело так.

Я даю доступ.
Я рядом.
Я проверяю задания.
Я отвечаю на вопросы.

Инициатива — у ученика.

Психологически это комфортная модель. Можно учиться в своём темпе. Можно делать паузы. Можно вернуться позже.

Но за годы я увидел закономерность.

Сначала ученик активно решает задачи.
Потом наступает неделя тишины.
Я пишу: «Как дела?»
В ответ — загрузка на работе, личные сложности, не успеваю.

Это нормально. Это жизнь.

Но дальше человек постепенно выпадает из процесса.

Особенно ярко я это увидел на курсе по DevOps.
В начале — высокая активность.
К середине курса — многие уже “взяли нужное” и замедлились.
Формально они что-то получили.
Но процесс остался незавершённым.

И здесь я понял важную вещь.

Когда ученик один на один со мной — ответственность только передо мной.
А это слабая модель.

Потому что в ней всегда можно сказать: «Зайду попозже».

Почему появляются потоки

Поток — это не просто группа.
Это завершённый процесс с чёткой структурой.

У любого инженерного процесса есть:

— точка входа
— ритм движения
— чекпоинты
— definition of done
— точка выхода

И результат не размазан во времени.

Мы приходим к конкретному состоянию.
Не к «я что-то посмотрел»,
а к «я готов к следующему шагу».

В Java — это готовность к входу в IT или переходу на junior backend.
В Go — это переход на middle+ уровень мышления и ответственности.

Теперь процесс контролируется системой, а не настроением ученика.

Есть ритм.
Есть еженедельные чекпоинты с вебинарами.
Есть фиксированная точка завершения.

Ты либо проходишь весь цикл,
либо осознанно выходишь из него.

Java поток — вход в IT

Старт: 1 марта 2026
Длительность: 2,5 месяца

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

Go поток — второй шаг (Middle+)

Старт: 1 июня 2026
Длительность: 2,5 месяца

Здесь результат — не просто знания.
А изменение способа мышления: процессы, границы, риски, архитектура.
И применение этого в реальных проектах и на собеседованиях.

Что будет с теми, кто уже учится?

Ничего не меняется.

Если вы уже в системе, вы продолжаете обучение в прежнем формате:

— решаете задачи
— получаете проверку
— задаёте вопросы
— получаете обратную связь

Потоки — это новый формат набора, а не отмена старого.

Я долго к этому шёл.

Пробовал мотивировать индивидуально.
Возвращать. Подталкивать.
Но понял: индивидуальная мотивация слабее системной.

Теперь будет процесс с definition of done.

И моя задача как автора — довести ученика до завершённого результата, а не оставить его где-то посередине.

Если вы хотите пройти весь цикл, а не “взять кусочек” —
присоединяйтесь к потоку.

Я отменяю мартовский поток по Java

Старт 1 марта не состоится.

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

Но за последние месяцы я пересобрал своё понимание того, как сегодня нужно учить backend-разработке.

Рынок изменился.

Раньше было достаточно:
– выучить язык
– пройти структуры данных
– разобрать архитектурные принципы

Сегодня этого недостаточно.

Сейчас junior должен уметь:
– зайти в существующий сервис
– добавить фичу
– изменить схему БД
– интегрироваться с другим сервисом
– не сломать контракт
– пройти код-ревью

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

Я не хочу запускать поток по инерции или ради дедлайна.

Поэтому мартовский запуск отменяется.

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

Ориентировочный запуск обновлённого потока — осенью.

Старый формат обучения больше запускаться не будет.
Дальнейшее обучение будет проходить только в формате потоков по новой программе.

Лучше запустить позже, но сделать правильно.

Про раздел «Экзамены»

Я принял решение убрать экзамены из текущего формата обучения.

Изначально они задумывались как подготовка к собеседованию — проверка теории и закрепление материала.

Но на практике получилось иначе.

Подготовка к экзамену и сдача теории разрывают главный процесс — написание кода.
Человек переключается в режим “учить ответы”, а не “решать задачи”.

А реальный путь разработчика выглядит так:

учимся писать код → готовимся к собеседованию → выходим на работу.

Подготовка к собеседованию — это отдельный этап.
Со своей логикой, своими форматами и своей интенсивностью.

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

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

Запускаю мини-группы для завершения уровней

Перед переходом на потоковую модель нужно корректно закрыть старый формат.

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

Обучение — это не кружок программирования.
Цель — научиться мыслить инженерно и реализовывать это в коде.

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

Расписание:

Уровень Стажёр — 14:30
Уровень Джуниор — 15:00
Уровень Мидл + DevOps — 15:30

Если вы не завершили уровень и уже делаете задачи следующего — переходите в группу следующего уровня.
Перепрыгивать уровень без завершения нельзя.

Формат работы:

— еженедельный созвон
— фиксация текущих задач
— контроль прогресса
— движение к завершению уровня

Мини-группы будут работать до 1 июня 2026 года.
После этой даты старый формат полностью закрывается.

Если хотите участвовать — напишите мне в личные сообщения: @parsentev
Укажите свой уровень и какую задачу сейчас делаете.

В эту субботу проведём первый созвон.

Сегодня провёл первые синки с мини-группами по всем уровням.

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

Ещё раз проговорили важную вещь:
цель — не просто “закрыть задачи”, а выстроить инженерное мышление.
Теория не ради теории. Практика не ради галочки.

Зачем нужны созвоны?

Не для контроля.
Не для отчётов.
А для ритма.

Когда есть регулярная точка фиксации прогресса — процесс перестаёт растягиваться на годы.

По поводу записей.

Это не лекции и не вебинары.
Это рабочие синки. Формат построен на участии и личной ответственности.

Записей не будет.

Если вам нужен только материал — он доступен.
Если нужен результат — нужен ритм.

Следующий синк — через неделю.

Performance Review — зеркало требований компании

Сейчас в компании, где я работаю, проходит Performance Review — регулярная оценка инженеров, по итогам которой принимаются решения о бонусах и повышениях.

Интересное наблюдение.

В сложных продуктовых компаниях с высокой ценой ошибки на review почти не обсуждают количество задач или знание инструментов.

Смотрят на другое:

— снижает ли инженер риски
— понимает ли доменную модель
— усиливает ли устойчивость сервиса
— влияет ли на предсказуемость системы

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

Мой курс много лет учил инженерной грамотности — и это важно.
Но в таких компаниях этого уже недостаточно.

Именно поэтому я пересобираю формат обучения.

Почему большинство разработчиков остаются middle

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

И всё равно оставаться middle.

Потому что переход на следующий уровень — это не про глубину технологии.
Это про смену масштаба мышления.

Возьмём простую задачу: добавить поле в API.

Middle думает:
- как правильно реализовать
- как сделать миграцию
- как написать тесты

Senior задаёт другие вопросы:
- зачем это поле появилось?
- кто его будет использовать?
- меняется ли контракт?
- ломаем ли интеграции?
- влияет ли это на отчёты или расчёты?
- что будет при null или некорректном значении?
- как это изменение вписывается в общий процесс?

Middle отвечает за реализацию.
Senior отвечает за последствия.

И нет, senior — это не человек-оркестр.

Он не забирает работу аналитика.
Не выбирает стратегию компании.
Не пишет за архитектора.

Но он понимает, в какой системе работает.
Понимает ограничения.
Понимает договорённости.
Понимает риски.

Он расширяет не роль.
Он расширяет ответственность.

Пока ты мыслишь границами тикета — ты middle.

Переход начинается тогда, когда ты начинаешь видеть цепочку:

пользователь → API → данные → интеграции → SLA → операционный процесс.

Если твой код ломает цепочку — это уже не “просто поле”.

Именно здесь начинается рост к senior.
А дальше — к архитектуре.

Поэтому и появился трек «Процессинговое мышление».

В базовом курсе мы разбираем инструменты и практики.
В этом треке смотрим на те же задачи иначе —
не как на набор техник,
а как на элементы системы.

Рост происходит не тогда, когда ты знаешь ещё один фреймворк.
А тогда, когда начинаешь видеть систему целиком.

Завтра очередные созвоны с мини-потоками.

В этот раз встречи проведут наставники:

• 1 уровень и 3 уровень — Стас
• 2 уровень — Алексей

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

Такие созвоны нужны прежде всего для ритма движения. Когда есть регулярная точка контроля, гораздо проще не выпадать из процесса и двигаться по программе.

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

Миф: плохое собеседование — это слабый публичный след

Сейчас многие разработчики не ходят на собеседования не потому, что им неинтересно.
А потому что не готовы.

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

Что останется такой след:
не дотянул, поплыл, не вывез.

Но в реальности собеседование — это не приговор, а практика в боевых условиях.

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

Именно поэтому на собеседования стоит ходить, даже когда ты не в поиске.

Плохое интервью — это не крест на профиле.
Это способ увидеть рынок, проверить себя и понять, что подтянуть.