Пишешь ли советы коллегам при код ревью
Что проверяют
Как вы ведёте себя в ревью: отделяете ли обязательное от вкусовщины, умеете ли объяснять причину замечания и не превращаете ли чужой пул-реквест в переписывание под свой стиль. Для команды это вопрос скорости: ревьюер, у которого всё блокирующее, останавливает поставку.
Как отвечать
Скажите, что советы пишете, и опишите систему. Замечания делятся по весу: блокирующее (ошибка, утечка, сломанный контракт, дыра в доступности или безопасности), важное, но не блокирующее, и мелочь, которую помечаете явно как необязательную. Форматирование и порядок импортов не обсуждаются вовсе, это работа линтера и форматтера, спор о них в комментариях тратит время двоих.
Дальше перечислите, на что во фронтенде советы реально нужны: нестабильные зависимости хуков и лишние перерисовки, useEffect там, где значение выводится из пропсов, ключи списка по индексу, необработанные состояния загрузки и ошибки, семантика и фокус вместо div с обработчиком клика, импорт тяжёлой библиотеки целиком вместо нужной части.
Форма важна не меньше содержания: вопрос вместо приговора («что произойдёт, если сюда придёт пустой массив?»), причина и ссылка на документацию, готовый вариант кода в предложении правки. Замечание всегда про код, не про автора. Удачные решения стоит отмечать вслух: ревью, где бывает только критика, люди начинают обходить стороной.
Где спотыкаются
Переписывают чужой код в комментариях по своему вкусу. Автор либо спорит неделю, либо молча соглашается и перестаёт приносить черновики на ранний просмотр.
Второе: не расставляют приоритет. Опечатка и настоящая гонка состояний лежат в ленте одинаково, автор перестаёт их различать и пропускает важное.
Третье: на собеседовании рассказывают заготовку про «повысил качество кода» с придуманным процентом снижения ошибок. Проверить это нельзя, звучит как шаблон. Один конкретный случай (какое замечание, почему, чем закончилось) убеждает сильнее.