Для 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++
