Vyhýbání se rozšiřování rozsahu

K „rozšíření rozsahu“ dochází, když seznam vyřešených problémů nebo implementovaných funkcí v rámci jednoho příspěvku výrazně přesáhne původní záměr na začátku práce. Začnete s jednoduchým problémem, objevíte úzce související problém a rozhodnete se zahrnout i jeho opravu, pak třetí… a než se nadějete, máte pull request, který uzavírá 5 problémů a přidává 3 nové funkce, včetně desítek souborů.

Rozšíření rozsahu se stává každému. Je to pojem, který je zkušeným vývojářům velmi dobře známý; všichni jsme to už několikrát zažili a setkali se se všemi problémy, které s tím souvisejí.

Existují velmi praktické důvody, proč se vyhnout rozšiřování rozsahu. Čím větší je příspěvek, tím obtížnější je s ním pracovat. Je těžší identifikovat okrajové případy nebo potenciální problémy, což znamená, že celková kvalita příspěvku může být snížena. Recenze se také stávají náročnějšími, když recenzent musí řešit více potenciálně nesouvisejících kontextů. Větší příspěvek znamená více recenzních komentářů a jako přispěvatel může být obtížné sledovat více recenzních vláken. Utrpí tím i vaše zkušenost s GitHubem – uživatelské rozhraní GitHubu se bude zpomalovat s rostoucí velikostí PR, což znamená, že procházení souborů prostřednictvím rozhraní GitHubu a pokusy o zanechání recenzních komentářů budou stále obtížnější.

Kdykoli najdete důvod přidat do svého příspěvku něco, co není výslovně součástí původního návrhu nebo hlášení o chybě, měli byste zvážit, zda se nevydáváte směrem k rozšiřování rozsahu. Existují dvě odlišné funkce, které by mohly být implementovány samostatně? Mohla by být funkce implementována se známým omezením nebo chybou a tato chyba opravena v následném požadavku na stažení? Je jedna část opravy chyby nezávislá na druhé? Pokud lze část změny vynechat, aniž by došlo ke změně původního příspěvku, pravděpodobně by tak mělo být učiněno.

Vývoj softwaru je vždy proces postupného zlepšování. Každý jednotlivý příspěvek by měl po sloučení zanechat kódovou základnu v lepším stavu, ale je zcela přijatelné ponechat chyby nebo části funkcí jako úkol pro budoucí vylepšení. To může znamenat rozdělení žádosti o stažení na více částí, které lze zkontrolovat samostatně, nebo zaznamenání problému, aby jej mohl někdo jiný prošetřit a vyřešit.

Omezení rozsahu každého příspěvku pomáhá všem zúčastněným, včetně vás. Vaši recenzenti, a dokonce i vy sami, to oceníte.