Buone linee guida e pratiche per la revisione obbligatoria del codice [chiuso]

Stiamo provando la revisione obbligatoria del codice su ogni commit - nulla arriva al master che non è stato convalidato da almeno 1 persona non l'autore - per un paio di sprint. Abbiamo acquisito sia da sviluppatori che da manager (che è una situazione straordinaria in cui trovarsi) e vogliamo ottenere alcuni dei vantaggi per i quali è noto:

• evidente riduzione dei bug
• maggiore consapevolezza dei cambiamenti in atto nel progetto
• "So che qualcuno lo guarderà in modo da non essere pigro" / effetto anti-cowboy
• maggiore coerenza all'interno / tra i progetti

Ma stiamo introducendo qualcosa che è noto per ridurre la velocità e, se fatto male, potrebbe creare uno stupido passo burocratico nella pipeline di commit che non fa altro che occupare tempo. Cose di cui sono preoccupato:

• recensioni che si stanno trasformando in un semplice prelievo
• (iperbolicamente) persone che aprono enormi problemi di architettura come parte di una revisione del commit a due righe.
• Non voglio distorcere le risposte con altre cose.

Sebbene siamo tutti persone ragionevoli e faremo molta autoanalisi, potremmo sicuramente usare alcune intuizioni vinte in battaglia su quali tipi di cose dovremmo cercare di realizzare in una sessione di revisione per far funzionare davvero le recensioni per noi . Quali sono alcune linee guida e politiche che hai trovato per funzionare?

1. Scrivi recensioni brevi.

   È difficile rimanere concentrati, soprattutto durante la revisione del codice, per molto tempo. Inoltre, le revisioni del codice lunghe possono indicare che c'è troppo da dire sul codice (vedere i prossimi due punti) o che la revisione diventa una discussione su questioni più grandi, come l'architettura.

   Inoltre, una recensione dovrebbe rimanere una recensione, non una discussione. Ciò non significa che l'autore del codice non possa rispondere, ma non dovrebbe trasformarsi in un lungo scambio di opinioni.

2. Evita di rivedere il codice che è troppo male.

   Revisionare un codice di bassa qualità è deprimente sia per il revisore che per l'autore del codice. Se un pezzo di codice è terribile, una revisione del codice non è utile. Invece, dovrebbe essere chiesto all'autore di riscrivere correttamente il codice.

3. Utilizzare controlli automatici prima della revisione.

   Le pedine automatizzate evitano di perdere tempo prezioso indicando errori che possono essere trovati automaticamente. Ad esempio, per il codice C #, eseguire StyleCop, le metriche del codice e soprattutto l'analisi del codice è una buona opportunità per trovare alcuni degli errori prima della revisione. Quindi, la revisione del codice può essere spesa in punti che sono estremamente difficili da fare per una macchina.

4. Scegli attentamente le persone che fanno le recensioni.

   Due persone che non possono sopportarsi a vicenda non faranno una buona recensione del codice di un altro. Lo stesso problema si presenta quando una persona non rispetta l'altra (a prescindere che si tratti del revisore o dell'autore).

   Inoltre, alcune persone non sono in grado di vedere il loro codice rivisto, quindi richiedono una formazione e preparazione specifiche per capire che non sono criticate e non dovrebbero vederlo come qualcosa di negativo. Fare una recensione, non preparata, non aiuta, dal momento che saranno sempre sulla difensiva e non ascolteranno alcun critico del loro codice (prendendo ogni suggerimento come critica).

5. Fai revisioni sia informali che formali.

   Avere una lista di controllo aiuta a concentrarsi su una serie precisa di difetti, evitando di passare al prelievo di nit. Questa lista di controllo può contenere punti come:

   • SQL Injection,
   • Presupposti errati su una lingua che può portare a errori,
   • Situazioni specifiche che possono portare a errori, come la precedenza dell'operatore. Ad esempio, in C #, var a = b ?? 0 + c ?? 0;potrebbe andare bene per qualcuno che vuole aggiungere due numeri nullable con coalescenza a zero, ma non lo è.
   • Deallocation of memory,
   • Caricamento lento (con i suoi due rischi: caricare la stessa cosa più di una volta e non caricarlo affatto),
   • overflow,
   • Strutture di dati (con errori come un semplice elenco anziché un set di hash, ad esempio),
   • Convalida degli input e programmazione difensiva in generale,
   • Sicurezza del filo,
   • eccetera.

   Fermo l'elenco qui, ma ci sono centinaia di punti che possono figurare in un elenco di controllo, a seconda dei punti deboli di un autore preciso.

6. Adeguare progressivamente l'elenco di controllo.

   Al fine di rimanere costruttivi e utili nel tempo, le liste di controllo utilizzate nelle revisioni formali dovrebbero essere adattate nel tempo a seconda degli errori riscontrati. Ad esempio, le prime revisioni informali possono rivelare una certa quantità di rischi di SQL Injection. Il controllo dell'iniezione SQL verrà incluso nell'elenco di controllo. Quando, pochi mesi dopo, sembra che l'autore sia ora molto attento alle query dinamiche rispetto a quelle parametrizzate, SQL Injection può essere rimosso dall'elenco di controllo.

Abbiamo quasi una lista di controllo:

• Mostrami la descrizione dell'attività.
• Fammi vedere il risultato e mostralo mentre funziona. Esegui scenari diversi (input non valido, ecc.).
• Mostrami i test di superamento. Com'è la copertura del test?
• Fammi vedere il codice: ecco dove stiamo cercando ovvie inefficienze.

Funziona abbastanza bene.

Penso che una persona che ha potere sugli altri sarebbe sufficiente, amministratore o moderatore per tagliare commenti irrilevanti, accelerare la revisione di cose che richiedono una rapida revisione. Decisore unico.

Meno di questo sarebbe che questa persona deve farlo come compito principale, mentre potrebbe fare qualcos'altro, e probabilmente ti piacerebbe avere la persona più esperta in questa posizione.

La seconda cosa è automatizzare il più possibile!

• controllo degli spazi bianchi
• software di controllo dello stile
• build automatizzate prima della revisione del codice
• test automatizzati prima della revisione del codice

Queste cose rimuoveranno almeno alcune cose che le persone potrebbero commentare senza bisogno reale. Se non sta costruendo o ha spazi bianchi finali non è abbastanza buono per la revisione, ripararlo e richiedere nuovamente la revisione. Se non sta costruendo o alcuni test falliscono, è ovvio che non è abbastanza buono.

Molto dipende dalle tue tecnologie, ma trova ciò che puoi controllare automaticamente e meglio è.

Non abbiamo ancora vinto questa battaglia, ma è quello che abbiamo trovato utile.