Recensioni di codice, quali sono i vantaggi? [chiuso]

Nel mio team, non facciamo revisioni formali del codice. Tendiamo a pensare che sia abbastanza con la programmazione delle coppie e le coppie rotanti spesso.

Dovremmo considerare di fare revisioni formali del codice? Quali sarebbero i vantaggi?

Facciamo revisioni del codice un po 'diverse (forse).

Troviamo tutti i programmatori insieme (ogni venerdì) e guardiamo cosa abbiamo fatto in un periodo di settimane. Quindi abbiamo scelto quali progetti vogliamo rivedere in modo che ogni progetto fatto / in corso abbia almeno una o poche persone. Poi, tra circa un'ora, esaminiamo le modifiche apportate, cerchiamo errori, come funzionano altri progetti e così via. Successivamente discutiamo, raccontiamo gli errori, come dovrebbe essere fatto (non correggiamo i bug, li segnaliamo semplicemente e spam il codice con FIXME). Tutto sommato di solito per noi (10 programmatori) dura circa 2 ore.

I pro:

• Ogni membro sa cosa succede in azienda
• I bug si trovano più velocemente
• Ci costringe a scrivere codice leggibile (codice che può essere letto senza spiegazione o introduzione!)
• Metodi di ottimizzazione / trucchi / programmi produttivi si diffondono più rapidamente
• Il programmatore come specialista "evolve" più velocemente
• È divertente

Quello che ho contro la programmazione di coppia come detto (certo è solo la mia opinione personale) è che più a lungo il team lavora insieme, più veloce diventa.

Spero che porti qualche spunto di riflessione. In bocca al lupo.

Potresti voler leggere questo libro gratuito:

http://smartbear.com/best-kept-secrets-of-peer-code-review/

Certo, hanno un prodotto da spingere, ma ci sono ancora molte informazioni utili lì dentro.

Discutono anche in che modo la programmazione di coppia offre alcuni degli stessi vantaggi, quindi se si sta programmando una coppia potrebbe non essere necessario rivedere il codice.

Non ho molta esperienza di revisione nel tuo ambiente. Non facciamo molta programmazione di coppie qui facciamo recensioni di codice per diffondere la conoscenza del software nel team, abbiamo un altro paio di occhi per individuare gli errori e avere un punto formale per verificare se il software si attiene alle nostre linee guida di codifica .

I primi 2 punti sono abbastanza buoni coperti dalla programmazione della coppia, il terzo dipende molto dalla coppia e potrebbe migliorare da una revisione formale del codice.

Dovresti fare una revisione formale del codice?

Assolutamente

Proprio come una nota a margine rapido, ho molto poca esperienza con la programmazione in coppia, ma non credo che le recensioni sarebbero in conflitto con questi metodi.

Vorrei introdurre due forme di recensioni di codice:

Revisioni del codice peer

Anche se la programmazione abbinata funziona per te, non fa mai male avere un altro set di occhi sul codice. I vantaggi di questo sono:

1. Ottiene una serie di nuovi occhi sul codice, qualcuno che potrebbe avere una conoscenza più intima delle aree della base di codice che tu (e / o il tuo partner) potrebbe non avere familiarità. Ciò può esporre problemi a catena.
2. Ti rende (la coppia) riconvalidare la tua soluzione prima dell'invio. Poiché il revisore non sa nulla di ciò che hai scritto, devi spiegarlo nella sua interezza. Questo può esporre casi limite a cui non avevi pensato o logica non valida.

Le revisioni del codice peer (nel mio mondo) vengono condotte prima di ogni invio. Come questo si ripercuota nel mondo della programmazione in coppia, non ne sono sicuro.

Revisioni del codice di gruppo

Questi si verificano meno frequentemente delle revisioni del codice peer. Generalmente trascinerei il mio gruppo (o una sottosezione del mio gruppo) in una sala riunioni per una revisione informale del codice. Generalmente sceglierei un codice che è stato scritto da una persona a caso nel team, preferibilmente un codice che è stato scritto da zero - il codice refactored non espone problemi come il codice fresco.

Assicurati che tutti sappiano che queste recensioni non sono pensate per mettere in imbarazzo e non vengono utilizzate per riflettere le prestazioni. Devono semplicemente garantire il rispetto degli standard di codifica del team e aiutare tutti a essere ingegneri migliori e quindi a diventare più utili per il team (e ulteriore crescita della carriera, ecc. Ecc.) E assicurarsi che questo sia il vero intento delle recensioni . Se qualcuno sospetta qualcosa di diverso, questi diventeranno temuti e meno produttivi.

Esaminerei il codice in modo un po 'informale, lasciando che qualcuno nella stanza indicasse diverse soluzioni che potrebbero avere o difetti logici che incontrano. Questo dovrebbe essere più una discussione di gruppo che un leader seduto lì che dice a tutti come dovrebbero codificare.

Ho scoperto che l'utilizzo di questi due metodi aumenta la velocità con cui gli ingegneri progrediscono e riduce notevolmente il numero di bug :)

Non ho mai fatto la programmazione di coppia in pratica (speravo solo), quindi non posso confrontare direttamente le due pratiche. Tuttavia, posso raccontare le mie esperienze con le revisioni formali del codice.

In passato ho condotto revisioni formali del codice in un progetto precedente, sul codice legacy. Il progetto era in un caos completo e la direzione ha accolto con favore qualsiasi iniziativa con la speranza di portare l'ordine nel caos. A quel tempo pensavo che la revisione formale del codice fosse una buona idea. Abbiamo trovato dei bug e abbiamo visto che la qualità del codice appena scritto era significativamente migliore di quella del vecchio codice. Ho raccolto statistiche, conteggi di bug, ecc. Per dimostrarlo.

Abbiamo fatto una sessione alla settimana in media, coinvolgendo 3-5 persone. Ogni sessione ha richiesto circa 3-4 ore di tempo a persona (compresa la preparazione) e ha esaminato 200-300 righe di codice (LOC) *. Con questo ritmo, per un periodo di oltre 6 mesi, siamo riusciti a rivedere circa 5K LOC, su circa 50K.

A posteriori, ritengo che sia stato molto costoso. Con questo ritmo, ci sarebbero voluti 5 anni per rivedere l'intera base di codice legacy. OTOH con più di una sessione a settimana avrebbe portato via le risorse dallo sviluppo. Naturalmente, questo è il tipico dilemma con il codice legacy. Ma anche la revisione formale di tutto il codice appena scritto richiederebbe molto tempo, rallentando notevolmente lo sviluppo.

La mia conclusione è che le revisioni formali del codice vengono eseguite meglio su codice appena scritto, incentrato sulle parti più critiche del codice. Il resto viene gestito meglio in un modo più informale, possibilmente tramite la programmazione di coppia. Questa è solo la mia opinione attuale, che può cambiare. Non pretendo di essere un guru della revisione del codice o altro.

* Questo è il ritmo normale delle revisioni formali del codice.

I tassi tipici di revisione del codice sono di circa 150 righe di codice all'ora. L'ispezione e la revisione di più di qualche centinaio di righe di codice all'ora per software critico (come il software incorporato critico per la sicurezza) potrebbe essere troppo veloce per trovare errori.

Citato da Wikipedia (enfasi da me).

Il motivo alla base delle revisioni del codice esiste perché i programmatori isolati devono incontrarsi e discutere il loro codice e verificare che sia conforme al loro standard.

Non menzionate alcun problema di qualità, quindi sembra che il vostro team stia già facendo abbastanza revisioni del codice attraverso la programmazione della coppia. Eccezionale!

La corretta programmazione delle coppie rende superflue le revisioni formali del codice. Ma provalo per alcune settimane e vedi come funziona, ma sospetto che non noterai alcun miglioramento.

Tieni presente che le revisioni del codice sono un processo faticoso e costoso e non qualcosa da prendere alla leggera. In sostanza introduce un passaggio di consegne nel tuo progetto che è costoso e rallenta tutto . È molto meglio assicurarsi che il codice sia corretto in primo luogo, piuttosto che cercare di trovare problemi in seguito.

Può essere. Le revisioni del codice richiedono tempo. Valgono solo se il tempo impiegato dalla revisione viene salvato in un altro punto del processo. Quali risparmi ti aspetti dalle revisioni del codice? Stai riscontrando difficoltà che potrebbero essere evitate dalle revisioni del codice?

Se si sta eseguendo la programmazione di coppia, la necessità di una revisione del codice diminuisce sostanzialmente, ma si trarrebbe sicuramente beneficio da una revisione tra pari. Affinché ciò sia benefico, deve essere fatto da una persona più anziana ed esperta rispetto ai membri della coppia.

Quali sono i vantaggi? Bene, sarebbe meglio se si considerano i rischi di non farlo.

• La coppia potrebbe fare qualcosa di sbagliato o forse farlo in un modo non ottimale
• Forse non stai seguendo gli standard di codifica o non stai documentando correttamente il codice. Una recensione tra pari è davvero brava a trovarli
• Nessuno oltre alla coppia comprende un particolare pezzo di codice. Quindi cosa succede se entrambi i membri della coppia se ne sono andati e il codice è scarsamente documentato? Altri perderanno tempo a cercare di capire le cose. Avere una terza persona che sa cosa hai fatto riduce il rischio.

Sono divertito dal fatto che la gente abbia detto che la revisione del codice è una perdita di tempo. Sì, ci vuole tempo. Forse non produrrà alcun cambiamento nel codice ma ciò non significa che sia sprecato. È come dire che non è necessario controllare regolarmente il sistema antincendio perché è una perdita di tempo.

Per me il vantaggio principale delle revisioni del codice è che consente alle persone di scrivere codice migliore.

Sapere che il tuo codice verrà letto e rivisto ti rende più consapevole della leggibilità e della "correttezza" del tuo codice. Quando sai che il codice sta andando direttamente nel repository e nessun altro lo leggerà a meno che non stiano risolvendo un difetto, tendi a lasciare che le cose scivolino come non ricoprire i nomi dei campi quando il loro uso cambia, lasciando i metodi inutilizzati in sospeso nel caso in cui potrebbero rientrare nel factoring ecc. ecc.