Qual è il modo migliore per rivedere un codice prima che venga eseguito il commit nel trunk? (SVN)

Qual è il modo migliore per rivedere un codice prima che venga eseguito il commit nel trunk SVN? Un'idea a cui sto pensando è di avere lo sviluppatore a impegnare il suo codice in un ramo e quindi a rivedere il suo codice unendo le revisioni del ramo nel trunk. È una buona pratica? In caso contrario, cos'altro si potrebbe fare per rivedere un codice prima che venga eseguito il commit nel trunk?

Tuttavia, ci sono due scuole: ciò che proponi o "rivedi prima di impegnarti". La maggior parte delle differenze può essere vista come aspetti negativi e / o positivi. - ad es. nessun tracciamento delle modifiche causate da una recensione - vuoi vederle come commit discreti o sei interessato solo al lavoro finale?

Revisiona prima del commit: non è richiesta la ramificazione (anche se può essere eseguita se lo si desidera), deve consentire ai revisori di accedere alle cartelle di lavoro. Il codice può essere modificato durante e dopo la revisione senza tracciamento. Le correzioni causate dalla revisione non vengono visualizzate nel repository.

Revisione dopo commit (su un ramo): è necessario ruotare un ramo per ogni revisione (anche se questo potrebbe essere già nel flusso di lavoro). Il codice inviato per la revisione non può essere modificato senza tenere traccia delle modifiche. Qualcuno deve unire i rami recensiti e tenere traccia di ciò che è stato rivisto e cosa no.

Dipende in gran parte dalla cultura e dall'esperienza del team. Qual è il modello di cui ti fidi, qual è lo scopo principale delle recensioni? Personalmente preferisco la revisione dopo il commit, poiché consente di tenere traccia delle modifiche a seguito della revisione. Ora usiamo Git e Gerrit in quanto forniscono un buon equilibrio tra le due opzioni.

1. Prima di eseguire il commit eseguire 'svn diff' per generare un file patch.
2. Invia il file patch al revisore che lo applica a una copia pulita del trunk.
3. Il revisore esamina le modifiche utilizzando il visualizzatore di differenze preferito.
4. Il revisore esegue build ed esegue test.
5. Se tutto va bene dì allo sviluppatore che può controllare le sue modifiche. In caso di
   problemi, lo sviluppatore torna al passaggio 1.

C'è il mondo ideale, e poi c'è il mondo reale.

Nel mondo ideale , tutto il tuo codice viene testato, quindi puoi essere sicuro che tutto ciò che viene archiviato funzionerà o saprai che è rotto perché fallisce uno o più test. Inoltre, chiunque non sia così esperto verrà accoppiato con qualcuno che ha esperienza, quindi la revisione del codice viene eseguita al volo (ti impegni mentre procedi).

Nel mondo reale , le cose sono diverse. Gli affari vogliono che il cambiamento sia vivo adessoe ti dirò, con una faccia perfettamente seria, che sì, avrai tempo per ripulire il codice e aggiungere casi di test in seguito. Probabilmente non avrai tempo di rivedere tutto il codice e la percentuale di codice coperta dai test diminuisce continuamente. Il motivo principale della revisione del codice è che gli sviluppatori junior possano imparare dagli sviluppatori senior (quando c'è tempo) facendo in modo che una persona più esperta controlli le modifiche e suggerisca "modi migliori di fare le cose". Avrai sviluppatori senior che si limitano a commettere codice non revisionato. La diramazione solo per una revisione del codice e quindi la fusione è un'enorme perdita di tempo. Un modo per ovviare a questo problema è quello di dichiarare una riunione settimanale periodica di 2 ore (circa) in cui si scelgono uno o due cambiamenti recenti su cui le persone hanno lavorato con breve preavviso e si sono fatti "presentare" dai propri autori il loro approccio guardando il codice insieme su un proiettore o qualcosa del genere Questo può portare ad alcune discussioni interessanti (in genere va un po 'fuori tema) ma generalmente migliora la comprensione di tutti su come farlo nel modo giusto. Inoltre la pressione di dover presentare il tuo codice fa sì che alcune persone lo facciano meglio ;-)

Oppure potresti essere fortunato e lavorare in un ambiente reale in cui non è così frenetico, i programmatori sono apprezzati per quello che fanno invece di abusare, e c'è tempo per fare tutto nel modo giusto. Nel qual caso la mia risposta sarebbe: provare alcuni dei diversi metodi suggeriti nelle risposte qui e vedere quale si adatta alla tua squadra e al modo in cui lavori meglio.

Le filiali dovrebbero funzionare correttamente, in base alla mia esperienza con le recensioni preimpegnate durante il lavoro precedente.

_{Nota allora, stavamo usando le recensioni pre-commit solo per le patch critiche al codice candidato alla versione di produzione, quindi non c'erano molti rami (le modifiche di routine venivano passate attraverso le recensioni post-commit).}

Dal momento che sembrerai utilizzare le recensioni pre-commit per tutte le modifiche, potrebbe essere necessario gestire una grande quantità di filiali. Se ti aspetti che lo sviluppatore effettui una modifica "recensibile" a settimana in media, finirai per avere circa 50 filiali ogni anno per ogni sviluppatore del team. Se stai usando piccoli pezzi di lavoro - come quelli che richiedono 1, 2, 3 ... giorni - moltiplica 50 per 2, 3, 5 ... di conseguenza.

Di seguito sono riportate alcune altre considerazioni da prendere in considerazione se lo si desidera nel modo migliore .

1. gestire i casi in cui la revisione ritardata blocca il codice necessario per gli altri membri del team

Stabilire, monitorare e risolvere i conflitti relativi alle scadenze di revisione del codice. Per quanto mi riguarda delle revisioni preimpegnate alle modifiche di routine che ho affrontato in uno dei progetti precedenti, la scadenza ragionevole è di circa 3 giorni e il tempo per iniziare a preoccuparsi è quando la revisione non viene completata più di 1 giorno dopo l'invio.

_{Per fare un confronto, nelle revisioni post-commit questi requisiti sono molto più rilassati (sto usando una scadenza di 2 settimane e comincio a preoccuparmi dopo 1 settimana) - ma poiché hai come target le recensioni pre-commit, questo probabilmente non è interessante.}

2. unire i conflitti quando si invia il codice esaminato

Cosa fare se il commit per il codice esaminato è bloccato da modifiche in conflitto commesse da qualcun altro mentre il codice era in attesa di revisione?

Un paio di opzioni da considerare sono

• tornare all'inizio e richiedere agli sviluppatori di reimplementare e riesaminare la modifica.
  In tal caso, potrebbe essere necessario affrontare un impatto negativo sul morale della squadra che ciò potrebbe (sarà!).
• passare la responsabilità di unire ad altri membri del team ("unisci master").
  In tal caso, dovrai anche decidere se le fusioni di per sé devono essere sottoposte alla revisione pre-commit o meno - e se sì, quindi cosa fare nel caso in cui quella fusione a sua volta incontra un altro conflitto.
• ignorare le modifiche apportate al codice rivisto nella fase di unione
  In tal caso, potrebbe essere necessario affrontare un impatto negativo sul morale della squadra in relazione al fatto che il codice impegnato differisce da quello rivisto.
• inventare un modo per evitare conflitti L'
  approccio diretto è quello di consentire a un solo sviluppatore alla volta di modificare un determinato set di file, anche se questo non ti proteggerà dal tipo di cambiamenti che non modificano direttamente i file, ma li influenzano attraverso le modifiche interne all'API . Potresti anche scoprire che questo tipo di "blocco pessimistico" rende problematiche le modifiche a livello di sistema e il refactoring profondo.

_{Per fare un confronto, non ci sarebbero problemi di questo tipo nelle revisioni post-commit (dal momento che riguardano il codice che è già unito per definizione) - ma poiché si prendono di mira le recensioni pre-commit, questo probabilmente non è interessante.}

3. caricare lo sviluppatore che è in attesa di revisione

Stabilire una politica esplicita per stabilire se lo sviluppatore che ha inviato la recensione debba passare a una nuova attività o fare qualcos'altro (come ad esempio inseguendo il revisore).

_{Per fare un confronto, le revisioni post-commit non necessitano quasi di una politica esplicita (poiché è naturale procedere con l'attività successiva dopo aver impegnato il codice e tenendo conto che la scadenza delle revisioni è di una settimana o due) - ma poiché si scelgono le recensioni pre-commit, questo è probabilmente non interessante.}

Qualsiasi pezzo di sviluppo che necessita di una revisione dovrebbe trovarsi in un ramo separato. Quindi, il ramo dovrebbe già esistere prima che arrivi il momento della revisione. Quindi il passaggio dovrebbe essere:

1. Revisione
2. Revisiona (possibilmente)
3. ritorna alla recensione (possibilmente)
4. Unisci nel bagagliaio

La fusione è la parte difficile. Più a lungo il ramo rimane indipendente, più sarà difficile rimetterlo nel tronco. (Potrebbe anche essere più difficile testarlo.)

La fusione incrociata è una possibile soluzione. Prima di fondersi nel trunk (passaggio 4, o anche prima, dire prima del passaggio 3 o passaggio 1), unire il tronco nel ramo. Lo sviluppatore può farlo e testarlo. Quindi il ramo raggiunge il tronco e diventa più facile fonderlo nel tronco. La fusione nel bagagliaio è fatta meglio da te o da chiunque sia responsabile del bagagliaio.

Alcune persone provano a rebase anziché a cross-merge. Alcune persone sostengono che rebase sia malvagio. Questo è un altro dibattito.