[Balun.Courses] Golang на практике (Алексей Бакин)

​

Для junior go и свитчеров в backend
Пошагово пишем такс-треккер и решаем типичные backend-задачи, которые встречаются на работе: от осознанного выбора инструментов разработки до production-ready кода и интеграции бэка со фронтом

Подойдет начинающим Golang-разработчикам и свитчерам из другой предметной области

• Проходили курсы по Golang c нуля, и вместо практики получили много теории, которую непонятно, как применять
• Хотите перейти в backend — уже изучили синтаксис и пощупали основы, которые теперь нужно отточить на практике
• Учились по статьям, документации, роликам на ютубе, и запутались еще сильнее
• На собеседованиях требуют большой опыт,
и в резюме нужен проект и стек технологий коммерческого уровня

Не подойдет свитчерам из другого backend-стека

• Здесь мы изучаем Golang на практике для начинающих backend-инженеров. Если переходишь в Go из PHP, Java, С++ или других ЯП — у тебя уже есть опыт backend-разработки, потому что основные концепции схожи.
Приходи на курс «Глубокий Go», чтобы сразу погрузиться в тонкости и нюансы языка

В рамках обучения не просто напишем еще один 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++

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