Potenziali problemi con le revisioni del codice [chiuso]

-1

per chiarezza, revisione del codice = una riunione del team e revisione / condivisione del codice

Quali sono gli aspetti potenzialmente negativi del processo di revisione del codice in un ambiente di sviluppo? Mi viene in mente

  • Le forti critiche possono portare a interazioni e sentimenti negativi animosità tra colleghi.
  • La pigrizia per leggere e capire il nuovo codice può portare ad apatico e feedback molto generale.
  • È necessario un notevole investimento in termini di tempo per organizzare e eseguire il processo di revisione.

Ci deve essere più di questo però, quali cose negative avete notato o sperimentato voi ragazzi?

    
posta Eogcloud 01.12.2013 - 18:26
fonte

2 risposte

7

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":

  1. Lavoro su una funzione e scrivo un sacco di codice
  2. 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)
  3. Il revisore riceve una notifica via e-mail
  4. Io cambio ramo (se uso git) o accento le modifiche al codice (se si utilizza perforce) e passa ad altro lavoro
  5. Al termine del revisore, ricevo un'e-mail con il suo feedback.
  6. 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.

    
risposta data 01.12.2013 - 18:51
fonte
0

Strong criticism can lead to negative interactions and feelings of animosity between colleagues.

Molto probabilmente sarà questo. Ad alcune persone non piace sentire che ciò che hanno fatto è sbagliato, o meglio, non del tutto corretto. La squadra nel suo complesso deve essere d'accordo su ciò che è accettabile, ma ci saranno sempre quelli che ancora non sono d'accordo con il resto della squadra e quindi potrebbero crescere a detestare gli altri membri del team. Questa è la natura umana che ho paura.

    
risposta data 01.12.2013 - 18:46
fonte

Leggi altre domande sui tag