Код-ревью иногда заканчивается вопросом – не замечанием
Раньше мне казалось, что на ревью нужно найти ошибку и написать, как её исправить. Если ошибок не нашёл – ставишь апрув.
Сейчас всё чаще замечаю, что полезнее бывает спросить: "А что произойдёт, если пользователь сделает вот так?"
Код может быть аккуратным, тесты – зелёными, линтер – довольным. Но они не всегда отвечают на вопросы о том, как поведёт себя фича в реальном сценарии, кто будет поддерживать это решение и сколько придётся менять, если требования чуть сдвинутся.
Иногда после такого вопроса оказывается, что риск уже учтён, просто я его не заметил. Иногда мы вместе находим случай, который стоит покрыть тестом. А иногда выясняется, что можно решить задачу проще.
Мне особенно непросто задавать такие вопросы на ревью кода более опытного коллеги. Сидишь и думаешь: "Наверняка он это предусмотрел, просто я не понял" 😅 Но если вопрос возник, лучше всё-таки обсудить его до мержа.
А у вас было, что один вопрос на код-ревью менял решение сильнее, чем список замечаний?
· 1 ч
"А у вас было, что один вопрос на код-ревью менял решение сильнее, чем список замечаний?" Да, конечно. Более того, к любой задаче, даже если она хорошо описана, полезно подходить с долей скепсиса — и не только на этапе код-ревью, но уже в момент её постановки. Часто при формулировке задачи не учитываются какие-то внутренние процессы или бизнес-ограничения. И чем раньше задаётся правильный вопрос, тем меньше вероятность, что команда пойдёт по неверному пути и тем качественнее в итоге будет решение. Всегда прошу свою команду задавать больше вопросов, если что-то не понятно или выглядит странным.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён