Nel mio team, non facciamo revisioni formali del codice. Tendiamo a pensare che sia sufficiente con la programmazione delle coppie e le coppie rotanti spesso.
Dovremmo prendere in considerazione l'analisi formale del codice? Quali sarebbero i vantaggi?
Facciamo recensioni di codice un po 'diverse (forse).
Veniamo insieme tutti i programmatori (ogni venerdì) e vediamo 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 in circa un'ora guardiamo ai cambiamenti che sono stati fatti, alla ricerca di errori, a come funzionano altri progetti e così via. In seguito discutiamo, raccontiamo gli errori, come dovrebbe essere fatto (non sistemiamo bug li sottolineiamo solo e spam il codice con FIXME). Tutto sommato di solito per noi (10 programmatori) richiede circa 2 ore.
I pro:
Ciò che ho contro la programmazione delle coppie come menzionato (certo è solo la mia opinione personale) è che più il team lavora insieme - più velocemente diventa.
Spero che porti qualche spunto di riflessione. Buona fortuna.
Potresti leggere questo libro gratuito:
Certo, hanno un prodotto da spingere, ma ci sono ancora molte informazioni utili lì dentro.
Esaminano anche il modo in cui la programmazione della coppia offre alcuni degli stessi vantaggi, quindi se stai programmando la coppia potresti non aver bisogno di una revisione del codice.
Non ho molta esperienza nella revisione del tuo ambiente. Non facciamo molti programmi di coppia qui facciamo revisioni del codice per diffondere la conoscenza del software nel team, avere 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 revisioni formali del codice?
Proprio come una breve nota, ho molto poca esperienza con la programmazione accoppiata, ma non credo che le recensioni sarebbero in conflitto con questi metodi.
Vorrei introdurre due forme di revisione del codice:
recensioni del codice peer
Anche se la programmazione accoppiata funziona per te, mai fa male per ottenere un altro set di occhi sul codice. I vantaggi di questo sono:
Le recensioni dei peer code (nel mio mondo) sono condotte prima della ogni sottomissione. Non sono sicuro di come questo si riporti nel mondo della programmazione accoppiata.
recensioni di codici di gruppo
Si verificano meno frequentemente rispetto alle recensioni di peer code. Generalmente tirerei il mio gruppo (o una sottosezione del mio gruppo) in una sala riunioni per una revisione informale del codice. Generalmente sceglievo un codice scritto da una persona a caso sul team, codice preferibilmente scritto da zero - il codice refactored non espone problemi come il codice nuovo.
Assicurati che tutti sappiano che queste recensioni sono non pensate per emberass e non sono utilizzate per riflettere il rendimento. Si limitano a garantire che gli standard di codifica del team vengano seguiti e per aiutare tutti a diventare ingegneri migliori e, quindi, a diventare più utili per il team (e ulteriore crescita di carriera, ecc.) - e assicurarsi che questo è il vero intento delle recensioni. Se qualcuno sospetta qualcosa di diverso, questi saranno temuti e meno produttivi.
Vorrei passare il codice in qualche modo in modo informale, lasciando che chiunque nella stanza indichi diverse soluzioni che potrebbero avere o difetti logici che incontrano. Questo dovrebbe essere più di una discussione di gruppo di 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 diminuisce considerevolmente il conteggio degli errori:)
Non ho mai fatto programmi di coppia in pratica (l'ho solo sperato), quindi non posso confrontare direttamente le due pratiche. Tuttavia, posso raccontare le mie esperienze con recensioni formali del codice.
Ero solito condurre revisioni formali del codice in un progetto precedente, su un codice legacy. Il progetto era in completo disordine e la direzione ha accolto qualsiasi iniziativa con la speranza di mettere ordine nel caos. A quel tempo pensavo che la revisione formale del codice fosse una buona idea. Abbiamo trovato bug e abbiamo visto che la qualità del codice appena scritto era significativamente migliore di quella del vecchio codice. Ho raccolto statistiche, conteggi di errori ecc. Per dimostrarlo.
Abbiamo fatto una sessione alla settimana in media, coinvolgendo 3-5 persone. Ogni sessione richiedeva circa 3-4 ore di tempo a persona (compresa la preparazione) e rivedeva 200-300 righe di codice (LOC) *. In questo ritmo, durante un periodo di oltre 6 mesi, siamo riusciti a rivedere circa 5K LOC, su circa 50K.
In retrospettiva, sento che è stato molto costoso. Con questo ritmo, ci sarebbero voluti 5 anni per rivedere l'intero codice di base legacy. OTOH che ha più di una sessione a settimana avrebbe tolto risorse dallo sviluppo. Ovviamente, questo è il tipico dilemma con codice legacy. Ma anche rivedere formalmente tutto il codice scritto in modo formale richiederebbe molto tempo, rallentando lo sviluppo in modo significativo.
La mia conclusione è che le revisioni formali del codice sono fatte al meglio sul codice appena scritto, incentrato sulle parti più critiche del codice. Il resto è gestito meglio in maniera più informale, possibilmente tramite la programmazione di coppie. Questa è solo la mia opinione attuale, che potrebbe cambiare. Non pretendo di essere un guru della revisione del codice o altro.
* Questo è il normale ritmo delle recensioni formali del codice.
Typical code review rates are about 150 lines of code per hour. Inspecting and reviewing more than a few hundred lines of code per hour for critical software (such as safety critical embedded software) may be too fast to find errors.
Citato da Wikipedia (enfasi da parte mia).
Le recensioni del codice motivo sottostante esistono perché i programmatori isolati devono soddisfare e discutere il loro codice e verificare che sia conforme al loro standard.
Non parli di problemi di qualità, quindi sembra che la tua squadra stia già facendo abbastanza revisioni di codice attraverso la loro programmazione di coppia. Impressionante!
La corretta programmazione delle coppie rende superflue le revisioni del codice formale . 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.
Forse. Le recensioni del codice richiedono tempo. Ne vale la pena solo se il tempo impiegato dalla revisione viene salvato in un altro punto del processo. Quali risparmi ti aspetti dalle recensioni del codice? Stai riscontrando difficoltà che potrebbero essere prevenute dalle revisioni del codice?
Se si sta eseguendo la programmazione della coppia, la necessità di una revisione del codice diminuisce sostanzialmente, ma si trarrebbe certamente vantaggio da una revisione tra pari. Perché ciò avvenga, deve essere fatto da una persona anziana e più esperta rispetto ai membri della coppia.
Quali sono i vantaggi? Bene, sarebbe meglio se consideri i rischi di non farlo.
Sono divertito dal fatto che le persone abbiano affermato che la revisione del codice è una perdita di tempo. Sì, ci vuole tempo. Forse non produrrà alcun cambiamento nel codice, ma questo non significa che sia sprecato. È come dire che non è necessario controllare regolarmente il sistema antincendio perché è una perdita di tempo.
Per me il principale vantaggio delle revisioni del codice è che rende le persone scrivere un codice migliore.
Sapendo che il tuo codice sarà letto e revisionato ti renderai 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 si tratti di correggere i difetti, si tende a lasciare che le cose scivolino come se non si ripetessero i nomi dei campi quando il loro utilizzo cambia, lasciando in sospeso i metodi inutilizzati essere ripreso in ecc. ecc.
Leggi altre domande sui tag code-reviews agile pragmatism