Code review в Go: что проверять и как давать обратную связь новичкам

Code review в Go: что проверять и как давать обратную связь

Code review (ревью кода) — это не просто формальная проверка перед мержем пул-реквеста. Это мощный инструмент для повышения качества кода, обмена знаниями в команде и предотвращения ошибок на ранних этапах. Для начинающих Go-разработчиков участие в ревью может казаться стрессом: страшно получить замечания или, наоборот, пропустить критическую ошибку. В этой статье мы разберем, на что обращать внимание при ревью Go-кода, и как давать обратную связь так, чтобы она была полезной, а не обидной.

Почему code review важен именно в Go?

Язык Go создавался с упором на простоту, читаемость и надежность. Однако простота синтаксиса не отменяет сложности логики. Типичные проблемы в Go-проектах: игнорирование ошибок, неправильная работа с горутинами, утечки ресурсов. Хороший code review помогает выявить эти и другие проблемы до того, как они попадут в продакшн.

Что проверять в Go-коде: чек-лист для новичков

Чтобы ревью было системным, используйте чек-лист. Вот основные пункты, которые стоит проверять в каждом пул-реквесте.

1. Обработка ошибок (error handling)

В Go ошибки — это значения, их нельзя игнорировать. Проверяйте, что каждая функция, возвращающая error, обрабатывает его или явно передает наверх.

// Плохо: игнорируем ошибку
file, _ := os.Open("config.yaml")

// Хорошо: обрабатываем ошибку
file, err := os.Open("config.yaml")
if err != nil {
    log.Fatalf("cannot open config: %v", err)
}
defer file.Close()

Также проверяйте, что ошибки оборачиваются с помощью fmt.Errorf("...: %w", err) для передачи контекста, а не просто логируются и проглатываются.

2. Именование и читаемость

В Go приняты короткие имена для переменных (например, r для reader, w для writer) и длинные — для экспортируемых функций. Проверьте, что:

• Экспортируемые функции, типы и переменные имеют комментарии (начинаются с имени сущности).
• Имена переменных отражают их назначение (не a, b, tmp).
• Нет лишних сокращений (calc лучше заменить на calculate).

3. Работа с горутинами и конкурентность

Горутины — мощный, но опасный инструмент. Проверьте:

• Есть ли механизм синхронизации (каналы, мьютексы) для общих данных.
• Не создаются ли «утекающие» горутины (goroutine leak). Используйте контекст (context.Context) для отмены.
• Не блокируется ли горутина навсегда (deadlock).

// Пример безопасной работы с горутиной
func worker(ctx context.Context, jobs <-chan int, results chan<- int) {
    for {
        select {
        case job, ok := <-jobs:
            if !ok {
                return
            }
            results <- job * 2
        case <-ctx.Done():
            return
        }
    }
}

4. Управление ресурсами (defer)

Проверьте, что все открытые файлы, сетевые соединения, транзакции БД закрываются через defer. Это должно быть сделано сразу после успешного открытия ресурса.

// Правильно: закрываем сразу
conn, err := net.Dial("tcp", "example.com:80")
if err != nil {
    return err
}
defer conn.Close()

5. Тестирование

Новички часто забывают про тесты. Убедитесь, что для новой логики написаны unit-тесты. Проверьте:

• Тесты покрывают не только счастливый путь (happy path), но и граничные случаи.
• Используется ли t.Run для подтестов.
• Нет ли тестов, которые зависят от внешних ресурсов (БД, сеть) без моков.

Как давать обратную связь: 5 правил для новичков

Техническая часть — половина дела. Вторая половина — умение общаться. Вот как сделать ревью полезным и дружелюбным.

Правило 1: Начинайте с позитива

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

«Отлично, что использовал табличные тесты — это упростит добавление новых кейсов».

Правило 2: Объясняйте «почему», а не только «что»

Вместо «Исправь это» напишите «Давай вынесем эту логику в отдельную функцию, чтобы улучшить читаемость и переиспользование».

Правило 3: Используйте вопросительные формулировки

Это снижает защитную реакцию. Вместо «Ты неправильно обработал ошибку» спросите: «А что будет, если файл не откроется? Нужно ли обработать этот случай?»

Правило 4: Разделяйте критику и код

Не пишите «Этот код ужасен». Лучше: «В этой функции есть несколько моментов, которые можно улучшить. Давай обсудим: ...»

Правило 5: Предлагайте альтернативы

Всегда показывайте, как можно исправить проблему. Используйте блоки suggestion в комментариях.

// Было:
if len(slice) > 0 {
    // ...
}

// Предложение: используем более идиоматичную проверку
if len(slice) != 0 {
    // ...
}

Типичные ошибки новичков при code review

И напоследок — что часто делают не так начинающие ревьюеры.

• Микро-менеджмент: не исправляйте каждую запятую. Если стиль соблюдается, оставьте как есть.
• Игнорирование контекста: не предлагайте рефакторинг всей архитектуры в рамках одного PR. Это задача для отде