> Как вести себя, если коллега предлагает решение, которое, по твоему мнению, не сработает (Go)

Короткий ответ

Сначала уточни понимание задачи и критерии успеха, затем приведи конкретные аргументы против решения: данные, метрики, ограничения системы или прецеденты. Предложи альтернативу или мини-эксперимент для проверки гипотезы. Важно обсуждать проблему, а не личность коллеги, и сохранять рабочие отношения. Если решение принято коллегиально - зафиксируй риски и предложи план B, но не блокируй работу без веских оснований.

Подробное объяснение

В backend-разработке на Go конфликт решений часто возникает вокруг производительности, конкурентности, обработки ошибок или архитектуры. Твоя задача - не победить в споре, а минимизировать риск для проекта.

Алгоритм действий:

1. Проверь собственное понимание. Возможно, коллега видит ограничение, которого ты не учитываешь. Переформулируй его предложение своими словами: "Ты предлагаешь сделать X, потому что Y, верно?"
2. Собери факты. Вместо "это не сработает" скажи: "При нагрузке 10k RPS этот подход даст блокировку на мьютексе, вот бенчмарк". Используй данные из профилирования, pprof, трассировки.
3. Предложи проверку. Если спор основан на предположениях - предложи написать бенчмарк или включить feature flag на 5% трафика.
4. Раздели риски. Есть решения, которые не сработают в принципе (например, использование sync.Map для записи в горячем пути), а есть те, которые сработают, но с trade-off (память vs скорость). Уточни, что именно ты оспариваешь.
5. Предложи альтернативу. Не критикуй в пустоту - дай конкретный вариант: другой паттерн конкурентности, иную структуру данных или подход к кешированию.
6. Эскалируй правильно. Если решение принимает тимлид или архитектор - выскажи опасения один раз, зафиксируй в задаче, но не саботируй выполнение.

На практике

Конкретные сценарии в Go:

• Гонки данных. Коллега предлагает общий map с доступом из нескольких горутин без синхронизации. Ты можешь указать на -race детектор и предложить sync.RWMutex или sharding.
• Неэффективный парсинг. Предлагают encoding/json на каждый запрос в цикле - предложи json.Decoder с переиспользованием буфера или fastjson.
• Блокирующие вызовы в HTTP-хендлере. Предлагают делать синхронный запрос к внешнему сервису - предложи таймауты через context.WithTimeout и пул соединений.
• Микросервис вместо функции. Коллега хочет вынести простую логику в отдельный сервис - покажи стоимость сетевого вызова (латенция, дебаг, деплой) и предложи оставить в монолите до реальной необходимости.

Важно: в Go культура code review и обсуждений через данные. Ссылайся на бенчмарки, go vet, staticcheck, а не на вкусовые предпочтения.

Пример кода

Ситуация: коллега предлагает использовать sync.Map для кеша с частыми записями.

GO
// Предложение коллеги
var cache sync.Map

func Set(key string, value int) {
    cache.Store(key, value)
}

func Get(key string) (int, bool) {
    v, ok := cache.Load(key)
    if !ok {
        return 0, false
    }
    return v.(int), true
}

Твой контраргумент с бенчмарком:

GO
// Альтернатива: sharded mutex
type ShardedCache struct {
    shards [16]struct {
        sync.RWMutex
        m map[string]int
    }
}

func (c *ShardedCache) Set(key string, value int) {
    shard := &c.shards[fnv32(key)%16]
    shard.Lock()
    shard.m[key] = value
    shard.Unlock()
}

Бенчмарк покажет, что при конкурентной записи sync.Map проигрывает sharded mutex в 2-3 раза из-за амортизации и интерфейсных преобразований. Это предметный разговор, а не "мне кажется".

Как отвечать на собеседовании

Расскажи историю из практики: была ли ситуация, когда ты оказался прав, и как ты это доказал. Подчеркни:

• ты не переходишь на личности;
• ты используешь измеримые критерии (latency, throughput, memory);
• ты готов проверить гипотезу экспериментом;
• ты умеешь аргументированно уступить, если данные показывают обратное.

Пример ответа: "Был случай, когда коллега предложил хранить сессии в глобальном map без TTL. Я написал бенчмарк, показал рост памяти и предложил LRU-кеш с фоновой очисткой. Мы приняли мой вариант, но я явно признал, что его подход проще в реализации - trade-off был задокументирован".

Что проверяет интервьюер

• Умение аргументировать техническую позицию без конфликта.
• Понимание trade-off в Go: конкурентность, память, простота.
• Навык работы с данными: бенчмарки, профилирование, метрики.
• Способность предлагать альтернативы, а не только критиковать.
• Уровень зрелости: готовность принять чужое решение, если оно не критично.

Типичные ошибки

• "Это не сработает, потому что я так думаю" - нет данных.
• Переход на личности - "ты не понимаешь Go" вместо разбора решения.
• Игнорирование контекста - не учтено, что решение может быть временным или для другого масштаба.
• Саботаж - молча делать по-своему после принятия чужого решения.
• Чрезмерная настойчивость - спорить после того, как решение принято и риски зафиксированы.
• Отсутствие альтернативы - критика без предложения замены воспринимается как пустое нытьё.