Code review стоит начинать с карты риска, а не с чтения каждой строки подряд

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

Сначала понять границы изменения

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

Короткое изменение в таком месте может требовать больше внимания, чем сотня строк интерфейса. Объём сам по себе не определяет сложность проверки.

Проверять доказательства вместе с кодом

Разбор RADARON о том, как проводить code review по рискам, можно использовать как основу для собственной последовательности проверки. Она должна учитывать контекст команды, архитектуру проекта и правила доступа к данным.

Автор изменения показывает тесты, сценарий ручной проверки и наблюдаемый результат. Для миграции нужны план возврата и проверка на копии данных, для внешнего API — обработка тайм-аута и повторного запроса, для прав — отрицательные сценарии. Комментарий становится полезнее, когда объясняет риск, а не только предлагает другой синтаксис.

Разделять обязательное и улучшение

Блокирующее замечание должно относиться к корректности, безопасности или согласованным требованиям. Идею для будущего упрощения лучше пометить отдельно, чтобы она не выглядела как скрытое условие слияния.

После проверки стоит сохранить короткий список обнаруженных классов риска. Со временем он превращается в чек-лист именно этого проекта и помогает быстрее находить опасные места без механического просмотра каждой строки с одинаковым приоритетом.