На что обращаете внимание при проверке кода
Что проверяют
Есть ли у вас система при ревью и умеете ли вы отделять важное от вкусовщины. Заодно оценивают, как вы пишете комментарии: ревьюер, который спорит о пробелах и пропускает сломанную обработку ошибок, команде дороже, чем полезен.
Как отвечать
Начните с контекста: что за задача и как изменение её решает. Без этого ревью превращается в чтение строк. Дальше идите по убыванию цены ошибки:
- корректность и краевые случаи: пустые данные, ошибка запроса, отмена и гонка, двойная отправка формы, повторный рендер;
- границы: не смешаны ли получение данных и отображение, не протекло ли состояние вверх без нужды, нет ли копии уже существующего компонента;
- особенности React: зависимости эффектов, подписки и их снятие, ключи списков, лишние перерисовки, размер того, что попадает в бандл;
- доступность и семантика: фокус, работа с клавиатуры, подписи к полям, альтернативный текст;
- безопасность: вставка неочищенного HTML, чувствительные данные в адресе, хранение токенов;
- тесты на новую логику и понятность имён.
Форматирование и стиль отдайте линтеру и форматтеру, чтобы они вообще не попадали в обсуждение. В комментариях разделяйте блокирующее и необязательное, объясняйте причину и предлагайте вариант.
Где спотыкаются
Превращают ревью в спор о стиле. Пять замечаний про кавычки и ни одного про то, что при ошибке сети экран остаётся в вечной загрузке.
Читают только дифф. Многие проблемы видны лишь в целом файле или в сценарии: дублирование, лишний запрос, компонент, который теперь делает две несвязанные вещи.
Пишут в приказном тоне и без причины. «Перепиши» без объяснения вызывает сопротивление, а массовый апрув не глядя хуже отсутствия ревью: он создаёт видимость проверки.