Evitare lo scope creep¶
Lo "Scope creep" si verifica quando l'elenco dei problemi risolti o delle funzionalità implementate da un singolo contributo cresce significativamente al di là di quanto previsto all'inizio del lavoro. Si inizia con un semplice problema; si scopre un problema strettamente correlato e si decide di includere anche quella soluzione; poi una terza… prima di rendersene conto, si ha una richiesta di pull che chiude 5 problemi e aggiunge 3 nuove funzionalità, comprese decine di file.
Lo Scope Creep capita a tutti. È un concetto fin troppo familiare agli sviluppatori esperti; tutti noi l'abbiamo fatto più volte e abbiamo sperimentato tutti i problemi che ne derivano.
Ci sono ragioni molto pratiche per evitare lo scope creep. Più un contributo diventa grande, più è difficile lavorarci. Diventa più difficile identificare i casi limite o i problemi potenziali, il che significa che la qualità complessiva del contributo può diminuire. Anche le revisioni diventano più impegnative quando il revisore deve occuparsi di più contesti, potenzialmente non correlati. Un contributo più grande significa più commenti di revisione e, come collaboratore, può diventare difficile seguire più thread di revisione. Anche l'esperienza su GitHub ne risentirà: l'interfaccia utente di GitHub rallenterà con l'aumentare delle dimensioni di una PR, il che significa che navigare i file attraverso l'interfaccia di GitHub e tentare di lasciare commenti di revisione diventa sempre più difficile.
Ogni volta che trovate un motivo per aggiungere al vostro contributo qualcosa che non fa esplicitamente parte della proposta originale o della segnalazione di un bug, dovete considerare se state andando incontro a un'espansione dell'ambito. Ci sono due caratteristiche distinte che potrebbero essere implementate separatamente? È possibile implementare una funzionalità con una limitazione o un bug noto, e risolvere tale bug in una richiesta di pull successiva? Una parte della correzione di un bug è indipendente da un'altra? Se una parte di un cambiamento può essere esclusa senza alterare il contributo originale, probabilmente dovrebbe esserlo.
Lo sviluppo di software è sempre un processo di miglioramento incrementale. Ogni singolo contributo dovrebbe lasciare la base di codice in uno stato migliore dopo la fusione, ma è del tutto accettabile lasciare bug o parti di funzionalità come lavoro per miglioramenti futuri. Questo può significare suddividere una richiesta di pull in più parti che possono essere riviste in modo indipendente, oppure registrare un problema in modo che qualcun altro possa indagare e risolvere il problema.
Limitare la portata di ogni contributo aiuta tutte le persone coinvolte, voi compresi. I revisori, e anche voi stessi, lo apprezzeranno.