Undgå scope creep

"Scope creep" opstår, når listen over løste problemer eller implementerede funktioner ved et enkelt bidrag vokser betydeligt ud over det, der var tiltænkt, da arbejdet begyndte. Du starter med et simpelt problem, opdager et tæt relateret problem og beslutter at inkludere den løsning også, og så et tredje… Før du ved af det, har du en pull-anmodning, der lukker 5 problemer og tilføjer 3 nye funktioner, herunder snesevis af filer.

Scope creep sker for alle. Det er et begreb, som erfarne udviklere kender alt for godt; vi har alle gjort det flere gange og oplevet alle de problemer, der følger med.

Der er meget praktiske grunde til at undgå scope creep. Jo større et bidrag bliver, jo sværere er det at arbejde med. Det bliver sværere at identificere grænsetilfælde eller potentielle problemer, hvilket betyder, at den samlede kvalitet af bidraget kan blive forringet. Gennemgange bliver også mere udfordrende, når korrekturlæseren skal håndtere flere, potentielt urelaterede sammenhænge. Et større bidrag betyder flere kommentarer til gennemgangen, og som bidragyder kan det blive svært at følge flere gennemgangstråde. Selv din GitHub-oplevelse vil lide under det – GitHubs brugergrænseflade bliver langsommere, jo større en PR bliver, hvilket betyder, at det bliver stadig sværere at navigere i filerne gennem GitHub-grænsefladen og forsøge at efterlade kommentarer til gennemgangen.

Hver gang du finder en grund til at tilføje noget til dit bidrag, der ikke udtrykkeligt er en del af det oprindelige forslag eller fejlrapport, bør du overveje, om du er på vej mod scope creep. Er der to forskellige funktioner, der kan implementeres separat? Kan en funktion implementeres med en kendt begrænsning eller fejl, og kan fejlen rettes i en opfølgende pull-anmodning? Er en del af en fejlrettelse uafhængig af en anden? Hvis en del af en ændring kan udelades uden at ændre det oprindelige bidrag, bør det sandsynligvis gøres.

Udvikling af software er altid en proces med gradvise forbedringer. Hvert enkelt bidrag bør efterlade kodebasen i en bedre tilstand som følge af sammenlægningen, men det er helt acceptabelt at efterlade fejl eller dele af funktioner som arbejde til fremtidige forbedringer. Det kan betyde, at en pull-anmodning opdeles i flere dele, der kan gennemgås uafhængigt, eller at der logges et problem, så en anden kan undersøge og løse problemet.

At begrænse omfanget af hvert bidrag hjælper alle involverede, inklusive dig selv. Dine korrekturlæsere og endda du selv vil sætte pris på det.