Qual è l'accordo con le revisioni del codice? [chiuso]

1. Assolutamente. Ci sono molti bug che puoi prendere in anticipo tramite la revisione del codice. E ci sono alcuni tipi di bug che difficilmente riescono a prendere in considerazione altro che la revisione del codice (ad esempio alcuni bug di concorrenza). Ma ciò che è ancora più importante: le recensioni di codice (di gruppo) sono un ottimo modo per diffondere e condividere una visione coerente e coerente di design, architettura, idiomi di codifica e best practice in tutto il team di sviluppo. L'unico modo migliore che posso immaginare è la programmazione della coppia, che di fatto è una forma estrema di revisione del codice.
   L'obiettivo principale delle revisioni (classiche, formali) del codice è in realtà non catturare bug già presenti nel codice, ma prevenire (futuri) bug dall'entrare nel codice, tramite la comunicazione / mentoring / discussione sopra menzionata tra i membri del team, generata durante le riunioni di revisione.
   Questo è probabilmente uno dei motivi per cui le recensioni di codice sono ancora rare. Mostrano il loro reale vantaggio solo a lungo termine, quindi ci vuole perseveranza per arrivarci, e la maggior parte dei manager (e degli sviluppatori allo stesso modo) non l'hanno mai sperimentato.

2. Nel nostro progetto attuale, lo abbiamo fatto solo occasionalmente fino ad ora, ma è destinato a cambiare. Il nuovo obiettivo è quello di far esaminare ogni modifica del codice da qualcun altro prima che entri in produzione. In un progetto precedente, lo abbiamo fatto ed è stato utile. In un progetto precedente, abbiamo fatto revisioni di codice di gruppo formali, ed era ancora utile, ma abbastanza lento e dispendioso in termini di tempo. Non avremmo potuto rivedere tutti i cambiamenti di codice in quel modo senza rallentare enormemente il nostro ritmo di sviluppo. Ma per alcuni tipi di progetti, anche quello paga. Se sono in gioco vite umane, la tua motivazione principale non è il risparmio di valori oscuri.

3. Fino ad ora non era più di un'ora alla settimana in media. Secondo il nostro nuovo processo, questo sicuramente aumenterà. Nei precedenti progetti menzionati, IIRC era in media 2-4 ore settimanali.

Pensiamo al caso migliore: il codice è perfetto (che non accadrà mai)

Le recensioni del codice sarebbero inutili? No , tutti coloro che sono coinvolti nella revisione apprenderebbero qualcosa e la revisione faciliterebbe la conversazione e lo scambio di idee.

Qualunque cosa in meno del migliore dei casi è stata affrontata da altre risposte.

Per quanto tempo dovrebbe essere speso rivedere e come dovrebbe essere strutturata la revisione ... questo dipende strongmente da molti fattori dipartimentali / organizzativi e non si può rispondere senza questo contesto.

Non menzioni se i tuoi programmatori hanno ottenuto il codice giusto al primo tentativo, o se hanno commesso codice in cui il QA ha trovato bug che richiedevano il fissaggio. Se il QA sta trovando bug, forse fare revisioni del codice ridurrebbe il numero di bug che troverà. Se il QA sta trovando meno dei bug più ovvi, hanno più tempo per trovare i bug meno ovvi. E più tempo passano a trovare i bug meno ovvi, meno è probabile che i tuoi clienti trovino gli stessi bug.

1. Sì. Si può imparare molto dalla revisione del codice, anche se è corretto e semplicemente scritto male.
2. Ogni volta che il tempo lo consente, di solito ogni giorno. Almeno qualche volta alla settimana è sufficiente.
3. Solitamente da 30 minuti a un'ora, a seconda della natura della recensione.

Ricorda, solo perché ogni azienda non esegue revisioni di codice non significa che sia una perdita di tempo per farlo. Forse non tutti si rendono semplicemente conto dei benefici o addirittura sanno di includerli come parte del loro processo di sviluppo.

1 - Considero le recensioni utili, anche se si tratta di un processo informale. Il test delle unità che passa non significa che tu abbia catturato tutti i casi, ei test unitari tentano di testare il codice da solo, quindi potresti aver scritto del codice che ignorava qualcosa che potrebbe causare problemi quando il tuo codice è integrato con altri componenti. Inoltre, potrebbe aiutarti a migliorare le tue capacità e il tuo stile se le persone possono suggerire modi migliori per scrivere ciò che hai scritto.

2 - Li faccio se sono il revisore per le correzioni di altre persone, anche se nella mia ultima società, abbiamo utilizzato Review Board e mi sarebbe stato chiesto di frequente di guardare il codice della gente. A volte guardo anche le principali modifiche al codice per vedere se i cambiamenti sono sani.

3 - Forse il 5% del tempo totale.

Cerco sempre di convincere qualcuno a guardare il mio codice. Per quanto competente possa essere, è bello avere altre persone di cui ti fidi a guardare il tuo codice e vedere se possono offrire suggerimenti o dare il pollice in su.

Ed ecco il link alla Review Board , che può collegarsi con i sistemi di controllo del codice sorgente come svn e git.

In alcuni negozi la programmazione delle coppie ha preso il posto delle revisioni del codice. Suppongo che tu possa pensare alla programmazione della coppia come a un processo di revisione continua del codice.

Nelle scienze umane c'è un famoso detto che "Anche Omero annuisce". Significa che anche se sei il più grande programmatore del mondo, a volte sarai distratto, fuori dal gioco o semplicemente rovinato. Un secondo set di occhi è incredibilmente utile per catturare cose come questa. I bug precedenti o le "mis-feature" vengono catturati, meno costosi sono da sistemare. A volte questi errori superano i test esistenti, ma si presentano come trappole esplosive per quando il codice deve essere esteso.

Ha anche l'effetto collaterale di tenere tutti i membri del team almeno un po 'consapevoli di come funzionano gli altri bit. Questo aiuta a evitare i disastri in cui l'unica persona che sapeva come funzionava il codice degli account ricevibili viene investita da un autobus o lascia la squadra.

Considero le recensioni di codice molto utili e utili. Anche se per miracolo il codice è privo di bug, si aprono opportunità di intuizione preziosa. Mi piace vedere come fare le cose in modo diverso e / o talvolta meglio. Quando faccio recensioni posso anche raccogliere qualcosa di nuovo o meglio mentre guardo il codice scritto da qualcun altro.

Quante volte sono fatti dipende da ciò che stiamo cambiando. Se si tratta di una correzione, è probabile che passerà direttamente al QA dopo che lo sviluppatore ha inoltrato una richiesta di fusione. Se è qualcosa di più grande e il tempo lo consente, il codice verrà esaminato.

La quantità di tempo speso per la revisione dipende dal codice e dallo sviluppatore. Alcuni sviluppatori sono più abili di altri e alcune modifiche al codice sono più grandi di altre, quindi varia. Non passa mai più di un'ora per me ... più l'incontro avrò su di esso (~ 30 minuti).