Strategia di riesame del codice riuscita con SVN e ReviewBoard?

Question

Sono riuscito a introdurre ReviewBoard sul flusso di lavoro di codifica nella mia azienda, mentre "introdurre" significa averlo installato e presentato. Abbiamo anche un accordo generale sul fatto che abbiamo bisogno di revisioni del codice, ma non siamo abbastanza sicuri di come vorremmo farlo.

Il nostro controllo di revisione principale è SVN, quindi siamo piuttosto limitati nella ramificazione e nella fusione. Alcune strategie a cui ho pensato:

1. Revisione pre-commit dal trunk. I professionisti includono l'uso di una singola patch, senza codice non revisionato nel repository. I contras devono mantenere pulito il checkout o effettuare il branching di un uomo povero con diversi checkout
2. Revisione post-commit dal trunk. Funziona bene con Review Board, tuttavia non impedisce alle persone di commettere codice dirty e consente loro di ignorare le richieste di revisione.
3. Revisione post-commit da un ramo di funzionalità. I pro sono ovvi dal momento che una funzione può essere elaborata indipendentemente, tuttavia c'è un grande problema nella creazione di filiali basate su server e anche un dolore molto più grande nel mantenere sincronizzati diversi rami. Anche vedi punto 2.

vorrei rendere questo più indolore possibile, quindi ci sono diverse possibili aggiunte automatizzati per il flusso di lavoro, come avere un robot commettere codice che ha guadagnato almeno X "Spedicalo!" voti e facendo in modo che il comitato di revisione "segua" un ramo di funzionalità con i ganci di commit. Tuttavia, non sono sicuro che il flusso di lavoro di revisione del codice potrebbe essere il migliore per il nostro team di circa 8 codificatori. Non saremo in grado di cambiare i sistemi di controllo delle revisioni, ad esempio git-svn e SVK sono fuori questione (mentre il secondo è morto comunque).

Potete raccomandare qualcosa dalla vostra esperienza?

Answer 1

Base si sistema sulla fiducia e la responsabilità e tenerlo leggero:

1. usare il buon senso: 'È possibile controllare qualsiasi cosa in qualsiasi momento. Chiedi una revisione del codice quando ne hai bisogno. " Aggiungi 'recensito da' ai commenti se è stato esaminato per facilitare le recensioni veloci.
2. La scheda di revisione è responsabile del monitoraggio delle modifiche tramite i hook di commit. Se vedono qualcosa che non gli piace, portalo con lo sviluppatore. Diversi membri possono esaminare diverse sezioni.
3. Se uno sviluppatore continua a controllare la schifezza senza chiedere una revisione, licenziarli.
4. Se ci sono sezioni del sistema che sono insolitamente complicate/centrali/facili da incasinare - bloccarle e richiedere l'approvazione per il check-in.
5. Tutti possono monitorare i check-in. Revisione non è solo per la commissione di revisione.

ho visto questo lavoro con 2 sviluppatori e 100.

Answer 2

Un combinato del # 2 e # 3 (magari con recensioni tronco abbreviato se il ramo di caratteristica è già stato recensito) può funzionare bene . Trovo che il pre-commit rilasci un processo un po 'soffocante - meglio avere un entusiasmo (tenuto acceso da te?) Per la revisione infetta l'intera squadra.

Mi raccomando di consultare il libro gratuito di SmartBear, Best Kept Secrets of Peer Code Review, che è un trattamento davvero imparziale. considerando che il suo autore vende una suite di revisione del codice commerciale. (Non lavoro per loro, né utilizzo i loro prodotti, FWIW.)

Quel libro ti aiuterà a pensare attraverso entrambi i possibili flussi di lavoro per il tuo ambiente, e come introdurre i flussi di lavoro, spiegando al team perché potresti voler puntare a recensioni di Lo-cento x cento o meno, o avere un po ' di una visita guidata prima di recensioni, ecc

Answer 3

Siamo in una posizione simile.

Avete SVN configurato per inviare i tuoi sviluppatori con ogni commettere? Questo è un buon primo passo per mantenere tutti onesti. Mandiamo una mail con il messaggio di log, le prime 200 righe della svn diff, e un link all'intera diff in trac (che in pratica si usa solo per mostrare svn diffs).

Se uno sviluppatore pensa che un cambiamento ha bisogno di revisione dopo il fatto, usiamo ReviewBoard per eseguire la revisione.

D'altra parte, gli sviluppatori possono anche richiedere una revisione prima del check in. Sia che si sono sviluppati i cambiamenti su un ramo di funzione o in una sandbox tronco, non fa differenza. Abbiamo considerato di adattare gli script per caricare una richiesta di revisione dalla riga di comando, ma il processo è così semplice che non lo abbiamo ancora fatto, almeno finora.

mia raccomandazione generale è quello di introdurre un sistema manuale, ed automatizzare, e possibilmente farla rispettare con gli script pre-commit, una volta che si è soddisfatti con il processo. In particolare, con un team ristretto è meglio sbagliare a favore dell'applicazione della peer-pressure perché si vuole minimizzare il numero di piccoli processi di abbattimento della produttività.

Answer 4

Recentemente abbiamo introdotto ReviewBoard nel nostro processo. Prima di aggiungere ReviewBoard abbiamo avuto le seguenti cose:

1. SVN con e-mail inviata automaticamente a tutti gli sviluppatori per ogni check-in.
2. ViewCV integrato con per consentire la visualizzazione delle differenze tra post-commit con un browser.
3. Lo script SCM-bug integrato con SVN in modo che gli sviluppatori debbano includere un id grande con i relativi check-in.
4. Buildbot integrato con SVN per eseguire automaticamente i test dopo ogni check-in.

Dal momento che abbiamo già avuto la-commit dopo roba coperta abbastanza bene con altre cose, usiamo ReviewBoard come strumento di pre-commit e solo dopo abbiamo colpito 'feature-complete' per una data di rilascio.

Answer 5

In sviluppi più ampi, i rami di funzionalità sono inevitabili. Con SVN, non è possibile "aggiornare" il ramo della funzione dal trunk come dalla copia di lavoro. Tuttavia, potresti avere frequenti fusioni e creazioni di nuovi rami.

A proposito, sa RB per gestire pre-commit recensioni pure.

Answer 6

Sono d'accordo con il primo parere: pre-commit recensione dal tronco

Dal momento che l'uso di strumenti CodeReview, assicurarsi che nessun codice non recensiti nel repository, e per mantenere il vostro checkout pulito