Quali sono alcune buone pratiche per la revisione del codice?

La società SmartBear Software ha pubblicato un piccolo white-paper con 11 buone pratiche per un efficace processo di revisione del codice:

1. Rivedere meno di 200-400 linee di codice (LOC) alla volta: Più di 400 LOC richiederanno più tempo, e demoralizzeranno il revisore che saprà in anticipo che questo compito gli richiederà un'enorme quantità di tempo.
2. Puntate su un tasso di revisione inferiore a 300-500 LOC/ora: È preferibile revisionare meno LOC ma cercare situazioni come bug, possibili falle di sicurezza, possibili fallimenti di ottimizzazione e anche possibili difetti di progettazione o di architettura.
3. Prendere abbastanza tempo per una revisione adeguata e lenta, ma non più di 60-90 minuti: Poiché si tratta di un compito che richiede attenzione ai dettagli, la capacità di concentrazione diminuirà drasticamente quanto più tempo si impiega per completare il compito. Per esperienza personale, dopo 60 minuti di revisione efficace del codice, o ci si prende una pausa (andare a prendere un caffè, alzarsi dalla sedia e fare un po' di stretching, leggere un articolo, ecc.), o si inizia ad essere compiacenti con il codice su questioni delicate come questioni di sicurezza, ottimizzazione e scalabilità.
4. Gli autori dovrebbero annotare il codice sorgente prima che la revisione inizi: È importante che l'autore informi i colleghi su quali file devono essere revisionati, evitando che il codice revisionato in precedenza venga convalidato di nuovo.
5. Stabilire obiettivi quantificabili per la revisione del codice e catturare metriche in modo da poter migliorare i processi: è importante che il team di gestione abbia un modo per quantificare se il processo di revisione del codice è efficace, come ad esempio contabilizzare il numero di bug segnalati dal cliente.
6. Le liste di controllo migliorano sostanzialmente i risultati sia per gli autori che per i revisori: Cosa rivedere? Senza una lista, ogni ingegnere può cercare qualcosa in particolare e lasciare dimenticati altri punti importanti.
7. Verificare che i difetti siano effettivamente risolti! Non basta che un revisore indichi dove sono i difetti o suggerisca miglioramenti. E non si tratta di fidarsi dei colleghi. È importante convalidare che, in effetti, i cambiamenti sono stati ben implementati.
8. I manager devono promuovere una buona cultura di revisione del codice in cui trovare i difetti è visto positivamente. È necessario evitare la cultura del "perché non l'hai scritto bene la prima volta? È importante che in produzione si trovino zero bug. La fase di sviluppo e di revisione è dove devono essere trovati. È importante avere spazio per un ingegnere per fare un errore. Solo allora si può imparare qualcosa di nuovo.
9. Attenzione all'effetto "Grande Fratello": Simile al punto 8, ma dalla prospettiva dell'ingegnere. È importante essere consapevoli che i suggerimenti o i bug riportati nelle code review sono quantificabili. Questi dati dovrebbero servire ai manager per vedere se il processo sta funzionando o se un ingegnere è in particolare difficoltà. Ma non dovrebbero mai essere usati per valutazioni di performance.
10. L'Effetto Ego: Fare almeno qualche revisione del codice, anche se non si ha il tempo di rivederlo tutto: Sapere che il nostro codice sarà revisionato dai pari ci spinge ad essere più cauti in quello che scriviamo.
11. Le revisioni del codice in stile leggero sono efficienti, pratiche ed efficaci nel trovare i bug: Non è necessario entrare nella procedura descritta da IBM 30 anni fa, dove 5-10 persone si chiudevano per incontri periodici con impressioni sul codice e scribacchiavano ogni linea di codice. Utilizzando strumenti come Git, è possibile partecipare al processo di revisione del codice, scrivere e associare commenti a linee specifiche, discutere le soluzioni attraverso messaggi asincroni con l'autore, ecc.

Vi consiglio di leggere il documento per una visione più approfondita di ogni punto.

È impossibile confutare che la revisione del codice migliori la qualità del codice prodotto, riducendo il numero di bug e migliorando il design. Ci sono alcuni vantaggi aggiuntivi come la condivisione delle conoscenze tra pari e il mentoring dei membri più giovani del team.

È un fatto che questo processo, anche se fatto in modo più leggero, porterà via del tempo al progetto. Nel processo di revisione, dobbiamo aggiungere il tempo di risposta dell'autore e di nuovo il tempo di revisione. Nel tentativo di accelerare questo consumo di tempo, consiglio che, dopo due revisioni non riuscite, l'autore e il revisore si siedano fianco a fianco e discutano il pezzo di codice che sta causando il problema.

Ma è davvero importante affermare una frase dal sito IBM - Slow down to go faster.

Vorrei concludere con una nota, che ho come troppo importante. Il processo di revisione del codice richiede all'intero team di sviluppo di dimostrare un'alta intelligenza emotiva. Di regola, i programmatori hanno un forte ego e si sentono "genitori" del codice scritto da loro stessi. A volte non è facile accettare commenti meno costruttivi. I commenti totalmente distruttivi, provocatori o scherzosi "faranno più male che bene", e possono anche distruggere il morale di una squadra. È importante seguire questi elementi, cercare di cambiare i loro atteggiamenti o, come ultima risorsa, eliminarli dal team.