Questa potrebbe essere principalmente la mia opinione, ma sto basando questa opinione su ciò che i miei team hanno provato in passato e su ciò che abbiamo osservato.
La nostra direzione ha cercato di istituire / applicare le revisioni del codice basate su team e le ho sempre odiate. In effetti ho odiato il 90% di ciò che la direzione ha cercato di istituire / far rispettare perché sembra che la maggior parte di queste cose non abbia fatto altro che perdere tempo.
Il problema con le revisioni del codice basate sul team è che hai un sacco di persone in una stanza. Tutte queste persone dovrebbero aver guardato il codice in anticipo (molto costoso per tutti i membri del team di interrompere il proprio lavoro e guardare i propri) ma non lo fanno mai (perché ognuno ha il proprio lavoro). Quindi la riunione inizia e il presentatore inizia a parlare alle persone e indica il codice che non hanno mai visto. Questo incontro durerà solo 1-2 ore, quindi alla fine solo il 10-20% del codice verrà "guardato". E poiché nessuno ha avuto il tempo di pensare e capire veramente quello che sta guardando, l'unica cosa su cui possono commentare è lo stile o la scelta pignola di piccoli dettagli che sono per lo più irrilevanti ... l'intera cosa è stata una completa perdita di tempo .
Allo stesso tempo, amo le recensioni del codice e mi assicuro che ogni singola riga del mio codice venga esaminata. Ciò che ha funzionato per noi nella mia precedente azienda quando il management ha smesso di cercare di spingere il loro "processo" e ha lavorato continua a lavorare per noi nella mia attuale azienda è la revisione del codice "asincrono":
- Lavoro su una funzione e scrivo un sacco di codice
- Quando il codice è pronto, lo invio per la revisione del codice. Scelgo un revisore, ma generalmente vado in squadra e chiedo a chi piacerebbe fare gli onori (una persona la maggior parte del tempo)
- Il revisore riceve una notifica via e-mail
- Io cambio ramo (se uso git) o accento le modifiche al codice (se si utilizza perforce) e passa ad altro lavoro
- Al termine del revisore, ricevo un'e-mail con il suo feedback.
- Io cambio succursali (o scaffali) e modifico il mio codice in base al suo feedback e lo spingo / eseguo il commit.
Ogni cambio di codice ha un'importanza diversa. Se è banale / facile / semplice, non ne parliamo nemmeno faccia a faccia. Tutto è fatto con strumenti / e-mail. Se è più importante, dopo che il recensore ha avuto una possibilità in pace e nel proprio tempo libero di sedersi e capire cosa ho scritto, teniamo una riunione e passiamo il suo feedback. Se è ancora più importante, abbiamo più persone in quella riunione. Ma la chiave è che abbiamo sempre un unico "revisore primario". In questo modo nessuno partecipa alla riunione pensando che altre persone abbiano guardato il codice. Se sei il primario, allora sai di doverlo guardare.
Un altro aspetto positivo di questo modello è che la maggior parte delle volte l'interazione è uno contro uno tra recensore e recensore, quindi non sembra un interrogatorio in cui ti trovi di fronte al gruppo e tutti ti criticano. Inoltre manteniamo le nostre recensioni estremamente informali. Non c'è gerarchia. Ogni sviluppatore può chiedere a qualsiasi altro sviluppatore di inviare una recensione e alla fine i nostri obiettivi sono:
- Ottieni una seconda serie di occhi sul codice perché c'è sempre qualcosa di stupido che verrà perso
- Chiedi a qualcun altro di conoscere il codice e il tuo stile
- Il revisore può imparare da te se hai fatto qualcosa che non hai mai visto prima
- Puoi imparare dal revisore se hanno fatto qualcosa che non hai mai visto prima e hanno notato che stai risolvendo lo stesso problema nel modo più duro
Ho trovato che questo metodo funziona per noi e spreca un tempo minimo in quanto l'intero team non viene messo in attesa e ottieni feedback / interazione preziosi perché il revisore è effettivamente impegnato e ha la possibilità di sedersi e prendere molto tempo, se necessario, senza pressioni temporali e secondo il proprio programma.