Проверяешь pull requests сам или твои pull requests проверяют во время cross review

Мой подход к процессу Code Review

В моей практике используется сбалансированный подход к pull request review, который я считаю оптимальным для DevOps-команд. Этот процесс постоянно эволюционировал на протяжении моей 10-летней карьеры и сейчас представляет собой комбинацию нескольких методик.

Основные принципы моего подхода

1. Обязательный cross-review для всего кода

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

2. Ротация ревьюверов внутри команды

   • Мы используем ротационную систему назначения ревьюверов
   • Каждый ревьювер отвечает максимум за 2-3 PR одновременно
   • Это предотвращает "бутылочное горлышко" и распределяет экспертизу

3. Специализация по доменам

   • Сложные изменения в критических системах (Kubernetes, базы данных, сеть) ревьювят специалисты домена
   • Инфраструктурный код (Terraform, Ansible) проверяют минимум 2 инженера
   • Пайплайны CI/CD ревьювят разработчики + DevOps инженеры

Как организован процесс в деталях

Для моих pull requests: Я создаю PR с максимально подробным описанием:

• Контекст изменений и ссылка на задачу
• Чеклист выполненных пунктов
• Инструкция по тестированию
• Пример вывода команд/скриптов
• Оценка рисков и rollback-сценарии

Пример оформления PR:

## Контекст
Миграция конфигурации HAProxy с версии 1.8 на 2.4 для поддержки HTTP/2

## Изменения
- Обновлен Docker образ `haproxy:2.4-alpine`
- Добавлена поддержка прометеус метрик
- Конфигурация разделена на include-файлы

## Тестирование
1. Запустить staging-среду: `make deploy-staging`
2. Проверить здоровье: `curl http://staging-lb/health`
3. Проверить метрики: `curl http://staging-lb:9101/metrics`

## Риски
- Несовместимость старого формата ACL
- Требуется перезагрузка всех backend сервисов

Когда я проверяю чужие PR, я фокусируюсь на:

1. Безопасность

   # Плохо: хардкод credentials
   export DB_PASSWORD="secret123"
   
   # Хорошо: использование секретов
   export DB_PASSWORD=$(aws secretsmanager get-secret-value...)
   

2. Идемпотентность инфраструктурного кода

   # Плохо: ресурс без lifecycle игнорирования изменений
   resource "aws_instance" "web" {
     ami           = "ami-123456"
     instance_type = "t2.micro"
   }
   
   # Хорошо: правильные lifecycle правила
   resource "aws_instance" "web" {
     ami           = "ami-123456"
     instance_type = "t2.micro"
     
     lifecycle {
       ignore_changes = [ami]
     }
   }
   

3. Соответствие принципам Infrastructure as Code

4. Качество тестов и документации

5. Производительность и мониторинг

Автоматизация review процесса

Мы используем комплекс автоматических проверок:

# .github/workflows/pr-checks.yml
name: PR Validation
on: [pull_request]

jobs:
  terraform-validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Terraform Format
        run: terraform fmt -check -recursive
      - name: Terraform Validate
        run: terraform validate
        
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Trivy Vulnerability Scanner
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'

Культурные аспекты review

Я практикую конструктивный, а не критикующий подход:

• Комментарии начинаю с положительных аспектов
• Задаю вопросы, а не выдвигаю ультиматумы: "Как ты думаешь, что будет если..."
• Предлагаю конкретные улучшения с примерами кода
• Всегда доступен для синхронного обсуждения сложных моментов

Эскалация и конфликтные ситуации

При разногласиях с автором PR:

1. Обсуждаем технические аргументы с ссылками на best practices
2. Привлекаем третьего инженера как арбитра
3. Если вопрос принципиальный - проводим короткую design session
4. Все значимые решения документируем в ADR (Architecture Decision Record)

Преимущества такого подхода

✅ Знания распространяются по команде - каждый видит разные части системы
✅ Повышается качество кода - несколько пар глаз видят больше
✅ Снижаются риски - критический код проверяют специалисты
✅ Новички быстрее обучаются - через review реального кода
✅ Предотвращаем bus factor - несколько человек понимают каждую часть системы

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