Come convincere gli sviluppatori a fare revisioni del codice in modo tempestivo

La società per cui lavoro richiede che tutto il codice sia rivisto da altri sviluppatori prima che venga eseguito il commit. I membri del mio team sono spesso frustrati perché gli altri sviluppatori sono troppo impegnati a scrivere un codice per fare una recensione, soprattutto se è molto lungo. In che modo incentivi altri sviluppatori a fare revisioni tempestive del codice?

(Usiamo git-svn in modo da poter continuare a scrivere codice in attesa di una recensione. Tuttavia, lo trovo ancora frustrante quando devo aspettare molto tempo prima di poter eseguire il commit del mio codice.)

Guarda come lo fa Facebook con la propria app, chiamata phabricator: http://phabricator.org/

Fondamentalmente si impegnano per ogni problema e, per ogni problema, viene mostrato il codice, che deve essere rivisto da qualcuno. Il codice non entra nel loro repository principale fino a quando il revisore non ha dichiarato che va bene farlo.

Immagino che lo renda più divertente.

Inoltre, forse un codice dovrebbe essere assegnato a due persone: una che lo fa e una che lo recensisce.

Anche se forse i tuoi compagni di squadra non credono in questa recensione.

Personalmente, in mancanza di revisori, ho usato i test unitari per le funzioni di livello inferiore e "il test del custode" per tutto il resto: il test del custode è chiamato in quel modo, perché anche il custode dovrebbe essere in grado di capire il tuo codice.

Di solito rimuovevo alcune parti minori, come parentesi di blocco / funzione, notazioni di visibilità, talvolta anche tipi, e lo mostravo a manager, esperti di dominio, compagni, chiunque avesse richiesto il codice: "è questo quello che vuoi?"

Inoltre, andare lì personalmente e non partire fino a quando non viene effettuata la revisione aiuta.

Oppure, nel caso in cui tu non stia bene con la squadra, o non stiano bene con te, sai "se puoi 'cambiare la compagnia, cambiare la compagnia" ...

Lo baserò su un paio di ipotesi:

1. Tutti sembrano voler scrivere codice (in caso contrario, ci sono persone che devono andare.).
2. Tutti vogliono che il proprio codice venga archiviato.

Consenti solo a coloro che completano le loro recensioni di controllare il proprio codice.

Forse un certo lasso di tempo può essere dedicato alle revisioni del codice nella speranza di evitare il problema di essere interrotti.

L'obiettivo dovrebbe essere quello di verificare il codice di qualità. Non vuoi punire / forzare le recensioni al punto in cui tutti danno semplicemente l'approvazione del "timbro di gomma".

Se hai diversi livelli (jr., Sr. Ecc.), La promozione e il mantenimento di un titolo dovrebbero dipendere dal tuo lavoro.

In un paio di precedenti datori di lavoro, abbiamo ruotato ogni giorno chi era in Code Review. Di solito 3 persone condividevano un giorno CR e ogni CR doveva essere firmato da due revisori. Ciò ha fatto sì che quando fosse la tua giornata, sapevi che ci si aspettava da te CR, indipendentemente dagli altri tuoi progetti. Quindi, ogni cinque giorni circa, è stato il tuo turno e puoi adattare di conseguenza le tue attività di sviluppo.

Attualmente, abbiamo un Team Lead che esegue un CR superficiale sul codice del suo team. A seconda di quale area dell'applicazione è stata aggiornata, dopo che il CR è stato completato, può essere trasferito al Global Review Team, dove controlliamo le cose che hanno un impatto globale sulle applicazioni, invece di quelle che sono correlato a una singola funzione. Quando c'è una grande recensione da fare, di solito la dividiamo tra poche persone, quindi nessuna persona deve affrontare le modifiche attraverso un numero ridicolo di file.

Detto questo, stiamo solo rivedendo il codice che è stato assegnato all'attuale ramo / variante Dev. Il codice deve superare Code Review, Global Review, DB Review e UI Review (ciascuno secondo necessità) prima di poter essere promosso nell'ambiente successivo (ad es. Alpha).

Infine, accettiamo un contratto di servizio relativo alla rapidità con cui le recensioni vengono invertite. Quasi nulla è in coda per più di 48 ore e la maggior parte delle recensioni viene effettuata in meno di 24 ore.

La società per cui lavoro richiede che tutto il codice sia rivisto da altri sviluppatori prima che venga eseguito il commit. I membri del mio team sono spesso frustrati ...

A meno che non si stiano eseguendo software mission-critical o patch critiche per il codice candidato alla versione in produzione, non vi sono motivi validi per attenersi rigidamente a particolari tipi di revisioni del codice.

• ^{L'idea alla base dei requisiti della tua azienda sembra ragionevole su una superficie (codice revisionato al 100%), ma i mezzi che hanno deciso di utilizzare sono controproducenti, perché come fai notare, questi portano a frustrare gli sviluppatori.}

Camminando nei tuoi panni, vorrei prima dire alla direzione che le revisioni del codice post-commit sono considerate altrettanto rispettabili di quelle pre-commit . Questi termini sono disponibili per la ricerca sul Web. Se necessario, trovare i riferimenti per eseguire il backup. Uno non ha necessariamente bisogno di revisioni pre-commit per ottenere il codice recensito al 100%.

Sulla base di quanto sopra, suggerirei loro di abbandonare l' atteggiamento di microgestione e di lasciare che gli sviluppatori provino il modo più comodo per loro. È consigliabile lasciare le recensioni pre o post commit ai programmatori. Se l'azienda conosce meglio dei programmatori, perché non scrivono il codice da soli?

Hai una serie di problemi da affrontare: devi conquistare i cuori e le menti e devi assicurarti che il tempo sia disponibile per le revisioni del codice.

La seconda parte è probabilmente più semplice - sei d'accordo (collettivamente e questo deve includere la gestione) che la prima cosa che fa uno sviluppatore ogni mattina sono le sue revisioni del codice - questo è semplice, comprensibile, efficace e ti dà un bel bastone chiaro per battere le persone con se non sono conformi. Meglio, non stai interrompendo nulla, non stai chiedendo loro di smettere di lavorare sul loro codice, non stai chiedendo alle persone di spremere qualcosa nella loro lista di cose da fare ...

La prima parte è il vero problema: i partecipanti al processo di revisione devono vederlo come valore altrimenti non faranno mai una revisione del codice (che si ritiene non abbia valore) quando potrebbero scrivere codice o correggere bug (che è sicuramente più importante ...?).

Se riesci a mettere insieme i due - in primo luogo assicurando che tutti credano (o comprendano) che vi sia valore nelle revisioni del codice - al massimo dovrebbe significare meno bug, il che significa più nuovo codice che di solito è più divertente - e poi organizzare in secondo luogo cose in modo che ci sia uno spazio libero nel programma per le revisioni del codice, quindi speriamo che succedano cose buone ... diventerà parte della cultura.

Una volta che fa parte della cultura, potrebbe non essere più necessario dire "prima cosa ogni giorno" - ma avendo detto che penso che si adatti bene al modello in cui si vorrebbe probabilmente lavorare uno sviluppatore.

Nella maggior parte delle aziende per cui ho lavorato, hai 3 giorni per completare una recensione. Non è accettabile non fare le recensioni. Fa parte del tuo lavoro. Se non fai recensioni decenti in tempo, ciò influisce sulla tua valutazione delle prestazioni. E sì, le recensioni sembrano sempre accadere nei momenti più inopportuni. Peccato, impara a includere i tempi di revisione nelle tue stime. Ad ogni modo, se il management crede davvero che le revisioni siano importanti (es. Obbligano a rivedere tutto il codice), spingerebbe una politica simile. Inoltre, se le persone non completano la revisione nel tempo assegnato, ciò corrisponde alla loro accettazione del materiale.

Prendi in considerazione l'utilizzo di uno strumento come Review Board . È molto utile, soprattutto per le recensioni lunghe.

Puoi caricare i tuoi diff e attendere fino a quando un revisore ha terminato la sua recensione. Se disponi di revisioni aperte che ti impediscono di continuare il tuo lavoro, puoi segnalarlo durante le riunioni quotidiane (il tuo team desidera che le nuove funzionalità vengano verificate in modo che possano essere testate il prima possibile, vero?).

Alcuni punti da aggiungere che non sono nelle altre risposte.

Il codice da rivedere deve essere registrato

• in modo da rivedere una versione stabile.
• Può trovarsi nel ramo di sviluppo principale se una versione è abbastanza lontana
• Può essere sul ramo se c'è una buona ragione per non inquinare principale

Le attività di blocco hanno la priorità, pertanto le revisioni del codice dovrebbero avere la priorità su altri lavori (ma cercando di non interrompere il flusso). Come sviluppatore dovresti chiedere ad altri di rivedere il tuo codice (dato che stai cercando di migliorarlo). In tale consapevolezza, è necessario eseguire prontamente recensioni per gli altri.

Le domande più difficili sono quando e come fare bene le revisioni del codice.

Una regola che ha funzionato per noi quando è che il codice condiviso deve essere rivisto in quanto ha un impatto più ampio mentre nel codice per una singola applicazione (specialmente dato che stiamo usando lo sviluppo test driven) è meno importante.