Як уникнути розширення обсягу робіт

«Розширення обсягу робіт» відбувається тоді, коли перелік вирішених проблем або реалізованих функцій у рамках одного внеску значно перевищує те, що було заплановано на початку роботи. Ви починаєте з простої проблеми; потім виявляєте тісно пов’язану з нею проблему і вирішуєте включити й це виправлення; потім з’являється третя… і, перш ніж ви встигнете збагнути, у вас вже є запит на злиття, який закриває 5 проблем і додає 3 нові функції, включаючи десятки файлів.

Розширення обсягу робіт трапляється з кожним. Це поняття дуже добре знайоме досвідченим розробникам; ми всі не раз стикалися з цим і переживали всі пов’язані з цим проблеми.

Існують цілком практичні причини, щоб уникати розширення обсягу робіт. Чим більшим стає внесок, тим складніше з ним працювати. Стає важче виявляти крайні випадки або потенційні проблеми, а це означає, що загальна якість внеску може знизитися. Рецензування також стає складнішим, коли рецензенту доводиться мати справу з кількома, потенційно не пов’язаними між собою, контекстами. Більший внесок означає більше коментарів під час рецензування, і автору може стати складно стежити за кількома нитками обговорення. Навіть ваш досвід роботи з GitHub погіршиться — інтерфейс GitHub працюватиме повільніше у міру зростання розміру PR, а це означає, що навігація по файлах через інтерфейс GitHub та спроби залишати коментарі під час рецензування ставатимуть дедалі складнішими.

Щоразу, коли ви знаходите привід додати до свого внеску щось, що явно не входить до оригінальної пропозиції чи звіту про помилку, вам слід задуматися, чи не наближаєтеся ви до розширення обсягу робіт. Чи існують дві окремі функції, які можна реалізувати окремо? Чи можна реалізувати функцію з відомим обмеженням або помилкою, а потім виправити цю помилку в наступному пул-реквесті? Чи є одна частина виправлення помилки незалежною від іншої? Якщо частину зміни можна опустити, не змінюючи початковий внесок, то, ймовірно, так і слід зробити.

Розробка програмного забезпечення — це завжди процес поступового вдосконалення. Кожен окремий внесок повинен, в результаті злиття, покращувати стан кодової бази, але цілком прийнятно залишати баги або частини функціоналу для подальшого вдосконалення. Це може означати розбиття пул-запиту на кілька частин, які можна перевіряти окремо, або створення запису про проблему, щоб хтось інший міг її дослідити та вирішити.

Обмеження обсягу кожного матеріалу йде на користь усім учасникам процесу, у тому числі й вам. Рецензенти, а також і ви самі, оцінять це.