Великий pull request рев'ю не проходить - він проходить «апрув». На 50 рядках рев'юер знаходить проблеми, на 2000 - гортає й пише «LGTM». Якість рев'ю падає разом з розміром.
Чому маленькі PR кращі:
- швидше рев'ю: 15 хвилин легко знайти між задачами, дві години - ні. Великі PR лежать днями;
- якісніше рев'ю: у фокусі одна ідея, помилки помітніші;
- менше конфліктів: гілка живе годину чи день, а не тиждень;
- простіший відкат: якщо щось зламалося, відкочується одна невелика зміна;
- зрозуміла історія: кожен PR - окремий логічний крок.
Орієнтир: до кількох сотень рядків змістовних змін. Згенеровані файли, lock-файли й міграції з даними рахуються окремо.
Як розбивати велику задачу:
- підготовчий рефакторинг окремо: перейменування, винесення класу, зміна сигнатури - без зміни поведінки, тому рев'ю швидке;
- шарами: спершу міграція й модель, далі сервіс з тестами, потім контролер і інтерфейс;
- за прапорцем функції (feature flag): незавершена функціональність потрапляє в
mainвимкненою, і можна вливати частинами; - механічні зміни окремо від логіки: масове форматування чи перейменування в одному PR, нова поведінка - в іншому. Інакше справжня зміна губиться серед сотень рядків шуму.
Чого уникати:
- змішувати кілька непов'язаних змін «раз уже я тут» - кожна ускладнює рев'ю й відкат;
- розбивати так, що окремий PR не має сенсу й не проходить тести - кожен крок має лишати
mainробочим.
Якщо PR все ж великий - напишіть в описі, з чого почати читання, і проведіть рев'юера за ключовими файлами.
