Dovremmo tentare di rivedere tutto il nostro codice?

18

Al momento stiamo modificando il processo di sviluppo e mi chiedo se dovremmo cercare di mantenere un peer review del 100%.

Qual è la tua esperienza in merito alle recensioni di codice?

Tendi a passare "molto" tempo su di loro (diciamo 1/2 ore al giorno), o semplicemente sfogli per un massimo di 5/10 minuti?
Hai un tempo fisso da dedicare al giorno / settimana / sprint / progetto?
Soprattutto, pensi che l'obiettivo dovrebbe essere il peer review del 100% del codice o che il 100% non è necessario?

code-reviews

— Simeone
fonte

Prova a toccare l'80% del codice con il 20% dello sforzo. Investi nei migliori strumenti automatizzati che il denaro può comprare.

— Lavoro

2

Gli strumenti automatizzati sono fantastici, ma diventano inutili a meno che tu non abbia il tempo e le risorse per mantenere tutti i test aggiornati.

— Kieren Johnstone,

19

Abbiamo un compito di "Revisione del codice" in ogni storia. Qualcuno idealmente non coinvolto nello sviluppo di quella storia esaminerà tutte le modifiche al codice associate a quella storia. Funziona bene.

Molto tempo? Non molto, dipende dalla quantità di codice: stiamo cercando errori evidenti, errori di battitura, controllo di integrità della logica di base, eccezioni non rilevate, ecc.

È un passaggio di qualità che trova bug, quindi ha un certo valore. Allocare tempo potrebbe non essere il modo migliore per farlo - che ne dici se qualcosa è abbastanza complesso, dovrebbe essere rivisto dal codice?

A proposito, è importante che qualcun altro esegua la revisione del codice.

— Kieren Johnstone
fonte

3

"A proposito, è importante che qualcun altro esegua la revisione del codice ..", la domanda implica che la stessa persona che scrive il codice dovrebbe esaminarlo? Se fa dove? Vorrei risolvere il problema :)

— Simeon,

4

No, ero comprensivo e dicevo che era importante

— Kieren Johnstone,

5

@Simeon è in realtà un malinteso quasi comune che il proprietario può rivedere il proprio codice. Mina l'intera operazione

— Tom Squires,

5

@ TomSquires: Esatto. Quando lavori con un pezzo di codice da molto tempo, puoi diventare "cieco" a difetti altrimenti evidenti in esso, perché lo vedi come dovrebbe essere invece di quello che è. Questi problemi saranno più facili da individuare per qualcuno che non ha mai visto il codice prima. Gli scrittori hanno lo stesso problema e, proprio come i libri non vengono rilasciati senza correzione di bozze, il codice non deve essere rilasciato senza revisione. Ci sono anche altri vantaggi nel fare revisioni del codice, ad esempio è utile per trasferire le conoscenze tra i membri del tuo team.

— Hammar,

@hammar - ovviamente cercare di trovare qualcuno che non ha scritto il codice che ha il tempo di conoscerlo così intimamente da poterlo rivedere in modo utile, è una sfida

— Peter Ajtai,

12

Un problema più importante del fatto che quanto sopra il tuo codice è coperto dalle recensioni, è quanto siano efficaci le recensioni. Se le tue recensioni rilevano pochi o nessun problema, raggiungere la copertura completa sarà inutile.

In primo luogo lavorare per rendere più efficaci le tue recensioni, quindi decidere 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 eseguire il codice di funzionamento a secco
Le recensioni possono includere 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 la ricerca di colli di bottiglia
Esistono strumenti per l'analisi del codice statico
Esistono strumenti per testare le convenzioni di codifica, non perdere tempo a ripassare
Codice di funzionamento a umido per test di unità, sistema e integrazione
I test di unità, sistema e test di integrazione possono essere ripetuti automaticamente, le revisioni del codice sono di solito una tantum
I test unitari dovrebbero avere un'elevata copertura del codice e testare sia i principali scenari di successo che le condizioni finali, le revisioni del codice possono farlo solo in parte
I test di integrazione testano la capacità di unità o sistemi di lavorare insieme, la revisione del codice non può sostituirla
Test di sistema testano la funzionalità di un intero sistema, la revisione del codice non può sostituirla

Prova a dedicare un periodo di tempo prestabilito al mese (o per sprint) per le recensioni. Seleziona il codice che desideri rivedere nel prossimo slot dedicato usando un'euristica come:

Codice che può contenere un bug non identificato che è stato segnalato
Il codice con quello recentemente ha avuto bug identificati al suo interno
Codice con problemi di prestazioni (collo di bottiglia)
Codice scritto da nuovi sviluppatori
Codice legacy che è stato recentemente aggiornato da qualcuno che non lo conosceva in precedenza
Codice in nuove aree
Codice esistente di cui vuoi conoscere i nuovi sviluppatori
Codice che risolve problemi complessi
Codice identificato come complesso dagli strumenti di analisi

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

Raccomando i seguenti materiali di lettura:

Recensioni senza lavoro selettivo I
migliori segreti della revisione del codice peer

— Danny Varod
fonte

5

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 delle risorse, dall'esperienza dei tuoi sviluppatori e da cosa stai cercando nelle revisioni del codice. (Tieni presente che lo sviluppatore medio che rivede il codice di qualcun altro probabilmente noterà problemi di stile e mancherà i bug algoritmici sottili ... soprattutto dato che la revisione del codice è una sorta di lavoro ingrato.)

Il mio consiglio sarebbe di risparmiare il tuo sforzo di revisione del codice per il codice in cui la correttezza è fondamentale e il costo degli errori non rilevati è elevato.

— Stephen C
fonte

5

Innanzitutto, devi rispondere a questa domanda: perché riesci a leggere il codice?

Con quella 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, avvicinarti al 100% è una buona idea se hai pochi test. Tuttavia, lasciare che gli strumenti di test facciano questo ridurrebbe la necessità di rivedere tutto il codice.

La maggior parte delle recensioni positive sembrano concentrarsi sulla condivisione delle conoscenze e sull'aumento delle capacità degli sviluppatori nella revisione (sia quella che ha scritto il codice sia quella che lo ha rivisto). Con questo come motivo principale per le recensioni, assicurarsi di rivedere il 100% del codice è probabilmente eccessivo.

— John Fisher
fonte

3

In un mondo perfetto, tutto verrebbe esplicitamente letto dall'autore e sottoposto a revisione paritaria da almeno un'altra persona, dalle specifiche dei requisiti ai manuali utente ai casi di test. Ma le recensioni, anche semplici controlli da banco, richiedono tempo e denaro. Questo significa che devi scegliere cosa rivedere e quando dovresti rivederlo.

Consiglio di dare la priorità alle cose da rivedere, scegliere come rivederle e provare a rivedere il più possibile con il livello di dettaglio appropriato. La priorità potrebbe essere basata sul tipo di manufatto, ad esempio affermando che i requisiti devono essere rivisti, il codice di progettazione e produzione deve essere rivisto e i casi di prova possono essere rivisti. Inoltre, puoi anche specificare che i componenti ad alto rischio o ad alto valore ricevono una priorità in revisione o forse una revisione più formale.

Per quanto riguarda il tempo, tutto risale a quanto è alta la priorità del componente. Ci sono state volte in cui ho passato 10-15 minuti a rivedere, e altre volte in cui più persone hanno letto il codice singolarmente, poi sono entrate 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, portata e qualità. Non puoi averli tutti, quindi devi ottimizzare dove puoi.

— Thomas Owens
fonte

3

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

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

— Nessuna possibilità
fonte

2

Mi riservo un'ora al giorno per fare revisioni tra pari, ma non sempre lo richiedo. La nostra base di codice è condivisa tra una dozzina di prodotti. La nostra politica è che una banale modifica del codice univoca per un prodotto sia accettabile per il check-in senza revisione. Modifiche di un prodotto più complesse richiedono una revisione, ma potrebbe essere informale come chiamare un collega alla scrivania per riprovare. Le modifiche al codice condiviso richiedono una revisione più formale, compresi gli sviluppatori su altri prodotti. Penso che la nostra politica raggiunga un discreto equilibrio rispetto ad altre aziende per cui ho lavorato.

Dedico più tempo al giorno alle recensioni di alcuni dei miei colleghi con ruoli meno centrali, ma non lo considero un ammontare irragionevole di tempo, perché prima della politica di revisione potrei facilmente perdere più tempo di quel rintracciare i bug che uno sviluppatore su un altro prodotto introdotto.

— Karl Bielefeldt
fonte

È una media? Limitare una revisione complessa a un'ora sembra strano, e se non c'è molto da rivedere .. beh, non riesco a vedere come un'ora al giorno sarebbe praticabile?

— Kieren Johnstone,

Non è un limite. Ho impostato il tempo in base al tempo impiegato, non viceversa. Di solito riesco a ottenere 2 recensioni in un'ora. Se ci vuole più tempo, i tuoi check in sono troppo grandi, non stai ricevendo abbastanza revisione del progetto in anticipo o i tuoi strumenti di revisione del codice sono troppo ingombranti. Le revisioni del codice sono un controllo, non una riprogettazione.

— Karl Bielefeldt,

2

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

Mentre si azzera nel processo, tenere le note. Cosa hai trovato? Che cosa ha trovato il QA in seguito? Cosa hanno trovato i tuoi clienti? Perché quei bug ti sono sfuggiti?

— MSalters
fonte

7

In che modo la revisione è più economica dei test automatici? Supponendo di scrivere un test una volta, di rivedere un test una volta e di disporre di una suite di test stabile, dovresti impiegare molto meno tempo e denaro per eseguire i test di quanti ne servono per eseguire qualsiasi tipo di revisione (per tutta la durata del progetto). Inoltre, puntare al 100% di copertura del codice è uno spreco di risorse, che potrebbe essere la ragione del maggiore tempo / costo dei test. Metto anche in discussione i 30 minuti nelle recensioni: potremmo rivedere un modulo per 30 minuti, ma c'è il tempo di preparazione per leggere inizialmente il codice, comprenderne il ruolo nel sistema e commentarlo.

— Thomas Owens

Le affermazioni di @MSalters non sono inaudite, anche se anch'io sono scettico con il fatto che ci sono voluti solo 30 minuti .. Ho letto solo di un posto in cui l'ispezione era più economica dei test di unità automatizzati e che era la NASA. In quel caso alla fine hanno abbandonato del tutto il test unitario perché era più economico ispezionare manualmente il codice. Certo, la NASA aveva ancora un tester 12: 1: rapporto degli sviluppatori, quindi stavano facendo anche molti altri test ...

— Michael,

2

@Thomas Owens: i test unitari trovano semplici bug. I costosi bug sono quelli in cui più unità si combinano in modi inaspettati. Un altro tipo di bug è mancati casi d'angolo. Uno sviluppatore che ha perso un caso non scriverà nemmeno un test unitario per esso, ma una seconda serie di occhi lo individuerà.

— MSalters il

@MSalters Ecco perché scrivi i test di integrazione e di sistema automatizzati nonché i test unitari. In realtà, gli unici test che potrebbero dover essere eseguiti manualmente sono i test di accettazione. E rivedendo i test al momento della creazione aiuterebbe a garantire che i casi più critici siano testati.

— Thomas Owens

2

Avere revisioni periodiche del codice principalmente per la creazione di team e la condivisione di idee sull'implementazione. In questo modo puoi imparare molto dai tuoi colleghi.

— programmatore
fonte

Questo indica solo alcuni vantaggi. Pensi che trovare errori sia importante? se cosi, quanto?

— JeffO

Naturalmente la ricerca di errori è importante, ma il vantaggio maggiore è la conoscenza a lungo termine acquisita dalle revisioni del codice. Forse un bug è stato creato da un cattivo approccio che può essere evitata in futuro

— coder

2

Abbiamo bisogno di una revisione del codice peer per ogni check-in. Se non è disponibile alcun peer, organizziamo una revisione post check-in. Il revisore è indicato nel commento del check-in del controllo del codice sorgente.

Questi non richiedono molto tempo e poiché sono fatti tra pari non c'è alcun aspetto tossico tra adulto e bambino.

— Jim In Texas
fonte

2

È necessaria la revisione del codice, IMO. Hai il 99,999 ...% del tempo non sempre sarà giusto, quindi devi assicurarti che sia corretto. Ho un orario prestabilito? No. Ma mi prendo il tempo per controllare il mio codice. Di solito un collega fa lo stesso.

— Dinamico
fonte

1

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

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

Abbiamo un white paper sulla conduzione di 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 risolverle. Puoi scaricarlo dal nostro sito Web.

— Katie B.
fonte