Рев'ю pull request очима PM: коментарі, пропозиції, approve

Продуктова людина переглядає зміну такою, якою її побачить клієнт, а не код. Більшість роботи покривають чотири питання:

1. Чи робить зміна те, про що просили в issue?
2. Чи добре читаються тексти: формулювання, тон, граматика?
3. Чи робить вона щось, чого issue не просило?
4. Що стається у випадках, яких ніхто не описав?

Код залиш інженерам: назви, структуру, швидкодію, вибір бібліотеки чи підходу. На #134 це переглядає Oscar, і він уже схвалив. Твоє рев'ю відповідає на інше питання: «чи це правильна зміна для клієнтів?», а не «чи це добрий код?».

Якщо щось у коді все ж здається дивним, постав питання замість указівки. «Навіщо виправленню бага змінювати styles/checkout.css?» це чесне продуктове питання. «Перейменуй цю функцію» це рішення, яке ти не можеш оцінити, і воно лише додає шуму в рев'ю.

Саме тому Котокорм просить двох рев'юерів для всього, що побачать клієнти: одного для коду, другого для продукту.

Переглядай зміну там, де її зустрінуть клієнти: на preview, тимчасовій копії сайту, яку перевірка preview збирає для гілки. Відкрий посилання на пристрої, яким клієнти користуються найчастіше; у Котокорму це телефон.

Спершу точно пройди кроки автора з «How to test». Вони доводять, що основний сценарій працює. Потім спробуй крайні випадки (edge cases): рідші шляхи через ту саму функцію, яких ніхто не описав. Для виправлення кошика це:

• видаляти товари по одному кнопкою «мінус», а не кошиком для сміття;
• застосувати промокод, а тоді змінити кількість;
• редагувати той самий кошик у двох вкладках браузера;
• повністю спорожнити кошик.

Лишайся в межах функції, якої торкається pull request. Логотип на головній чи сторінка доставки не стосуються #134, тож їхня перевірка нічого не каже про цю зміну. Читати файл тестів це інженерна частина рев'ю.

Запиши, які саме випадки перевірено. Цей список піде в підсумок рев'ю й підкаже автору, які випадки вже перевірено.

У Files changed не обов'язково читати кожен файл. Кожен файл має позначку Viewed (станом на 2026 рік): познач ті, що вже переглянуто або лишено іншим, і вони згорнуться. На #134 компонент і тест належать Oscar, а файл текстів і стилі твої.

Щоб прокоментувати рядок, наведи на нього курсор і натисни синій + або протягни по кількох рядках. Під рядком відкриється поле коментаря з двома кнопками:

• Add single comment публікує одразу й сповіщає автора.
• Start a review зберігає коментар в очікуванні (pending), тож можна додати ще й надіслати все разом із вердиктом.

Коментарі в очікуванні мають позначку Pending, і бачиш їх лише ти, доки не надішлеш рев'ю. Автор отримує все одним сповіщенням із вердиктом угорі.

Обирай рев'ю, а не окремі коментарі. П'ять окремих коментарів це п'ять сповіщень посеред чужої роботи; одне рев'ю це одне сповіщення з усією твоєю думкою.

Коли виправлення це кілька точних слів, не описуй його, а напиши. На панелі коментаря є кнопка запропонованої зміни (suggestion; станом на 2026 рік маленька іконка з плюсом і мінусом). Вона вставляє блок suggestion з поточним рядком, готовим до редагування:

```suggestion
  "checkoutDisabledHint": "Your cart is empty. Add a treat to check out.",
```

Під блоком додай причину в одному рядку: «check out» тут дієслово, і тон дружніший.

Послідовність: відкрити Files changed, натиснути синій + на рядку, вставити suggestion, відредагувати рядок, додати причину, Start a review і зрештою надіслати рев'ю з вердиктом.

Автор бачить міні-diff із кнопкою Commit suggestion. Один клік перетворює твій рядок на коміт у його гілці, і GitHub указує тебе співавтором. Кілька пропозицій можна зібрати в один коміт через Add suggestion to batch.

Запропонована зміна замінює рівно ті рядки, під якими стоїть коментар, рівно тим текстом, що стоїть у блоці. Тому вона ідеальна для малих точних виправлень: слово в тексті, друкарська помилка, число, посилання, напис на кнопці. Правильну відповідь ти знаєш, а автору лишається погодитися.

Для всього більшого це не той інструмент. Якщо в оформленні замовлення потрібен інший крок, якщо цілий екран має поводитися інакше або виправлення зачіпає кілька файлів, suggestion цього не вмістить, та й обирати рішення тут, імовірно, не тобі. Опиши проблему: що видно на preview, чому це важливо для клієнтів і як виглядає добрий результат. А як цього досягти, хай вирішить автор.

Те саме з кодом, який ти не можеш оцінити. Запропонувати іншу назву функції чи переписану умову здається корисним, але перетворює продуктове рев'ю на інженерне.

Просте правило: якщо фінальний текст уміщається в один рядок, а пояснення в одне речення, пропонуй suggestion. Інакше опиши проблему.

Перевірка меж порівнює три речі: issue, опис і diff. Усе в diff, про що не згадують ні issue, ні опис, отримує питання, а не мовчазне схвалення.

У #134 issue просило робочу кнопку оформлення замовлення. А diff ще й змінив styles/checkout.css: головна кнопка всього магазину із зеленої стала помаранчевою. Технічно ніщо не заважає це змерджити. Проблема в тому, що це помітна зміна для кожного клієнта, схована у виправленні бага, яке ніхто не читатиме як редизайн.

Чому це важливо для продуктової команди:

• Якщо наступного тижня впадуть замовлення, ніхто не подумає шукати причину у «виправленні бага».
• Ефект не виміряти; така зміна заслуговує на окремий A/B-тест і власне issue.
• Відкат кольору відкотить і виправлення, бо обидва живуть в одному pull request.

Тож попроси автора винести зміну окремо. Добре питання про межі дружнє й конкретне: що зайве, чому це важливо і куди це можна перенести.

Пам'ятай, хто читатиме рев'ю: колега, який три дні працював над зміною і відкриє твої коментарі о шостій вечора. Кілька звичок роблять коментарі зручними для дії:

• Коментуй зміну, а не людину. «Яка причина зміни кольору?» питає те саме, що й «Навіщо ти це зробив?», але не звучить як допит.
• Кажи чому, а не лише що. «Це неправильно» не дає автору нічого, що можна виправити.
• Питай, коли є сумнів. «Що буде, якщо промокод сплине, поки кошик відкритий?» це справжнє питання, а не приховане звинувачення.
• Позначай дрібниці як необов'язкові. Почни з «Optional:» (деякі команди пишуть «nit:»), щоб автор знав, що це не блокує мердж.
• Кажи, що вдалося. «Підказка з'являється саме тоді, коли кошик порожній, чудово» підказує автору, що лишити.

Добрий коментар конкретний, має причину й пропонує наступний крок. Тон не прикраса: коментарі, яким радіють, і виправляють найшвидше.

Коментарі лишаються в очікуванні, доки ти не надішлеш рев'ю. Скористайся кнопкою рев'ю вгорі Files changed: станом на 2026 рік вона називається Submit review (у старіших версіях Review changes). Відкривається поле для підсумку і три варіанти:

• Comment: відгук чи питання без вердикту.
• Approve: можна зливати.
• Request changes: щось має змінитися до мерджу.

Start a review і Add single comment стоять раніше: вони вирішують, чи коментар чекатиме на вердикт, чи піде окремо. Сам вердикт завжди один із трьох.

Ті самі вердикти є й у терміналі: gh pr review 134 --approve, gh pr review 134 --request-changes -b "..." і gh pr review 134 --comment -b "...".

У схваленнях часто пишуть «LGTM», «looks good to me», «як на мене, усе добре». Нормально, якщо це правда: LGTM на pull request, який ніхто не відкривав, це найгірше рев'ю. А Request changes не грубість. Це точність: автор знає, що саме блокує мердж, а не вгадує з купи коментарів.

Вибір вердикту зводиться до одного питання: чи має щось змінитися, перш ніж клієнти це отримають?

• Якщо зміна працює, а решта зауважень дрібні й необов'язкові, натисни Approve, а зауваження лиши як необов'язкові пропозиції. Автор застосує їх зараз або пропустить.
• Якщо щось зашкодить клієнтам або не було в запиті, як-от помітна зміна кольору, неправильна ціна чи поле там, де його не має бути, натисни Request changes і назви цей блокер у підсумку.

По обидва боки дві помилки. Запит на зміни через кому затримує робоче виправлення через питання смаку. Схвалення з надією, що справжню проблему помітить хтось інший, перекладає ризик на клієнтів.

Підсумок автор читає першим, над коментарями до рядків. Напиши його у два-чотири речення: що перевірено, що працює, що блокує (якщо блокує) і чому, які зауваження необов'язкові. Тоді вердикт і коментарі розповідають ту саму історію.

Захист гілки (branch protection), або ruleset у новіших налаштуваннях, це список правил, які GitHub застосовує до гілки. У Котокорму для main їх п'ять:

• зміни лише через pull requests;
• щонайменше одне схвалення;
• перевірки build і test мають пройти;
• усі обговорення розв'язані;
• гілка оновлена відносно main перед мерджем.

Дві деталі часто плутають. По-перше, рев'ю Request changes від людини з правом запису тримає мердж, навіть коли потрібну кількість схвалень набрано. Блок знімається, коли цей рев'юер схвалить після виправлення або коли хтось із потрібними правами відхилить (dismiss) це рев'ю. По-друге, автор не може схвалити власний pull request, а в правило зараховуються лише рев'ю людей із правом запису.

Після виправлень автор повторно просить твого рев'ю (стрілки біля твого імені). Кожне обговорення має кнопку Resolve conversation; у Котокорму обговорення розв'язує той, хто його відкрив, коли задоволений. Тоді ти схвалюєш, і блок мерджу може стати зеленим.