Анти-функциональные опции в 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