Code review как ownership и onboarding
Как организовать code review в backend-команде, чтобы сохранять качество и одновременно растить знание кодовой базы у команды?
Короткий ответ
На review стоит назначать минимум эксперта по домену и человека, который погружается в проект. Первый отвечает за correctness, второй расширяет bus factor.
Полный разбор
Практичная схема: каждый MR смотрит maintainer или domain owner, который понимает бизнес-логику и архитектурные границы сервиса. Второй reviewer может быть разработчиком, которого нужно погрузить в эту часть кодовой базы. Так review становится не только gatekeeping, но и системным onboarding.
На review нужно проверять не только style. Важнее семантика изменения, границы слоев, тесты, миграции, обратная совместимость API, observability и влияние на performance. Мелкие style-вопросы лучше автоматизировать formatter/linter-ом, чтобы люди тратили внимание на design и correctness.
Хорошая политика также ограничивает количество итераций: понятные checklist-и, маленькие MR, owners по подсистемам и быстрый feedback loop.
Теория
Code review одновременно снижает риск дефектов и распределяет знание. Если review делает только один постоянный эксперт, bus factor не растет.
Типичные ошибки
- Сводить review к naming и форматированию.
- Назначать случайных reviewers без ownership.
- Не использовать review как способ погружения в проект.
Как отвечать на собеседовании
- Скажи про domain owner плюс onboarding reviewer.
- Отдели автоматизируемый style от ручной проверки design/correctness.