Вы уверены, что defer всегда безопасен?

В этой статье хочу рассмотреть поведение defer более детально. Данную статья пишется в целях "попробовать себя", а так же, надеюсь, помочь кому-то разобраться с defer.

https://habr.com/ru/articles/914642/

👉 @golang_lib

Анти-функциональные опции в Go

Часто в Go можно встретить такую конструкцию:

type Options struct {
    Timeout time.Duration
    Retries int
    Logger  *log.Logger
}

func DoSomething(ctx context.Context, opts Options) error {
    if opts.Timeout == 0 {
        opts.Timeout = 5 * time.Second
    }
    if opts.Retries == 0 {
        opts.Retries = 3
    }
    if opts.Logger == nil {
        opts.Logger = log.Default()
    }

    // дальше используем opts
}

На первый взгляд — удобно. Но на практике это ведёт к скрытым багам и неочевидному поведению. Почему?

🔸 Проблема 1: нулевое значение может быть валидным

Допустим, я хочу отключить ретраи и передаю Retries: 0. Но функция решает, что "ноль — это дефолт", и перезаписывает его на 3. В итоге получается поведение, которого явно не хотел.

🔸 Проблема 2: смешение ответственности

Функция DoSomething теперь делает больше, чем нужно: она и бизнес-логику выполняет, и значения инициализирует. Это противоречит принципу единственной ответственности и усложняет тестирование.

🔸 Проблема 3: дублирование

Если в коде много таких функций, каждая будет по-своему инициализировать Options. Это ведёт к дублированию и рассыпанной логике дефолтов.


💡 Что делать?

Вынеси дефолтные значения в отдельную функцию:

func DefaultOptions() Options {
    return Options{
        Timeout: 5 * time.Second,
        Retries: 3,
        Logger:  log.Default(),
    }
}

Теперь клиентский код выглядит явно:

opts := DefaultOptions()
opts.Retries = 0 // без ретраев

DoSomething(ctx, opts)

https://rednafi.com/go/dysfunctional_options_pattern/

👉 @golang_lib

Тестируемый код в Golang

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

Создаётся впечатление, что это самый лучший и правильный способ писать тесты, и вообще, невозможно обойтись без моков. Это не так! Можно писать тестируемый код без моков. Более того, использование моков следует избегать и использовать их только в специфичных случаях.

https://habr.com/ru/companies/skbkontur/articles/917280/

👉 @golang_lib

🏎 Вы уже сталкивались с «глухими» зависаниями и гонками данных в Go? Настало время взять каналы под контроль!

💻 На открытом уроке «Подводные камни каналов в Go — и как их обходить» 1 июля в 20:00 МСК мы не просто обсудим, что такое каналы:

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

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

👉 Регистрируйтесь сейчас и получите персональную скидку на курс «Golang Developer. Professional»: https://vk.cc/cNbzNf

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

🛠 gRPC через HTTP/3

На момент написания статьи HTTP/3 поддерживается 30,4% из топ-10 миллионов сайтов. Такое проникновение на рынок впечатляет, однако, похоже, что весь этот прогресс достигнут почти исключительно благодаря усилиям со стороны браузеров, балансировщиков нагрузки и CDN-провайдеров. А как обстоят дела с бэкендом? Как HTTP/3 чувствует себя там? Увы, ответ не столь воодушевляющий.

Именно поэтому мне стало особенно интересно рассмотреть HTTP/3 в контексте gRPC. Хотя gRPC сыграл ключевую роль в популяризации HTTP/2, то же самое пока нельзя сказать про HTTP/3 — несмотря на то, что он обещает ряд преимуществ, которые, на первый взгляд, идеально подходят для gRPC-сервисов.

В этом посте мы разберёмся, что такое HTTP/3, и исследуем убедительные причины, по которым он отлично вписывается в архитектуру gRPC-приложений. Мы рассмотрим технические улучшения, которые делают HTTP/3 более быстрым, надёжным и безопасным. Но не ограничимся теорией — мы перейдём к практике: на примерах на Go покажем, как настроить и протестировать gRPC-серверы и клиенты, работающие по HTTP/3.

К концу этого пути у вас будет чёткое понимание преимуществ HTTP/3 для gRPC, знаний о доступных инструментах для его использования уже сегодня и представление о том, какое будущее он может принести в разработку API. Пристегните ремни — впереди вас ждёт знакомство с новым поколением сетевых протоколов!

https://kmcd.dev/posts/grpc-over-http3/

👉 @golang_lib

🚀 Микросервисы — это не тренд, а стандарт. А Go — язык, который выбрали для этого стандарта в крупнейших корпорациях. Если вы уже пишете на Go, следующий шаг очевиден.

На курсе от OTUS вы освоите:

🔹 Проектирование микросервисной архитектуры на Go
🔹 Чистая архитектура, CI/CD, gRPC, REST
🔹 Логирование, Kafka, PostgreSQL, мониторинг
🔹 И многое другое!

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

Оставьте заявку прямо сейчас: https://vk.cc/cNjx7m

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

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

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

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

https://www.dolthub.com/blog/2024-07-24-static-analysis/

👉 @golang_lib

Чеклист рефакторинга

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

Чеклист:

1. Есть ли тесты?
Перед началом убедитесь, что код покрыт тестами. Если их нет — напишите.

2. Маленькие шаги.
Меняйте код постепенно. После каждого шага запускайте тесты, чтобы убедиться, что ничего не сломалось.

3. Автоматические проверки.
Используйте инструменты статического анализа и линтеры. Они помогут выявить проблемы до того, как они попадут в продакшен.

4. Ищите дублирование.
Повторяющийся код — главный кандидат для рефакторинга.

5. Упрощайте.
Если часть кода можно сделать проще — делайте.

6. Читабельность важнее.
Код читается чаще, чем пишется. Улучшение структуры и понятности всегда оправдано.

Главная цель: сделать код чище, не нарушая его поведение.

https://quii.gitbook.io/learn-go-with-tests/testing-fundamentals/refactoring-checklist

👉 @golang_lib

🚀 Вебинар: Тестируем скорость сайтов как профи с WebPageTest!

Привет, backend-разработчик! Ты уверен, что твой сайт летает, а не ползет, как улитка в пробке? 🐌💨

Бесплатный вебинар по WebPageTest покажет, как измерить скорость твоего веб-приложения без магии и шаманских бубнов: регистрация

Разберем:
✅ Как тестировать скорость правильно (спойлер: F5 – не метод)
✅ Что скрывает архитектура WebPageTest
✅ Как читать результаты тестов и не плакать

После вебинара ты сможешь:
🔹 Выбирать систему тестирования
🔹 Проводить тесты так, чтобы даже Google позавидовал
🔹 Анализировать результаты и чинить тормоза

📅 Регистрируйся → получишь напоминалку перед стартом: регистрация

P.S. Если хочешь прокачаться в оптимизации на 100%, приходи на курс «Оптимизация производительности веб-приложений». Не упусти шанс сделать сайты быстрее, чем твой коллег успевает сказать «Это не баг, это фича»! 😉

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576