Dovremmo provare a rivedere tutto il nostro codice?

Abbiamo un compito di 'Code Review' in ogni storia. Qualcuno, idealmente non coinvolto nello sviluppo di quella storia, esaminerà tutte le modifiche al codice associate a quella storia. Funziona bene.

Un sacco di tempo? Non molto, dipende da quanto codice: cerchiamo errori evidenti, errori di battitura, controllo della sanità logica di base, eccezioni non rilevate, ecc.

È un passo di qualità che trova bug, quindi ha un certo valore. Il tempo di allocazione potrebbe non essere il modo migliore per farlo: se qualcosa fosse abbastanza complesso, dovrebbe essere sottoposto a revisione del codice?

A proposito, è importante che qualcun altro riveda il codice ..

Un problema più importante di quanto il tuo codice sia coperto dalle recensioni, quanto efficaci sono le recensioni. Se le tue recensioni riscontrano pochi o nessun problema, raggiungere la copertura completa sarà inutile.

Per prima cosa rendi più efficaci le tue recensioni, poi decidi sulla copertura.

Le recensioni dovrebbero essere eseguite non solo sul codice, ma anche sul design.

Inoltre, le recensioni non sostituiscono test e strumenti:

• Le recensioni possono far funzionare il codice
• Le recensioni possono includere l'analisi del codice
• Le recensioni esaminano il riutilizzo e la leggibilità
• Le recensioni possono esaminare alcuni aspetti dell'efficienza, tuttavia, ciò non sostituisce la misurazione effettiva del tempo di esecuzione e il rilevamento dei colli di bottiglia
• Esistono strumenti per l'analisi del codice statico
• Esistono strumenti per testare le convenzioni di codifica, non perdere tempo per la revisione su questo
• Unità, sistema e test di integrazione codice di funzionamento a umido
• Test dei test di unità, sistema e integrazione possono essere ripetuti automaticamente, le revisioni del codice sono di solito una tantum
• I test unitari devono avere una copertura di codice elevata e testare sia i principali scenari di successo che le condizioni finali, le revisioni del codice possono eseguire solo parzialmente questo
• I test di integrazione testano la capacità delle unità o dei sistemi di lavorare insieme, la revisione del codice non può sostituire questo
• Test di sistema testano la funzionalità di un intero sistema, la revisione del codice non può sostituire questo

Prova a dedicare una quantità predefinita di tempo al mese (o per sprint) per le recensioni. Seleziona il codice che desideri esaminare nel prossimo spazio dedicato utilizzando un euristico come:

• Codice che potrebbe contenere un errore non identificato segnalato
• Il codice con cui di recente sono stati identificati bug al suo interno
• Codice con problemi di rendimento (colli di bottiglia)
• Codice scritto dai nuovi sviluppatori
• Codice legacy che è stato recentemente aggiornato da qualcuno che non aveva familiarità con esso
• Codice in nuove aree
• Codice esistente che vuoi far conoscere ai nuovi sviluppatori
• Codice che risolve problemi complessi
• Codice identificato come complesso dagli strumenti di analisi

E ricorda, stai esaminando il codice (o il design o i test) e non gli autori.

Raccomando i seguenti materiali di lettura:

Recensioni selettive per i compiti a casa
I migliori segreti di Peer Code Review

Per prima cosa, devi rispondere a questa domanda: Perché recensisci il codice?

Con questa risposta in mano, puoi capire quale codice deve essere rivisto.

Alcune revisioni del codice realizzano esattamente ciò che il test fa o avrebbe fatto. Se questo è l'obiettivo delle tue recensioni, avvicinarsi al 100% è una buona idea se hai pochi test. Tuttavia, fare in modo che gli strumenti di test lo faccia ridurrebbe la necessità di rivedere tutto il codice.

La maggior parte delle recensioni positive sembra essere incentrata sulla condivisione delle conoscenze e sull'aumento delle capacità degli sviluppatori nella revisione (sia chi ha scritto il codice che quelli che hanno revisionato il codice). Con questo come motivo principale per le recensioni, assicurarti di rivedere il 100% del codice è probabilmente eccessivo.

Dipende.

Dipende da cosa sta facendo il tuo software:

• Se controlla un pacemaker elettronico o uno space shuttle, allora sicuramente sì.

• Se si tratta di un prototipo usa e getta, probabilmente no.

Dipende anche da quanto sei dotato di risorse, dall'esperienza dei tuoi sviluppatori e da ciò che stai cercando nelle revisioni del codice. (Ricorda che lo sviluppatore medio che sta esaminando il codice di qualcun altro probabilmente noterà problemi di stile e mancherà dei piccoli bug algoritmici ... specialmente considerando che la revisione del codice è un po 'complicata.)

Il mio consiglio è di salvare lo sforzo di revisione del codice per il codice laddove la correttezza è critica e il costo degli errori non rilevati è elevato.

In un mondo perfetto, tutto sarebbe letto esplicitamente dall'autore e sottoposto a revisione da almeno un'altra persona, dalle specifiche dei requisiti ai manuali degli utenti fino ai casi di test. Ma le recensioni, anche semplici assegni da scrivania, richiedono tempo e denaro. Ciò significa che devi scegliere ciò che dovresti rivedere e quando dovresti rivederlo.

Raccomando di dare priorità alle cose da esaminare, scegliendo come rivederle e cercando di esaminare il più possibile con il livello di dettaglio appropriato. La priorità potrebbe basarsi sul tipo di artefatto, ad esempio affermando che i requisiti devono essere rivisti, che il codice di progettazione e produzione dovrebbe essere rivisto e che i casi di test possono essere rivisti. Al suo interno, puoi anche specificare che le componenti ad alto rischio o ad alto valore ricevono una priorità nella revisione o forse una revisione più formale.

Per quanto riguarda il tempo, tutto torna alla massima priorità del componente. Ci sono stati momenti in cui ho trascorso 10-15 minuti di revisione e altre volte in cui più persone hanno letto il codice individualmente, quindi sono andati in una stanza per fare un processo di ispezione più formale che dura 30-45 minuti (a seconda delle dimensioni di il modulo).

Alla fine, è un equilibrio tra tempo, costi, ambito e qualità. Non puoi averli tutti, quindi devi ottimizzare dove puoi.

Come suggerimento, se hai intenzione di fare qualsiasi recensione, hai alcune linee guida condivise sull'obiettivo di revisione e l'obiettivo per assicurarti che le recensioni non causino frizioni inutili tra i membri del team.

I team coerenti costruiscono progetti migliori. Le persone potrebbero perdere le relazioni oltre le assurdità o le richieste di perfezionamento. C'è sempre quella persona che si lamenterebbe di questo o quello e cagionerà gli altri solo perché è così ...

Mi riservo un'ora al giorno per fare recensioni tra pari, ma non sempre lo richiedono. La nostra base di codici è condivisa tra una dozzina di prodotti. La nostra politica prevede che un semplice cambiamento nel codice unico per un prodotto sia corretto per il check in senza revisione. Le modifiche di un prodotto più complesse richiedono una revisione, ma potrebbe essere altrettanto informale come chiamare un collega alla tua scrivania per dargli una possibilità. Le modifiche al codice condiviso richiedono una revisione più formale, compresi gli sviluppatori su altri prodotti. Penso che la nostra politica abbia un buon equilibrio rispetto alle altre società per cui ho lavorato.

Trascorro più tempo al giorno sulle recensioni di alcuni dei miei colleghi con ruoli meno centrali, ma non lo considero una quantità irragionevole di tempo, perché prima della politica di revisione avrei potuto sprecare più tempo di quel bug di individuazione che uno sviluppatore di un altro prodotto ha introdotto.

Abbiamo fatto recensioni al 100% per il codice. È molto più economico dei test, in particolare del 100% dei test di copertura del codice. Non spendiamo troppo tempo su di loro, la revisione per più di un'ora al giorno diventa meno produttiva. (30 minuti è non molto).

Durante l'azzeramento del processo, tieni le note. Cosa hai trovato? Che cosa ha trovato il QA in seguito? Cosa hanno trovato i tuoi clienti? Perché quegli insetti ti hanno sfuggito?

Esegui regolarmente revisioni di codice per lo sviluppo di team e la condivisione di idee sull'implementazione. Puoi imparare molto dai tuoi colleghi in questo modo.

Richiediamo una revisione del codice peer per ogni check-in. Se non è disponibile nessun peer organizziamo una revisione post-it. Il revisore è annotato nel commento del check-in del controllo del codice sorgente.

Non ci vuole molto tempo, e dal momento che sono fatti tra pari non c'è nessun aspetto tossico adulto-figlio per loro.

La revisione del codice è, IMO, necessaria. Sei 99.999 ...% del tempo non sempre andrà bene, quindi è necessario assicurarsi che sia corretto. Ho un tempo stabilito? No. Ma mi prendo il tempo di controllare il mio codice. Di solito ho un collega che fa lo stesso.

Le revisioni del codice possono sembrare scoraggianti, ma sono uno strumento prezioso se condotte correttamente. Saranno la vostra prima linea di difesa contro errori di progettazione e implementazione. Se non stai conducendo revisioni del codice su ogni funzione che hai messo in atto, dovresti iniziare al più presto.

Per quanto tempo dedicare alle recensioni tra pari, una buona pratica è lasciare il 5-10% del tempo totale di sviluppo stimato per condurre e rispondere alla revisione del codice.

Abbiamo un white paper su come condurre revisioni efficaci del codice che possono aiutarti a iniziare con il piede giusto. È una guida passo passo e discute le insidie più comuni che potresti incontrare e come risolverli. Puoi scaricarlo dal nostro sito web.