Rivedi prima o dopo il commit del codice, che è meglio?

Tradizionalmente abbiamo eseguito la revisione del codice prima del commit, ho avuto una discussione con il mio collega oggi, che ha preferito la revisione del codice dopo il commit.

Innanzitutto, ecco alcuni retroscena,

1. Abbiamo alcuni sviluppatori esperti e abbiamo anche nuovi assunti con esperienza di programmazione quasi zero.
2. Vorremmo eseguire iterazioni veloci e brevi per rilasciare il nostro prodotto.
3. Tutti i membri del team si trovano nello stesso sito.

Ho imparato i vantaggi della revisione del codice prima del commit:

1. Mentore nuove assunzioni
2. Cerca di prevenire errori, guasti, cattivi progetti all'inizio del ciclo di sviluppo
3. Impara dagli altri
4. Backup della conoscenza se qualcuno esce

Ma ho anche avuto delle brutte esperienze:

1. Bassa efficienza, alcune modifiche potrebbero essere riviste nel corso dei giorni
2. Difficile bilanciare velocità e qualità, soprattutto per i neofiti
3. Un membro del team si è sentito sfiduciato

Per quanto riguarda la revisione post-commit, ne so poco, ma la cosa di cui sono più preoccupato è il rischio di perdere il controllo a causa della mancanza di revisione. Qualche opinione?

AGGIORNARE:

1. Stiamo usando Perforce per VCS
2. Codifichiamo e impegniamo negli stessi rami (rami di tronco o correzione di bug)
3. Per migliorare l'efficienza, abbiamo cercato di dividere il codice in piccole modifiche. Abbiamo anche provato alcune revisioni dei dialoghi dal vivo, ma non tutti hanno seguito la regola. Questo è un altro problema però.

Come menziona Simon Whitehead nel suo commento , dipende dalla tua strategia di ramificazione.

Se gli sviluppatori hanno un proprio ramo privato per lo sviluppo (che consiglierei comunque nella maggior parte delle situazioni), eseguirò la revisione del codice prima di unirmi al trunk o al repository principale. Ciò consentirà agli sviluppatori di avere la libertà di effettuare il check-in tutte le volte che vogliono durante il loro ciclo di sviluppo / test, ma ogni volta che il codice va nel ramo che contiene il codice consegnato, viene rivisto.

In generale, le tue brutte esperienze con le revisioni del codice sembrano più un problema con il processo di revisione con soluzioni. Esaminando il codice in blocchi più piccoli e individuali, puoi assicurarti che non impieghi troppo tempo. Un buon numero è che è possibile rivedere 150 righe di codice in un'ora, ma la velocità sarà più lenta per le persone che non hanno familiarità con il linguaggio di programmazione, il sistema in fase di sviluppo o la criticità del sistema (un critico per la sicurezza richiede più tempo) - queste informazioni potrebbero essere utili per migliorare l'efficienza e decidere chi partecipa alle revisioni del codice.

C'è un mantra che nessuno sembra aver ancora citato: fai il check-in in anticipo e spesso :

Gli sviluppatori che lavorano per lunghi periodi - e per lungo intendo più di un giorno - senza controllare nulla nel controllo del codice sorgente, si stanno preparando per alcuni gravi mal di testa nel processo di integrazione. Damon Poole concorda :

Gli sviluppatori spesso rimandano il check-in. Lo rimandano perché non vogliono influenzare troppo presto le altre persone e non vogliono essere incolpati per aver infranto la build. Ma questo porta ad altri problemi come perdere lavoro o non poter tornare alle versioni precedenti.

La mia regola empirica è "il check-in anticipato e spesso", ma con l'avvertenza di avere accesso al versioning privato. Se un check-in è immediatamente visibile agli altri utenti, si corre il rischio di introdurre modifiche immature e / o interrompere la build.

Preferirei che i frammenti venissero controllati periodicamente piuttosto che per lunghi periodi senza avere idea di cosa stiano scrivendo i miei colleghi. Per quanto mi riguarda, se il codice non è registrato nel controllo del codice sorgente, non esiste . Suppongo che questa sia l'ennesima forma di Don't Go Dark ; il codice è invisibile fino a quando non esiste nel repository in qualche forma.

... Se impari a fare il check-in anticipato e il check-in spesso, avrai tutto il tempo per feedback, integrazione e revisione lungo il percorso ...

Ho lavorato per un paio di aziende che avevano approcci diversi nei confronti di questo. Uno lo ha permesso, a condizione che non impedisse la compilazione. L'altro andrebbe fuori di testa se avessi verificato qualsiasi bug. Il primo è molto preferito. Dovresti svilupparti in un tipo di ambiente che ti consenta di collaborare con altre persone su cose che sono ancora in corso, con la consapevolezza che tutto sarà testato in seguito.

C'è anche la dichiarazione di Jeff Atwood: non abbiate paura di rompere le cose :

Il modo più diretto per migliorare come sviluppatore di software è di essere assolutamente impavido quando si tratta di cambiare il codice. Gli sviluppatori che hanno paura del codice non funzionante sono sviluppatori che non diventeranno mai professionisti.

Vorrei anche aggiungere che per le revisioni tra pari, se qualcuno vuole che tu cambi qualcosa, avere la cronologia della tua versione originale nella fonte è uno strumento di apprendimento molto prezioso.

Di recente ho iniziato a fare recensioni pre-commit in un progetto in cui mi trovo e devo dire che sono piacevolmente sorpreso da quanto sia problematico.

Il più grande svantaggio delle recensioni post-commit che vedo è che spesso si tratta solo di una sola persona aleatoria: qualcuno esamina il codice per correttezza, ma l' autore di solito non è coinvolto a meno che non ci sia un errore grave. Piccoli problemi, suggerimenti o suggerimenti di solito non raggiungono l'autore.

Questo cambia anche il risultato percepito delle recensioni del codice: è visto come qualcosa che produce solo lavoro aggiuntivo, al contrario di qualcosa in cui tutti (il recensore e l'autore del codice) possono imparare nuove cose ogni volta.

Le revisioni del codice pre-commit sembrano così naturali, non mi è mai venuto in mente che le recensioni potessero essere fatte deliberatamente dopo il commit. Da una prospettiva di integrazione continua, si desidera eseguire il commit del codice una volta terminato, non in uno stato funzionante, ma forse mal scritto, giusto?

Forse è perché il modo in cui l'abbiamo sempre fatto nei miei team è una finestra di dialogo attiva avviata dallo sviluppatore originale, non revisioni asincrone, basate sul controllo e basate su documenti.

La maggior parte dei repository oggi supporta un commit in due fasi o uno shelfet (filiale privata, richiesta pull, invio patch o come si desidera chiamarlo), che consentirà di ispezionare / rivedere il lavoro prima di inserirlo nella linea principale. Direi che sfruttare questi strumenti ti permetterebbe di fare sempre recensioni pre-commit.

Inoltre, potresti considerare la codifica di coppia (coppie senior con junior) come un altro modo di fornire una revisione del codice integrata. Consideralo come un'ispezione di qualità sulla catena di montaggio invece che dopo che l'auto è partita.

Fai entrambi :

• pre commit - fai questo tipo di recensioni quando è qualcosa di molto importante, come un pezzo di codice molto riutilizzabile o una decisione di progettazione importante
• post commit - fai questo tipo di recensioni quando vuoi ottenere opinioni su un pezzo di codice che potrebbe essere migliorato

Qualsiasi revisione formale deve essere intrapresa sui file di origine che sono sotto controllo di configurazione e i record di revisione indicano chiaramente la revisione del file.

Ciò evita qualsiasi argomento di tipo "non hai l'ultimo file" e garantisce che tutti stiano rivedendo la stessa copia del codice sorgente.

Significa anche che, qualora fossero necessarie eventuali correzioni post-revisione, la cronologia può essere annotata con questo fatto.

Per la revisione del codice stesso, il mio voto è per "durante" il commit.

Un sistema come gerrit o clover (penso) può mettere in scena un cambiamento e quindi fare in modo che il revisore lo commetta al controllo del codice sorgente (push in git) se è buono. Questo è il migliore di entrambi i mondi.

Se ciò non è pratico, penso che dopo l'impegno sia il miglior compromesso. Se il design è buono, solo gli sviluppatori più giovani dovrebbero avere cose abbastanza brutte che non le vuoi impegnare mai. (Fai una revisione pre-commit per loro).

Il che porta alla revisione del progetto - mentre puoi farlo al momento della revisione del codice (o del resto al momento della distribuzione del cliente), la ricerca di problemi di progettazione dovrebbe essere fatta prima di quello - prima che il codice sia effettivamente scritto.

Con la peer review c'è un rischio minimo di perdere il controllo. Sempre due persone hanno conoscenza dello stesso codice. Devono cambiare di tanto in tanto, quindi devono essere sempre attenti a tenere traccia del codice.

Ha senso avere uno sviluppatore abile e un principiante che lavorano insieme. A prima vista questo sembra essere inefficiente, ma non lo è. In effetti, ci sono meno bug e ci vuole meno tempo per risolverli. Inoltre, i neofiti impareranno molto più velocemente.

Ciò che impedisce la cattiva progettazione, questo dovrebbe essere fatto prima della codifica. In caso di modifiche / miglioramenti / nuovi progetti significativi, è necessario rivederlo prima dell'inizio della codifica. Quando il design è completamente sviluppato, non c'è molto da fare. La revisione del codice sarà più semplice e richiederà meno tempo.

Concordo sul fatto che non è essenziale rivedere il codice prima di impegnarsi solo se il codice è prodotto da uno sviluppatore esperto, che ha già dimostrato le proprie capacità. Ma se c'è un novizio, il codice dovrebbe essere rivisto prima di impegnarsi: il revisore dovrebbe sedersi accanto allo sviluppatore e spiegare ogni cambiamento o miglioramento apportato da loro.

Le recensioni traggono vantaggio sia dal pre che dal post commit.

Commessa pre-revisione

• Dà ai revisori la fiducia che stanno rivedendo l'ultima revisione dell'autore.
• Aiuta a garantire che tutti rivedano lo stesso codice.
• Fornisce un riferimento per il confronto una volta completate le revisioni apportate dagli elementi della recensione.

Nessun commit in esecuzione durante la revisione

Ho usato gli strumenti di Atlassian e ho visto eseguire degli commit durante la revisione. Questo è fonte di confusione per i revisori, quindi sconsiglio.

Revisioni post revisione

Dopo che i revisori hanno completato il loro feedback, verbalmente o per iscritto, il moderatore dovrebbe assicurarsi che l'autore apporti le modifiche richieste. A volte i revisori o l'autore possono non essere d'accordo sul fatto se designare un articolo di revisione come un difetto, un suggerimento o un'indagine. Per risolvere i disaccordi e garantire che gli elementi dell'indagine vengano liquidati correttamente, il team di revisione dipende dal giudizio del moderatore.

La mia esperienza con circa 100 ispezioni di codice è che quando i revisori possono fare riferimento a uno standard di codifica inequivocabile e per la maggior parte dei tipi di logica e altri errori di programmazione, i risultati della revisione sono generalmente chiari. Occasionalmente c'è un dibattito sul nit-picking o un punto di stile può degenerare in discussione. Tuttavia, dare potere decisionale al moderatore evita lo stallo.

Impegno post-revisione

• Fornisce al moderatore e agli altri revisori un punto dati da confrontare con il commit pre-revisione.
• Fornisce metriche per giudicare sia il valore che il successo della revisione nella rimozione dei difetti e nel miglioramento del codice.

Dipende dal trucco della tua squadra. Per un team relativamente esperto che è bravo con piccoli e frequenti commit, allora la revisione post-commit solo per avere un secondo paio di occhi sul codice va bene. Per i commit più grandi e complessi e / o per gli sviluppatori meno esperti, pre-commit delle recensioni per risolvere i problemi prima che entrino sembra più prudente.

In questo senso, avere un buon processo di CI e / o check-in gated riduce la necessità di revisioni prima del commit (e probabilmente post-commit per molti di loro).

Io e i miei colleghi abbiamo fatto alcune ricerche scientifiche su questo argomento di recente, quindi vorrei aggiungere alcune delle nostre intuizioni nonostante questa sia una domanda piuttosto vecchia. Abbiamo creato un modello di simulazione di un agile processo / team di sviluppo Kanban e confrontato la revisione pre-commit e post-commit per un gran numero di situazioni diverse (diverso numero di membri del team, diversi livelli di abilità, ...). Abbiamo esaminato i risultati dopo 3 anni di tempo di sviluppo (simulato) e abbiamo riscontrato differenze in termini di efficienza (punti trama finiti), qualità (bug rilevati dai clienti) e tempo di ciclo (tempo dall'inizio alla consegna di una storia utente) . I nostri risultati sono i seguenti:

• Le differenze in termini di efficienza e qualità sono trascurabili in molti casi. In caso contrario, la revisione post commit presenta alcuni vantaggi in termini di qualità (altri sviluppatori agiscono come "beta-tester" in un certo senso). Per motivi di efficienza, il post commit presenta alcuni vantaggi in team di piccole dimensioni e il pre commit ha alcuni vantaggi in team di grandi dimensioni o non qualificati.
• La revisione pre-commit può comportare tempi di ciclo più lunghi, quando si verifica una situazione in cui l'avvio delle attività dipendenti è ritardato dalla revisione.

Da questi, abbiamo derivato le seguenti regole euristiche:

• Quando hai un processo di revisione del codice stabilito, non preoccuparti di cambiare, probabilmente non ne vale la pena
  • a meno che tu non abbia problemi con il tempo di ciclo => Passa a Posta
  • O i problemi scivolati interrompono troppo spesso i tuoi sviluppatori => Passa a Pre
• Se non stai ancora facendo recensioni
  • Usa pre commit se uno di questi vantaggi è applicabile per te
    • La revisione pre commit consente agli estranei senza diritti di commit di contribuire a progetti open source
    • Se basato su strumenti, la revisione pre commit impone una certa disciplina di revisione nei team con aderenza al processo altrimenti lassista
    • La revisione pre commit consente di evitare la consegna di modifiche non ancora visualizzate, il che è utile per cicli di distribuzione continui / rilasci molto brevi
  • Usa pre commit se la tua squadra è grande e puoi convivere o aggirare i problemi nel tempo di ciclo
  • Altrimenti (ad es. Team industriale piccolo e competente) utilizzare post commit
• Cerca combinazioni che ti offrano i vantaggi di entrambi i mondi (non li abbiamo studiati formalmente)

Il documento di ricerca completo è disponibile qui: http://dx.doi.org/10.1145/2904354.2904362 o sul mio sito Web: http://tobias-baum.de

A mio avviso, la revisione tra pari del codice funziona meglio se eseguita dopo il commit.

Consiglierei di adattare la tua strategia di ramificazione. L'uso di una filiale sviluppatore o di una funzione presenta numerosi vantaggi ... non ultimo quello che facilita le revisioni del codice post-commit.

Uno strumento come Crucible faciliterà e automatizzerà il processo di revisione. È possibile selezionare uno o più changeset impegnati da includere nella revisione. Crucible mostrerà quali file sono stati toccati nei changeset selezionati, terrà traccia di quali file ha già letto ogni revisore (mostrando una percentuale completa di%) e consentirà ai revisori di commentare facilmente.

http://www.atlassian.com/software/crucible/overview

Alcuni altri vantaggi dei rami utente / funzionalità:

• Gli sviluppatori ottengono i vantaggi del controllo della versione (backup delle modifiche, ripristino dalla cronologia, modifiche alle differenze) con meno preoccupazioni per la rottura del sistema per tutti gli altri.
• Le modifiche che causano difetti o che non vengono completate in tempo possono essere annullate, riordinate o accantonate se necessario.

Per gli sviluppatori inesperti, una regolare consultazione con un mentore e / o la programmazione di coppia è una buona idea, ma non la considero una "revisione del codice".

Entrambi. (Tipo.)

Dovresti rivedere il tuo codice sommariamente prima di impegnarlo. In Git, penso che l'area di stadiazione sia fantastica. Dopo aver messo in scena le mie modifiche, corro git diff --cachedper vedere tutto ciò che è in scena. Lo uso come un'opportunità per assicurarmi di non archiviare alcun file che non appartiene (creare manufatti, registri, ecc.) E assicurarmi di non avere alcun codice di debug o commenti importanti su. (Se sto facendo qualcosa che so di non voler fare il check-in, di solito lascio un commento in maiuscolo in modo da riconoscerlo durante la messa in scena.)

Detto questo, la revisione del codice peer dovrebbe essere generalmente condotta dopo il commit, supponendo che si stia lavorando su un ramo di argomento. Questo è il modo più semplice per assicurarsi che tutti gli altri stiano rivedendo la cosa corretta, e se ci sono problemi importanti, non è un grosso problema ripararli sul tuo ramo o eliminarli e ricominciare da capo. Se esegui revisioni del codice in modo asincrono (ovvero utilizzando Google Code o Atlassian Crucible), puoi facilmente cambiare ramo e lavorare su qualcos'altro senza dover tenere traccia separatamente di tutte le diverse patch / differenze che sono attualmente in fase di revisione per alcuni giorni.

Se non stai lavorando su un argomento, dovresti . Riduce lo stress e le seccature e rende la pianificazione del rilascio molto meno stressante e complicata.

Modifica: dovrei anche aggiungere che dovresti fare la revisione del codice dopo il test, che è un altro argomento a favore del commit del codice prima. Non vuoi che il tuo gruppo di test si armeggi con dozzine di patch / diff da tutti i programmatori, quindi archivia i bug solo perché hanno applicato la patch sbagliata nel posto sbagliato.

Programmazione accoppiata al 100% (non importa quanto senior pensi di essere) con molti piccoli commit e un sistema CI che si basa su OGNI commit (con test automatizzati che includono unità, integrazione e funzionalità ove possibile). Revisioni post-commit per modifiche grandi o rischiose. Se devi avere una sorta di recensione gated / pre-commit, Gerrit funziona.

Il vantaggio della revisione del codice al momento del check in (buddy check) è il feedback immediato, prima che siano state completate grandi quantità di codice.

Lo svantaggio della revisione del codice al momento del check-in è che può scoraggiare le persone dal check-in fino al completamento di lunghi tratti di codice. Se ciò accade, nega completamente il vantaggio.

Ciò che rende questo più difficile è che non tutti gli sviluppatori sono uguali. Le soluzioni semplici non funzionano per tutti i programmatori . Le soluzioni semplici sono:

• Programmazione obbligatoria delle coppie, che consente di effettuare controlli frequenti perché il compagno è proprio accanto a te. Questo ignora che la programmazione delle coppie non funziona sempre per tutti. Effettuata correttamente, la programmazione delle coppie può anche essere davvero stancante, quindi non è necessariamente qualcosa da fare tutto il giorno.

• Filiali degli sviluppatori, il codice viene rivisto e verificato nel ramo principale solo al termine. Alcuni sviluppatori sono inclini a lavorare in segreto e dopo una settimana escogitano del codice che può o meno passare in rassegna a causa di problemi fondamentali che potrebbero essere stati individuati in precedenza.

• Revisionare ad ogni check-in, che garantisce revisioni frequenti. Alcuni sviluppatori dimenticano e fanno affidamento su check-in molto frequenti, il che significa che altri devono fare revisioni del codice ogni 15 minuti.

• Revisionare in un momento non specificato dopo il check-in. Le recensioni verranno ulteriormente spinte fuori in caso di scadenza. Verrà eseguito il commit del codice che dipende dal codice già impegnato ma non ancora rivisto. Le recensioni segnaleranno i problemi e i problemi verranno inseriti nel backlog per essere risolti "in seguito". Ok, ho mentito: questa non è una soluzione semplice, non è affatto una soluzione. Revisionare in un determinato momento dopo il check-in funziona, ma è meno semplice perché è necessario decidere quale sia il tempo specificato

In pratica, fai questo lavoro rendendolo ancora più semplice e complesso allo stesso tempo. Stabilisci semplici linee guida e lasci che ogni team di sviluppo capisca come una squadra cosa devono fare per seguire queste linee guida. Un esempio di tali linee guida è:

• Il lavoro è suddiviso in compiti che dovrebbero richiedere meno di un giorno.
• Un'attività non è terminata se il codice (se presente) non è stato archiviato.
• Un'attività non è terminata se il codice (se presente) non è stato rivisto.

Sono possibili molte forme alternative di tali linee guida. Concentrati su ciò che realmente desideri (codice peer review, progressi osservabili del lavoro, responsabilità) e lascia che il team capisca come possono darti ciò che vogliono.

in realtà facciamo un ibrido su LedgerSMB. I committenti commettono modifiche che vengono riviste dopo. I non committenti inviano le modifiche ai committenti che devono essere riviste prima. Ciò tende a significare due livelli di revisione. Innanzitutto ottieni un tutor che ti esamina e ti assiste. Quindi quel mentore ottiene il codice rivisto una seconda volta dopo aver firmato e fatto circolare il feedback. I nuovi committer di solito passano molto tempo a rivedere inizialmente gli impegni degli altri.

Funziona abbastanza bene. La cosa però è che una recensione dopo è di solito più rapida di una recensione prima, quindi vuoi assicurarti che la recensione dopo sia riservata a coloro che si sono dimostrati. Ma se hai una revisione a due livelli per le nuove persone, ciò significa che è più probabile che i problemi vengano colti e che le discussioni abbiano avuto.

Commettere dove? C'è un ramo che ho creato per fare un po 'di lavoro. Mi impegno in quel ramo ogni volta che ne ho voglia. Non sono affari di nessuno. Quindi ad un certo punto quel ramo è integrato in un ramo di sviluppo. E da qualche parte nel mezzo c'è una revisione del codice.

Il recensore recensisce ovviamente dopo che mi sono impegnato nella mia filiale. Non è seduto alla mia scrivania, quindi non può esaminarlo prima di impegnarmi nel mio ramo. E rivede prima della fusione e si impegna nel ramo di sviluppo.

Basta non fare recensioni di codice. O ritieni che i tuoi sviluppatori siano in grado di scrivere un buon codice o dovresti sbarazzartene. Gli errori nella logica dovrebbero essere colti dai test automatici. Errori è lo stile dovrebbe essere colto da strumenti di analisi lanugine e statici.

Avere gli umani coinvolti in quelli che dovrebbero essere processi automatici è solo uno spreco.