Пошагово пишем такс-треккер и решаем типичные backend-задачи, которые встречаются на работе: от осознанного выбора инструментов разработки до production-ready кода и интеграции бэка со фронтом.
Подойдет начинающим Golang-разработчикам и свитчерам из другой предметной области.
- Проходили курсы по Golang c нуля, и вместо практики получили много теории, которую непонятно, как применять
- Хотите перейти в backend — уже изучили синтаксис и пощупали основы, которые теперь нужно отточить на практике
- Учились по статьям, документации, роликам на ютубе, и запутались еще сильнее
- На собеседованиях требуют большой опыт, и в резюме нужен проект и стек технологий коммерческого уровня
В рамках обучения не просто напишем еще один pet-проект, а на практике разберемся:
- С чего начинается разработка типичного проекта на Golang
- Какие инструменты выбирать под задачу и с чего начать, когда перед тобой пустой файл
- Как проектировать API и по каким критериям выбирать БД
- Их много, и каждая затаскивается в проект под разные задачи
- Как рефакторить код
- Разберемся с архитектурами, выберем одну из них и перепишем код с нуля
- Как создать асинхронную задачу и не потерять ее
- Научимся правильно использовать очереди и безопасно читать из них сообщения
- Что делать, если упал prod
- Сами его положим и реанимируем. Научимся тестировать, логировать и мониторить сервис, чтобы избегать инциденты
- Как подготовить код к совместной работе с командой
- Внедрим CI, линтеры и автотесты, чтобы ловить баги до сode review от коллег постарше
Бонусом интегрируем бэк со фронтом через ИИ. Иногда нужно быстро сделать простую веб-морду для бэка, чтобы докрутить MVP или упростить тестирование. Посмотрим, как с помощью ИИ можно сделать это быстро и без погружения во фронтенд.
В итоге получится таск-треккер с чистой архитектурой и масштабируемым кодом. Опыт коммерческого уровня, который можно отражать в резюме.
Программа курса
Урок №1. Ставим задачу, подбираем технологии и пишем микросервис
Теория:
- с чего начать, когда перед тобой пустой файл
- как не уйти в оверинжиниринг — учимся осознанно выбирать технологии под любую задачу, а не «тащить» все, что слышал и видел
- библиотека, сервис, тулза — чем отличается и как влияет на то, что ты делаешь
Пишем с нуля:
- HTTP-микросервис с одним эндпоинтом для мониторинга — лайф-проба, которая будет возвращать о себе базовую информацию
- клиент для HTTP-микросервиса — CLI-тулза, которая чекает мониторинг
Результат:
- освоил лучшие практики, с которых начинается разработка типичного проекта
Урок №2. Прорабатываем сценарии таск-трекера и работы с БД из Go. Пишем API
Теория: часть №1:
- для чего нужны сценарии использования
На практике:
- описываем задачу
- пишем функционал создания списка, получения и добавления элементов
- прорабатываем HTTP API
Теория: часть №2:
- какие бывают БД и как выбрать БД под задачу
На практике:
- выбираем БД из Go с пониманием — почему эта, а не другие
- делаем окружение на docker compose, запускаем Postgres
- встраиваем работу с БД в микросервис — подключение, запись и чтение данных. Делаем первые запросы
Результат:
- спроектировали API под задачу
- запустили Postgres в Docker’e и подключились к нему из БД
- написали базовый функционал таск-трекера
Урок №3. Архитектуры приложений: делаем код чистым, интегрируемся со фронтом
Функционал написан, код работает, самое время «натянуть на морду». Только senior за соседним столом пробежался глазами и сказал, что код страшный и надо рефакторить. Как теперь сделать его чище?
Теория:
- гексагональная архитектура: суть, плюсы и минусы внедрения
- слабосвязанные компоненты
- инверсия зависимостей
На практике:
- выбираем архитектуру и рефакторим под нее код
- улучшаем мониторинг — Live и Ready пробы, Healthcheck докер контейнера
- быстро пишем веб-морду с помощью ИИ, чтобы протестировать все, что получилось
- разбираем кейсы, в которых ИИ не справляется
Результат:
- узнали, как изучать разные архитектуры
- привели код в порядок
- научились интегрировать frontend
Урок №4. Очереди сообщений: как создать асинхронную задачу
У таск-трекера появились пользователи и они хотят знать, что их друзья добавляют в свои списки задач, и какие из них выполняют
Разбираемся с протоколами очередей, брокерами и прочим:
- MQTT
- AMQP
- RabbitMQ
- Распределенный лог Kafka — базовые операции
Выбираем очередь под задачу:
- какие задачи решает очередь, а какие лог
- что подходит под наш микросервис
На практике:
- проектируем эксченджи, топики и формат сообщений — проработка сценариев и фиксирование протокола
- учимся работать с AMQP из Go — подключаем, настраиваем окружение, отправляем сообщения
Результат:
- поняли, зачем и как использовать очереди сообщений в реальных сервисах
Урок №5. Обрабатываем сообщения из очереди, защищаем prod и ловим инциденты
Сообщения отправили. Что дальше? Как теперь их читать и обрабатывать? А главное — после интеграции очередей система перестала быть прямолинейной, а значит появились риски инцидентов. Как искать проблемы?
Получаем сообщения из очереди:
- подключаем и настраиваем консьюмер
- внедряем горутину-обработчик сообщений
Внедряем надежность и гарантии:
- разные политики чтения сообщений из очереди
- concurrency при чтении сообщений из очереди
Учимся искать причины неполадок:
- анализируем логи, ищем и воспроизводим баги в ручном режиме
Результат:
- научились читать сообщения из очереди и писать код, пригодный для поддержки
Урок №6. Тестируем
Искать баги вручную после запуска — тоже навык, но лучше ловить их на этапе тестирования, а не на продакшене
Теория:
- зачем нужны тесты
- где и какие тесты нужны
- организация кода, который можно протестировать
На практике:
- пишем юнит- и интеграционнные тесты
Результат:
- научились ловить баги до того, как они попадут в продакшн
Урок №7. Готовим код к совместной работе с другими разработчиками, внедряем CI
Твой код всегда будет читать и запускать кто-то ещё. Поэтому важно, чтобы он работал одинаково на любом компьютере — не только у тебя
Как собрать единое окружение и зафиксировать его, чтобы при отправке кода в GitHub всё воспроизводилось автоматически:
- одинаковые версии зависимостей (go.mod, vendor)
- одинаковые версии софта (скрипты, докер-контейнеры)
Автоматизируем поиск ошибок до code review:
- внедряем линтеры для проверки кода под общие договоренности команды
- CI — зачем нужен и как добавить
- добавляем запуск тестов в CI
Результат:
- большая часть багов ловится без твоего участия: тесты прогоняются сами, а код автоматически тестируется и валидируется линтерами до ревью
- теперь у тебя есть не только pet-проект коммерческого уровня, но и шаблон, по которому можно ориентироваться в других задачах — переиспользовать практики и ускорять свою работу
Преподает Алексей Бакин:
- Senior Go-разработчик
- 20 лет коммерческого опыта на go и C++
