Переход от Java к Go: взгляд инженера, а не фаната языка

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

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

Тем временем

Я обновил весь дизайн через GPT 5.2. Может где-то моргнул, так что смело пишите.

http://job4j.ru/

Light theme

Добавил светлую тему. В правом верхнем углу переключатель.

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

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
Укажите свой уровень и какую задачу сейчас делаете.

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

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

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

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

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

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

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

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

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

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

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

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