Кто может ставить апрув в процессе code review

Что проверяют

Как устроен процесс в ваших прошлых командах и понимаете ли вы, что апрув это ответственность за изменение, а не формальность. Следом спрашивают, ставили ли вы апрув коду старшего коллеги и что делаете, если с ревьюером не сходитесь.

Как отвечать

Начните с того, что правила задаются не традицией, а настройками репозитория, и назовите их:

• обязательное число апрувов: в GitHub это branch protection или rulesets для main, в GitLab правила одобрения merge request. Типично один или два апрува;
• владельцы кода: файл CODEOWNERS закрепляет каталоги за людьми или командами. Правка в internal/billing/ без апрува владельца не вмержится, даже если одобрили трое других;
• автор не одобряет сам себя: GitHub этого не позволяет, в GitLab это регулируется отдельной настройкой;
• сброс апрува после новых коммитов: опция, при которой одобрение старой версии не переносится на новую;
• обязательные проверки: апрув не заменяет зелёный CI, где идут go test -race, go vet, golangci-lint.

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

Если есть что рассказать про свою практику, добавьте: сколько апрувов требовалось, были ли CODEOWNERS, как быстро команда отвечала на ревью. Цифры и детали нужны ваши, не придуманные.

Где спотыкаются

Говорят «апрув ставит тимлид». Такой процесс не масштабируется: лид становится узким местом, и интервьюер это знает.

Считают апрув вежливостью. Поставить «ок», не читая, потому что автор старше, значит разделить ответственность за баг, который вы не посмотрели.

Путают ревью кода с тестированием. Апрув означает, что код понятен и корректен, а не что фича проверена вручную, и одно не заменяет другое.