Preferisco fare il check-in, supponendo che lo sviluppatore abbia fatto il lavoro correttamente (cioè essere ottimista sulla loro qualità del codice)
Se risulta che una revisione richiede una rilettura, allora lo sviluppatore può controllare le correzioni - in molti modi questo è esattamente l'approccio adottato con bug, commit; costruire; test; commettere correzioni Non è un problema con le versioni, perché la revisione del codice dovrebbe essere diversa?
Creo sempre un ticket per la revisione, proprio come qualsiasi altro compito - e ne seguo il progresso, così che il dev commette, crea una nuova attività di revisione del codice per il commit e lo assegna al revisore che poi lo usa per registrare eventuali errori di revisione che hanno bisogno di lavoro - e li restituisce al dev che aggiusta e riassegna, o lo chiude.
Lo sviluppatore dovrebbe lavorare su una diramazione piuttosto che sulla linea principale, puoi quindi eseguire la revisione senza tenerlo su, può continuare a lavorare su altre attività, mentre aspetta che tu esegua la revisione.
Ai vecchi tempi ho utilizzato ReviewBoard per le recensioni: è necessario caricare un diff (lo SCM è stato automatizzato per fornire questi e creare le attività di revisione). Ora userei Redmine che può integrare il processo di revisione con lo strumento SCM e il suo ticket tracker integrato. (comunque avrai bisogno del plugin CodeReview).
In tutti i casi, rivedi dopo il commit: è l'unico modo per mantenere alta la produttività.
modifica rapida: i vantaggi del post-commit includono:
a) se contrassegni la revisione che hai revisionato, il codificatore non può imbrogliare e modificare il codice quando lo esegue dopo la revisione ...
b) lo strumento SCM ti offre una differenza rispetto a tutte le modifiche apportate dall'ultima revisione, rendendo più semplice la revisione.
c) in attesa che la revisione non blocchi il dev dal funzionamento.
Lavorerei comunque con le filiali in questo caso: dev lavora su un ramo, viene revisionato e unito a un ramo 'for testing', viene testato e quindi viene unito a un ramo 'for release'. In questo modo, puoi facilmente vedere che il processo di revisione è esattamente come il processo per il test in modo da poter gestire l'intero processo di consegna nello stesso modo.