Автор: Перший мій code review був жахливим. Я залишив двадцять коментарів про відступи й назви змінних, а справжню проблему з транзакцією в базі пропустив. Колега тоді промовчав, але я запам’ятав, що рецензія — це не про те, щоб показати, який ти уважний.
Головне питання на рев’ю звучить просто: чи зробить цей код те, що має, і чи не зламає чогось іншого? Спершу читайте опис і розумійте мету. Тільки потім дивіться на деталі. Якщо логіка хибна, сперечатися про пробіли немає сенсу, а для стилю є лінтер і форматувальник, які не ображаються.
Коментарі краще писати як питання або пропозиції, а не вироки. «А що буде, якщо список порожній?» працює краще за «Ти не врахував порожній список». Зміст той самий, а реакція зовсім інша. Позначайте, що критично, а що лише побажання, наприклад префіксом nit. Тоді автор одразу бачить, на що витрачати час.
Про розмір. Зміна на дві тисячі рядків не рецензується, її лише ставлять «апрув». Якщо ви автор, ріжте роботу на невеликі частини по двісті-чотириста рядків. Рецензенти скажуть вам спасибі, а помилки знаходитимуться швидше. Якщо ви рецензент, не соромтеся просити розбити зміну.
Не забувайте хвалити. Якщо побачили елегантне рішення чи добре написаний тест, скажіть про це. Це не лестощі, а сигнал, який практики варто повторювати. Команда, де рев’ю складається лише з претензій, швидко вчиться ховати зміни від колег.
Нарешті, швидкість. Рев’ю, що висить три дні, блокує людину сильніше за будь-яку помилку в коді. Домовтеся в команді про розумний термін відповіді, скажімо, до кінця наступного робочого дня. Це проста домовленість, але саме вона помітно прискорює весь процес розробки.
