Как происходило код-ревью в прошлой команде?

Процесс код-ревью в моей прошлой команде

В моей прошлой команде, работавшей над высоконагруженным микросервисным проектом на Go, процесс код-ревью был формализованным, но не бюрократичным — мы нашли баланс между качеством и скоростью разработки. Вот как это было организовано:

Основные принципы и инструменты

Мы использовали GitLab Merge Requests (MR) как основной инструмент. Каждое изменение, даже от самых опытных разработчиков, проходило через ревью. Ключевые принципы:

• Никаких прямых пушей в master/main — только через MR
• Обязательное approval минимум одного разработчика (для критических областей — двух)
• CI/CD pipeline должен пройти успешно перед мержем
• Все обсуждения публичны в тредах MR

Жизненный цикл Merge Request

1. Подготовка MR:

   • Разработчик создает ветку от актуального master
   • Делает изменения, соблюдая принцип единственной ответственности (один MR — одна логическая фича/фикс)
   • Пишет понятное описание с контекстом и тестированием
   • Запускает локально go fmt, go vet, golangci-lint

2. Прохождение автоматических проверок:

   # Пример .gitlab-ci.yml для Go проекта
   stages:
     - test
     - lint
     - build
   
   go-test:
     stage: test
     script:
       - go test ./... -v -race -coverprofile=coverage.out
   
   golangci-lint:
     stage: lint
     image: golangci/golangci-lint:v1.54
     script:
       - golangci-lint run --timeout 5m
   
   build:
     stage: build
     script:
       - go build -o app ./cmd/main.go
   

3. Ревью кода:

   • Автор назначает ревьюверов (обычно 1-2 человека)
   • Ревьюверы проверяют в течение рабочего дня (SLA)
   • Используем подход "ревью для обучения, а не для критики"

Критерии оценки кода на Go

При ревью мы обращали особое внимание на следующие аспекты Go-разработки:

1. Идиоматичность Go

// Плохо — неидиоматично
func ProcessData(data []string) (result []string, err error) {
    result = []string{}
    for _, item := range data {
        // ...
    }
    return
}

// Хорошо — идиоматичный Go
func ProcessData(data []string) ([]string, error) {
    result := make([]string, 0, len(data))
    for _, item := range data {
        // ...
    }
    return result, nil
}

2. Обработка ошибок и ресурсов

• Все ошибки должны быть обработаны или явно проброшены
• Использование defer для очистки ресурсов
• Проверка ошибок в многострочных цепочках вызовов

3. Конкурентность и параллелизм

• Корректное использование горутин и каналов
• Отсутствие гонок данных (обязательно -race при тестировании)
• Правильное использование контекстов для отмены операций

4. Производительность и аллокации

• Избегание лишних аллокаций в горячих путях
• Использование sync.Pool где уместно
• Бенчмарки для критического кода

Практики проведения ревью

Технические проверки:

• Соответствие SOLID принципам (особенно для пакетов)
• Качество тестов (покрытие, читаемость, отсутствие флакеров)
• Отсутствие утечек памяти и гонок данных
• Совместимость API (при изменениях публичных интерфейсов)

Человеческий аспект:

• Constructive feedback — вместо "это плохо" говорим "можно улучшить так..."
• Вопросы вместо утверждений — "Как ты думаешь, что будет при...?"
• Уважение к автору — признаем, что может быть несколько правильных решений
• Обучение на примерах — приводим ссылки на документацию или код из проекта

Особенности для Go-проектов

1. Вендоринг зависимостей:

   • Проверяем обновления версий в go.mod
   • Следим за совместимостью через go mod tidy

2. Интерфейсы и моки:

   // Правильное определение интерфейса
   type Storage interface {
       Get(ctx context.Context, id string) (*Item, error)
       Save(ctx context.Context, item *Item) error
   }
   
   // Использование для тестирования
   type mockStorage struct {
       Storage
       // ...
   }
   

3. Работа с памятью:

   • Проверяем использование указателей vs значения
   • Оптимизация под капотом GC

Эскалация и разрешение конфликтов

При спорных ситуациях:

1. Технический диалог в комментариях MR
2. При необходимости — быстрый голосовой созвон (5-10 минут)
3. В крайних случаях — привлечение тимлида или архитектора
4. Все решения и их обоснование фиксируются в MR

Метрики и улучшения процесса

Мы регулярно анализировали:

• Время от создания MR до мержа (цель < 24 часов)
• Количество итераций до approval
• Частые замечания — по ним проводили микро-обучения
• Автоматизируемые проверки — что можно перенести в линтеры/CI

Выводы и рекомендации

Такой процесс позволил нам:

• Поддерживать высокое качество кода при скорости разработки
• Распространять знания по команде
• Ловить ошибки до попадания в прод
• Обучать джуниоров через практику ревью их кода

Ключевой урок: код-ревью — это не полиция, а система взаимного обучения и улучшения качества. Для Go-проектов особенно важно сочетать автоматические проверки (линтеры, тесты) с экспертной оценкой идиоматичности и производительности кода.