Quanto deve fidarsi di un revisore del coder che invia il codice per la revisione?
Ho sempre il dilemma se dovrei andare a testare le modifiche proposte o dovrei fidarmi del mittente che sarebbe sapendo cosa sta facendo? Soprattutto perché alla fine della giornata anche la responsabilità dei revisori.
Le recensioni del codice non sono sempre divertenti.
No, non devi fidarti di loro. Ti è stato chiesto di rivedere il codice, non è come testarlo:
Se non ti fidi della persona per testare il loro codice, con cosa puoi fidarti? Se non puoi fidarti di loro per farlo, credi onestamente di poterti fidare di loro per fare dei follow-up di revisione post-codice?
Certo, si può dire che solo perché lo hanno testato, non significa che lo abbiano testato bene. Ma questo porta a una domanda diversa: ti fidi di loro per testare bene il loro codice?
Se hai dubbi su quanto è stato testato, pensa a tutti i percorsi di errore che riesci a pensare e a tutti i casi d'angolo e tieni d'occhio chi è nella revisione del codice o durante l'ispezione di revisione pre-codice (prendere appunti). Se hai dubbi sui casi che hai escogitato, chiedi di loro. Se non è possibile rispondere alla soddisfazione durante la sessione, lo sviluppatore deve seguirli; assicurati di essere copiato sui risultati delle indagini.
La revisione del codice dovrebbe essere condotta in base a una serie di criteri misurabili. Non credo che la fiducia vi entri. Il codice sorgente e la documentazione di accompagnamento dovrebbero essere aperti. Le domande al programmatore dovrebbero essere sincere.
Se l'atteggiamento del codice di revisione e il partecipante non è aperto, franco e senza ego, allora non è una vera revisione del codice.
Dipende interamente dalle procedure della tua organizzazione e dalle misure di controllo del processo che hai in atto. Se, ad esempio, impieghi il test unitario, puoi controllare la copertura totale del codice come misura di quanto "fidarti" del codice.
Veramente, ci sono troppi fattori da valutare, molti dei quali sono altamente soggettivi, perché ci sia una regola dura e veloce per questo. Prendo sicuramente in considerazione chi sta controllando il codice - Sono molto meno pignolo con il codice controllato da un veterano di quanto lo sia io con un ragazzo appena laureato.
Dipende dalla dimensione delle modifiche al codice:
Extreme 1: Piccoli cambiamenti - Se viene corretto un bug cambiando alcune righe di codice, in genere vorrei mostrare un prima e dopo l'esecuzione del codice come parte standard della recensione. Questo potrebbe essere preso come paranoia dalla mia parte, ma ha senso farlo normalmente.
Extreme 2: Grandi cambiamenti - Se ci sono dozzine di nuove classi aggiunte, allora potrebbero essere alcune ore solo per andare oltre il design in modo che dimostrare tutte le funzionalità non sia una cosa realistica da fare. In questo caso c'è una certa fiducia nell'ottenere i dettagli più fini, così come alcuni credono che i dettagli di livello superiore possano essere comunicati in un modo un po 'conciso in quanto non voglio dover leggere ogni riga che è stata aggiunta.
In mezzo è dove viene effettuato il 99% delle modifiche al codice e c'è un po 'di giudizio su dove si trova la linea. Generalmente mi piace vedere alcuni casi di lavoro con alcuni casi limite se è realistico fare un test di base per la nuova funzionalità.
Le modifiche ai test dovrebbero essere parte della stessa revisione delle modifiche al sistema sottoposto a test. Se non possono essere, per motivi organizzativi (ad esempio, si sta utilizzando uno strumento che funziona su un solo repository alla volta e i test non si trovano nello stesso repository del codice funzionale), è necessario collegare le due recensioni in qualche modo. Potrebbe essere semplice come un'email o una conversazione che dice quali recensioni appartengono insieme.
Nel caso in cui alcuni dei tuoi test non siano automatizzati, la revisione dovrebbe includere almeno una dichiarazione dei test condotti.
In tutti i casi, una parte importante della revisione è identificare le lacune nel test, e cerco sempre i casi limite che sono stati persi e potrebbero causare problemi al codice.
Durante la revisione, normalmente non ripeto i test, ma prenderemo in considerazione la possibilità di farlo se l'autore ha chiesto (ad esempio se stiamo compilando per piattaforme diverse, o per confermare che il diff è completo - anche se di solito, il server di compilazione ce lo dirà). Non è un buon uso del mio tempo duplicare le azioni di qualcun altro senza una buona ragione .
Leggi altre domande sui tag code-reviews trust