Code review: come migliorare il processo

Code review: come migliorare il processo

Ascolta il contenuto dell’articolo nella puntata del Reloaded Podcast “Code Review per un codice di qualità e non solo

 

Cos’è la code review? E’ il processo di revisione del codice scritto da uno sviluppatore da parte di un suo collega per evidenziare eventuali problemi, suggerire miglioramenti o per imparare da un codice scritto da qualcun altro.

Ma cosa fare quando quando la code review diventa un rallentamento per il processo?
Nell’articolo, illustriamo quelli che, secondo noi, sono i 3 metodi più efficaci di fare code review e come poterli utilizzare per:

  • sfruttare la qualità del codice scritto
  • aumentare le competenze e la multidisciplinarietà dei team di sviluppo.

Prima di tutto, però, parliamo di pull requests.

Le pull requests

Se avete già lavorato nell’ambito dello sviluppo software, vi sarete già sicuramente imbattuti nelle pull requests.
Le pull requests (o merge request) sono un meccanismo per richiedere la revisione del codice, per cui uno sviluppatore informa il sistema che vuole unire il proprio pezzo di lavoro nel ramo principale del codice sorgente, in modo che quel pezzo venga incluso nei prossimi rilasci che andranno in produzione.
Tale pezzo di lavoro deve essere rivisto, controllato e la revisione deve avvenire da qualcun altro che dovrà approvare la pull request oppure respingerla segnalando problemi o chiedendo modifiche.

Processo di code review: 1 sviluppo funzionalità, 2 Creazione di pull request, 3 Code review e modifica del codice, 4 Unione funzionalità al codice sorgente

Le insidie delle pull requests

Le pull requests sono nate nel 2008 e introdotte da GitHub nello stesso anno. Sono state usate nell’ambito dell’open source ed erano un ottimo modo per assicurarsi, proprio grazie alla revisione, gli standard di qualità previsti in progetti che accettavano contributi esterni.
Le pull requests sono state poi adottate anche all’interno delle aziende come metodo di revisione del codice. Per quanto il meccanismo possa essere utile, può anche essere rischioso. Si rischia che diventi un modo per giudicare un codice scritto da qualcuno, soprattutto in contesti gerarchici dove il lavoro di uno deve essere sempre revisionato da un responsabile.
Un altro aspetto da tenere in considerazione è che, in termini di processo, la code review richiesta tramite pull request potrebbe diventare un collo di bottiglia.

Quando la code review diventa collo di bottiglia

Le pull requests sono un ottimo modo per evitare che entri in produzione un codice non ottimale ma anche per imparare leggendo il codice di qualcun altro. Bisogna però ammettere e affrontare che il processo stesso di pull request comporta un rallentamento di processo: si vedono team di sviluppo bloccati perché sono in attesa che qualcuno si prenda in carico la revisione del codice e quindi approvi la pull request.

3 metodi per migliorare il processo di code review

Come possiamo migliorare il processo e ridurre il rischio di ritrovarsi in una situazione di rallentamento di processo o collo di bottiglia? Per la nostra esperienza, condividiamo 3 delle pratiche che riteniamo essere d’aiuto, nonostante i loro punti critici che vedremo, e sono:

  • Kanban
  • Le pull request non bloccanti
  • Pair Programming

Vediamoli singolarmente di seguito.

Kanban

Il primo suggerimento arriva da Kanban: se stiamo sviluppando una nuova funzionalità, nella Kanban board possiamo aggiungere la colonna “review”. Al termine dello sviluppo, gli elementi del backlog passano nella colonna di “review”, in modo che vengano revisionati e poi integrati nel ramo principale del ramo sorgente.
Impostando dei limiti sul work in progress, qualcuno deve occuparsi della revisione prima di iniziare a sviluppare qualcosa di nuovo. Questo aiuta a mitigare il problema e ad evidenziare i colli di bottiglia, ma non lo risolve del tutto perché i tempi di attesa potrebbero essere lunghi da quando una funzionalità viene sviluppata a quando viene revisionata.

La colonna code review nella Kanban board

Le pull requests non bloccanti

Cosa si intende con pull requests non bloccanti? Pur mantenendo la colonna “review” nella Kanban board come nel precedente caso, le funzionalità sviluppate entrano direttamente nel ramo principale del codice sorgente e quindi la revisione viene fatta in un momento successivo.
Questo approccio, per essere efficace, presuppone che ci siano dei sistemi di continuous integration e una serie di test automatici che assicurano che il codice integrato e aggiunto mantenga intatta la consistenza e la stabilità del sistema intero. Ad un certo punto, qualcuno deve occuparsi della revisione e le eventuali modifiche verranno aggiunte e integrate nel codice sorgente il prima possibile.
Quanto vantaggio porta questo approccio? La funzionalità entra a far parte del codice sorgente da subito, anche se non scritta nel modo migliore possibile, e genera valore per l’utente finale, che aumenterà quando verrà fatta la revisione.

Pair Programming

Il pair programming è la pratica in cui due persone lavorano nello stesso momento sulla stessa funzionalità ed è come fare una revisione continua e istantanea del codice.
Di pair programming abbiamo parlato in questo articolo dedicato “Pair Programming, la collaborazione per la qualità del codice”, di cui vi consigliamo la lettura per approfondire la pratica.
Come accennato all’inizio del paragrafo, le due persone coinvolte nella sessione si danno continuamente feedback e il codice viene scritto e revisionato in tempo reale. Il pair programming ha comunque degli aspetti da tenere in considerazione, perché le persone che stanno lavorando alla funzionalità devono essere presenti allo stesso momento a differenza dei casi precedenti in cui la review è asincrona.
Il feedback istantaneo e la condivisione delle idee sono, secondo noi, il modo più efficace per scrivere codice migliore e favorire la crescita delle persone tramite la condivisione delle competenze, conoscenze e la conversazione.

Conclusioni

Qualunque sia il metodo usato per fare code review, è importante che la revisione del codice venga fatta. Le pull requests, se usate bene, sono utilissime e semplici da usare, soprattutto agli inizi. Quando i team, e soprattutto le organizzazioni, hanno raggiunto una certa maturità, crediamo che la loro naturale evoluzione porti al pair programming e alla revisione in tempo reale di quello che si sta implementando.

 

Read more posts from the same category: Pratiche e strumenti per team

Or explore other categories: Organizzazione e strategia Pratiche e strumenti per team Prodotti e progetti agili