> Как организован процесс перформанс ревью в команде (Go)

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

Перформанс ревью в Go-команде - это системный процесс, который включает профилирование (pprof), бенчмарки (benchmarks), анализ аллокаций и проверку конкурентных паттернов. Ревью проходит на нескольких уровнях: до merge request (статический анализ, бенчмарки), в рамках code review (внимание к hot path, избегание лишних аллокаций) и после деплоя (метрики, tracing). Ключевое - не разовое действие, а регулярная практика с фиксированными чек-листами и автоматизацией.

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

Процесс перформанс ревью в команде, работающей на Go, обычно строится вокруг нескольких этапов:

1. Автоматизированный этап - до того как код попадает на ревью, запускаются:

   • go vet и staticcheck - выявляют очевидные проблемы.
   • Бенчмарки для ключевых функций (если они есть в PR) - сравниваются с baseline.
   • Профилирование тестовых сценариев через pprof - ищем аллокации, блокировки, утечки горутин.

2. Ручной этап (code review) - ревьюер смотрит:

   • hot path: циклы, обработка запросов, сериализация/десериализация.
   • использование sync.Pool, strings.Builder вместо конкатенации, избегание fmt.Sprintf в горячих местах.
   • конкурентность: мьютексы, каналы, atomic - нет ли лишних блокировок или гонок.
   • работу с памятью: слайсы, мапы, утечки горутин.

3. Этап после мержа - мониторинг в проде:

   • метрики latency, throughput, error rate.
   • распределённый tracing (Jaeger, OpenTelemetry) для поиска узких мест.
   • сравнение с предыдущими версиями.

Важно, чтобы процесс был регламентирован: есть чек-лист, есть ответственный за перформанс (или дежурный), есть SLA на время ревью. В командах с высокой зрелостью перформанс-ревью интегрировано в обычный code review, а не выделяется в отдельную церемонию.

На практике

В реальной команде процесс выглядит так:

• В CI добавлен шаг, который запускает бенчмарки из PR и публикует результат в комментарий к MR (например, через benchstat).
• Для критичных сервисов есть нагрузочное тестирование (k6, vegeta) - запускается в staging перед релизом.
• Ревьюер, если видит потенциальную проблему, просит автора добавить бенчмарк или профиль. Это обязательное условие для merge.
• Раз в спринт проводится "перформанс-день": команда разбирает метрики, ищет регрессии, планирует оптимизации.
• Ведётся база знаний: типичные паттерны (например, "не используй fmt.Sprintf в цикле", "используй sync.Once для ленивой инициализации").

Пример чек-листа для ревьюера:

• есть ли бенчмарк для новой функции?
• не увеличилось ли количество аллокаций на запрос?
• нет ли блокировок на общем мьютексе в hot path?
• используются ли context и таймауты для внешних вызовов?
• нет ли утечек горутин (например, go func() без WaitGroup)?

Пример кода

GO
// Плохо: конкатенация строк в цикле
func buildString(parts []string) string {
    result := ""
    for _, p := range parts {
        result += p // аллокации на каждой итерации
    }
    return result
}

// Хорошо: strings.Builder
func buildString(parts []string) string {
    var sb strings.Builder
    for _, p := range parts {
        sb.WriteString(p)
    }
    return sb.String()
}

// Бенчмарк, который должен быть в PR
func BenchmarkBuildString(b *testing.B) {
    parts := []string{"a", "b", "c", "d", "e"}
    for i := 0; i < b.N; i++ {
        _ = buildString(parts)
    }
}

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

Начни с того, что перформанс-ревью - это не отдельная активность, а часть культуры инженерии. Опиши этапы: автоматизация, ручное ревью, пост-деплой мониторинг. Подчеркни важность метрик и бенчмарков, а не "чуйки". Приведи конкретный пример из практики: как нашли регрессию через pprof или как бенчмарк в CI предотвратил деградацию. Если спросят про инструменты - назови pprof, benchstat, staticcheck, go test -race, trace. Покажи, что понимаешь trade-off: перформанс-ревью не должно тормозить разработку, поэтому важно автоматизировать и не требовать микрооптимизаций там, где это не нужно.

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

Интервьюер оценивает:

• понимание жизненного цикла перформанс-проблем: от кода до продакшена;
• знание инструментов профилирования и бенчмарков в Go;
• умение расставлять приоритеты: не оптимизировать всё подряд, а фокусироваться на hot path;
• способность аргументировать решения: почему sync.Pool здесь оправдан, а где это преждевременная оптимизация;
• опыт с конкурентностью и памятью в Go.

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

• Сводить перформанс-ревью только к code review, игнорируя метрики и профилирование.
• Требовать бенчмарки на каждую мелочь - это убивает скорость разработки.
• Не учитывать контекст: оптимизация ради оптимизации, без измерения.
• Забывать про конкурентность: гонки, дедлоки, утечки горутин.
• Не иметь baseline: без сравнения с прошлыми версиями невозможно понять, стало лучше или хуже.
• Игнорировать прод-метрики: код может быть быстрым в тестах, но медленным под нагрузкой.