Quando uno sviluppatore ha finito di lavorare su un ticket, un altro sviluppatore esamina il codice e prende in considerazione domande come le seguenti:

• Sono presenti errori logici evidenti nel codice?

• Esaminando i requisiti, tutti i casi sono completamente implementati?

• I nuovi test automatizzati sono sufficienti per il nuovo codice? I test automatizzati esistenti devono essere riscritti per tenere conto delle modifiche al codice?

• Il nuovo codice è conforme alle linee guida di stile esistenti?

Le revisioni del codice devono integrarsi con il processo esistente di un team. Ad esempio, se un team utilizza flussi di lavoro per la creazione di branch dei task, avvia una revisione del codice dopo che l'intero codice è stato scritto e sono stati eseguiti e superati i test automatizzati, ma prima che venga eseguito il merge del codice a monte. Ciò garantisce che il tempo impiegato dal revisore del codice venga impiegato per controllare aspetti che le macchine non rilevano e impedisce che l'adozione di decisioni di codifica sbagliate rovinino la linea di sviluppo principale.

Ogni team può trarre vantaggio dalle revisioni del codice indipendentemente dalla metodologia di sviluppo. I team Agile, tuttavia, possono ottenere vantaggi enormi perché il lavoro è decentralizzato all'interno del team. Nessuno è l'unica persona che conosce una parte specifica della base del codice. In poche parole, le revisioni del codice facilitano la condivisione della conoscenza tra la base del codice e il team.

Le revisioni del codice condividono conoscenza

Il filtro di tutti i team Agile è una flessibilità impareggiabile: la capacità di eliminare il lavoro dal backlog e avviare l'esecuzione da parte di tutti i membri del team. Di conseguenza, i team sono maggiormente in grado di occuparsi dei nuovi lavori perché nessuno di essi rappresenta il "percorso critico". Gli ingegneri full stack possono affrontare il lavoro front-end e il lavoro lato server.

Le revisioni del codice consentono di effettuare stime migliori

Ricordi la sezione sulla stima? La stima è un esercizio di team e il team effettua stime migliori con la progressiva diffusione della conoscenza del prodotto in tutto il team. Man mano che vengono aggiunte nuove funzioni al codice esistente, lo sviluppatore originale può fornire un feedback e una stima adeguati. Inoltre, qualsiasi revisore del codice è soggetta anche alla complessità, ai problemi noti e alle preoccupazioni di quell'area della base del codice. Il revisore del codice, quindi, condivide la conoscenza dello sviluppatore originale di quella parte specifica della base del codice. Questa pratica crea molteplici input informati che, se utilizzati per una stima finale, la rendono sempre più forte e affidabile.

Le revisioni del codice consentono di fare una pausa

A nessuno piace essere l'unico punto di contatto di una parte di codice. Allo stesso modo, nessuno vuole entrare a capofitto in una parte di codice critico che non ha scritto, specialmente durante un'emergenza di produzione. Le revisioni del codice condividono la conoscenza all'interno del team in modo che qualsiasi membro del team possa prendere in mano in timone e continuare a guidare la nave (quanto ci piacciono le metafore in Atlassian!) Ma ecco il punto: se non è presente alcuno sviluppatore che rappresenti il "percorso critico", significa anche che i membri del team possono andare in ferie in base alle proprie esigenze. Se ti ritrovi vincolato a una scrivania a lavorare sul sistema di controllo delle versioni, la revisione del codice rappresenta un ottimo modo per avere libertà, ad esempio quella di andare in ferie o di dedicare del tempo a un'area del prodotto diversa.

Le revisioni del codice guidano i nuovi ingegneri

Una particolarità di Agile risiede nel fatto che sono gli ingegneri più esperti ad affiancare i nuovi membri del team e la revisione del codice facilita le conversazioni sulla base del codice. Spesso, i team dispongono di una conoscenza nascosta all'interno del codice che emerge durante la revisione del codice. I nuovi membri, guardando il tutto con occhi nuovi, scoprono aree della base del codice complesse e afflitte da problematiche legate al tempo, e che necessitano di un nuovo punto di vista. Pertanto, la revisione del codice è utile anche per garantire che le nuove informazioni siano mitigate dalla conoscenza esistente.

Certo, richiedono tempo. Ma non è mai tempo sprecato, anzi.

Ecco tre modi per ottimizzarle. 

Condividi il carico

In Atlassian, molti team richiedono che il codice sia sottoposto a due revisioni prima di essere archiviato nella base del codice. Ti sembra un processo che comporta spese elevate? In realtà, non è così. Quando un autore seleziona i revisori, lancia una rete ampia in tutto il team. Anche due ingegneri possono dare il loro contributo. Il processo viene così decentralizzato affinché nessuno sia un collo di bottiglia e garantisce una buona copertura per la revisione del codice a livello di intero team.

Rivedi prima di effettuare il merge

Richiedere la revisione del codice prima del merge a monte garantisce che nessun codice venga utilizzato senza revisione. Ciò significa che le discutibili decisioni sull'architettura prese alle 2 del mattino e l'uso improprio di un modello di fabbrica da parte di uno stagista vengono rilevati prima che possano avere un impatto duraturo (e spiacevole) sulla tua applicazione.

Usa le revisioni dei colleghi a tuo vantaggio

Quando gli sviluppatori sanno che il loro codice verrà esaminato da un collega del team, si impegnano più a fondo per assicurarsi che tutti i test siano stati superati e che il codice sia ben progettato affinché la revisione proceda senza intoppi. Questa consapevolezza tende inoltre a rendere il processo di codifica stesso ancora più fluido e, in definitiva, più veloce.

Non aspettare una revisione del codice se il feedback è necessario nelle prime fasi del ciclo di sviluppo. Il feedback tempestivo e frequente migliora il codice, quindi non esitare a coinvolgere gli altri, ogni volta che ciò accade. Migliorerà il tuo lavoro, ma anche le capacità di revisione del codice dei colleghi del team. E il ciclo virtuoso continua...!