Давайте начнём с честного признания. Большинство команд делают code review неправильно. Либо формально — "approve, потому что дедлайн". Либо как показатель власти — "я тут старший, сейчас научу тебя жить". Оба варианта не работают.
Pull request review — это не про поиск багов. Ну, не только про них. Это про передачу знаний, выравнивание стиля и постепенное выращивание культуры в команде. Если ваш ревью — это просто ворчание про отступы и нейминг, вы теряете 80% пользы от процесса.
Расскажу, как мы делали это в Яндексе, что работает в стартапах, и как построить процесс так, чтобы разработчики не ненавидели друг друга.
Зачем вообще нужен pull request review
Первая причина — очевидная. Найти ошибки до того, как они попадут в прод. Но если бы только ради этого, проще было бы написать больше тестов и покрыть всё 100%. Spoiler: это тоже не работает.
Вторая причина — обмен знаниями. Когда один человек долго работает над частью кодовой базы, она становится его "вотчиной". Другие боятся туда лезть. "А вдруг сломаю? Там какая-то магия". Code review принудительно размазывает знания по команде. Ты не можешь аппрувнуть то, чего не понимаешь. Приходится спрашивать, разбираться.
Третья причина — коллективная ответственность. Если код просмотрели три человека и никто не заметил критическую уязвимость, виноваты все. Это снимает стресс с автора и заставляет ревьюеров относиться к процессу серьёзнее.
Четвёртая — историческая. PR — это документация того, почему код стал таким, какой он есть. Коммит-месседжи часто врут. А вот обсуждение в треде пулл реквеста обычно содержит реальную аргументацию.
Как создать pull request на GitHub без позора
Начнём с базы. Если вы здесь впервые, коротко пройдёмся по механике.
Допустим, вы закончили работу над фичей в ветке feature/add-payment. Теперь нужно создать pull request на GitHub:
git push origin feature/add-payment
GitHub обычно сам подсказывает — видите жёлтый баннер "Compare & pull request"? Жмите. Если не видите, идите в репозиторий → вкладка Pull requests → кнопка "New pull request".
Дальше выбираете base-ветку (куда мержим, обычно main или develop) и compare-ветку (откуда, ваша feature/add-payment).
Заголовок и описание — это половина успеха. Плохой пример:
"Fixes stuff"
Хороший пример:
"Добавляет оплату картой через Stripe
- Интегрирует Stripe Checkout
- Добавляет вебхук для подтверждения оплаты
- Покрыто тестами 87% нового кода
- Breaking change: убран эндпоинт /pay/old"
Чем больше контекста вы дадите ревьюеру, тем быстрее пройдёт review. Честно. Пять минут на описание экономят час объяснений в комментариях.
Кстати, про how to delete pull request github — иногда создаваете по ошибке. Заходите в PR → внизу справа "Delete branch". Сам PR останется в истории, но ветка удалится. Если нужно удалить полностью — закройте PR, больше никто его не увидит в активных.
Размер имеет значение: как не утопить ревьюера
Вот типичная ситуация. Разработчик неделю работает над фичей. Пушит PR на 2000 строк. Ревьюер открывает, видит этот монстр, и... откладывает на "потом". Потом превращается в "никогда". Или в формальный approve "ок,".
Правило простое: PR должен просматриваться за один присест. 30-60 минут максимум. Это примерно 200-400 строк, если код нетривиальный.
На одном проекте мы ввели жёсткое правило — PR больше 400 строк требует отдельного одобрения техлида. Знаете что произошло? Размер PR упал в среднем до 150 строк. Потому что никому не хотелось объяснять техлиду, почему это один PR, а не три.
Если фича большая, разбивайте на несколько PR. Скелет → логика → UI → интеграция. Каждый аппрувится отдельно, мержится в_feature-ветку. Потом один финальный PR в main.
# .github/size-limit-comment.yml — автокоммент для больших PR
name: PR Size Check
on: pull_request
jobs:
size-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check PR size
run: |
LINES=$(git diff origin/main... --stat | tail -1 | awk '{print $4+$6}')
if [ "$LINES" -gt 400 ]; then
echo "⚠️ PR is too large ($LINES lines). Consider splitting."
exit 1
fi
Что проверять: чеклист, который реально работает
Чеклисты — это хорошо. Но чеклист из 50 пунктов никто не читает. Вот сокращённая версия, которую мы используем:
Функциональность. Код делает то, что заявлено? Edge-кейсы покрыты? Что если база упадёт прямо посреди транзакции?
Читаемость. Через полгода кто-то другой будет это читать. Он поймёт, что тут происходит? Нейминг говорящий? Комментарии нужны или код самодокументируемый?
Тесты. Есть? Покрывают сценарии или просто гоняют happy path? Моки адекватные?
Безопасность. SQL-инъекции? XSS? Секреты не закоммичены? Права доступа проверяются?
Производительность. N+1 запросы? Алгоритм O(n²) там, где можно O(n)?
Пять пунктов. Реалистично пройтись по ним за 15 минут.
Но главное — приоритизируйте замечания. Не каждое "улучшение" одинаково важно. Я делю комментарии на три категории:
- Блокеры — баг, уязвимость, критический косяк. Must fix.
- Предложения — можно сделать лучше, но работает и так. Опционально.
- Нитпики — стилистические замечания, личные предпочтения. Не блокируют мерж.
В комменте явно пишу категорию. "[BLOCKER] Тут SQL-инъекция". "[SUGGESTION] Можно вынести в хелпер". "[NIT] Лично я бы назвал по-другому, но не настаиваю".
GitHub Actions для pull request: автоматизируйте рутину
Человек плох в рутине. Машину не то что можно — нужно использовать для проверок, которые алгоритмизируются.
Линтеры, форматтеры, тесты — это должно проходить автоматически. Ревьюер не должен тратить время на "ты забыл точку с запятой" или "импорт не используется".
Базовый setup для GitHub Actions pull request:
# .github/workflows/pr-checks.yml
name: PR Checks
on:
pull_request:
branches: [main, develop]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- run: npm ci
- run: npm run lint
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- run: npm ci
- run: npm run test:coverage
- name: Check coverage threshold
run: |
COVERAGE=$(cat coverage/coverage-summary.json | jq '.total.lines.pct')
if (( $(echo "$COVERAGE < 80" | bc -l) )); then
echo "Coverage $COVERAGE% is below 80% threshold"
exit 1
fi
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
Теперь если линтер падает — PR не мержится. Ревьюер даже не смотрит на стиль, его уже проверил робот.
Но автоматизация может быть умнее. Статический анализ — Semgrep, SonarQube, CodeQL — находит реальные баги. Не "переменная не используется", а "указатель разыменовывается после проверки на null".
Типичные ошибки, которые убивают процесс review
Ошибка первая — ревью как трибунал. Автор PR чувствует себя обвиняемым. Ревьюер — прокурором. Это создаёт токсичную атмосферу. Люди начинают прятать код, делать "feature branch" на полгода, чтобы показать только готовое. Результат — ещё хуже.
Решение: меняйте тон. Не "ты сделал неправильно", а "а что если сделать так?". Не "это баг", а "как этот код поведёт себя, если...?". Вопросы вместо утверждений творят чудеса.
Ошибка вторая — approve без прочтения. "У нас deadline, мержим". Знакомо? Если ревью — формальность, лучше его отменить. Честнее. И быстрее.
Решение: защищённые ветки. Требуйте approve от минимум двух человек + passed checks. Да, это замедляет. Но это заставляет относиться серьёзно.
Ошибка третья — задержка review. PR висит три дня. Автор переключается на другую задачу. Через неделю возвращается и уже не помнит контекст.
Решение: SLA на review. Например, "ответить в течение 4 рабочих часов". Можно даже автоматизировать напоминания — бот пингует в Slack, если PR висит без движения.
Ошибка четвёртая — ревью "своих" и "чужих". Сеньоры ревьюят друг друга быстро и снисходительно. Джуниоров роют до молекулярного уровня. Демотивирует, создаёт касты.
Решение: рандомизация назначений. Или ротация — каждый ревьюит всех подряд, без.
Как сделать review полезным для всех
Главный секрет — относиться к review как к обучению, а не контролю. Автор PR учится писать лучше. Ревьюер учится разбираться в чужом коде.
Поощряйте вопросы. "Почему здесь так?" — отличный вопрос, даже если ответ очевиден опытному разработчику. Может, автор сам не думал об этом. Может, есть причина, которую стоит задокументировать.
Давайте позитивный фидбек. Не только критикуйте. "Крутой рефакторинг тут, стало намного чище" — это мотивирует. Разработчик будет стараться и дальше.
Не переделывайте за автора. Если вы можете написать лучше — объясните как. Не коммитьте "щас сам сделаю" без согласования. Это унижает и не учит.
Базовая механика review проста. Создаёте pull request на GitHub, ждёте approve, мержите. Но культура review строится годами. Автоматизируйте что можно — линтеры, тесты, безопасности. Оставьте людям то, что люди делают лучше — архитектурные решения, обмен знаниями, менторство.
Кстати, часть рутины можно делегировать AI. Distiq делает автоматический code review для GitLab, GitHub и GitVerse — находит баги, уязвимости и проблемы с производительностью ещё до того, как PR увидит живой человек. Не замена ревью, но хороший первый фильтр. У нас в команде экономит часа два в неделю на каждом разработчике.