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

Guarda come Facebook fa con la propria app, chiamata phabricator: link

In pratica si basano su una base per numero e per ogni problema viene mostrato il codice, che deve essere esaminato da qualcuno. Il codice non entra nel loro repository principale fino a quando il revisore non ha detto che è giusto farlo.

Immagino che lo renda più divertente.

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

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

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

Di solito rimuovevo alcune parti minori, come le parentesi di blocco / funzione, le notazioni di visibilità, a volte persino i tipi, e lo mostravo a manager, esperti di dominio, compagni, chiunque richiedesse il codice: "è questo che vuoi?"

Inoltre, andare lì personalmente e non partire fino a quando la revisione non è stata completata aiuta

Oppure, nel caso in cui non stia bene con il team, o non stia bene con te, sai, "se puoi 'cambiare la compagnia, cambia compagnia" ...

Baserò questo su un paio di ipotesi:

1. Tutti sembrano voler scrivere codice (se no, hai persone che devono andare.).
2. Tutti vogliono che il proprio codice venga archiviato.

Consenti solo a coloro che completano le recensioni di avere il proprio codice archiviato.

Forse un certo periodo 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 fino al punto in cui tutti gli danno solo un'omologazione "timbro di gomma".

Se hai livelli diversi (jr., sr. ecc.), la promozione e il mantenimento di un titolo dovrebbero essere subordinati all'esecuzione del tuo lavoro.

A un paio di precedenti datori di lavoro, abbiamo fatto ruotare chi era su Code Review su base giornaliera. Di solito 3 persone hanno condiviso un giorno di CR e ogni CR ha dovuto essere firmato da due dei revisori. Questo ha fatto in modo che quando era il tuo giorno, sapevi che CR ti aspettavi da te, indipendentemente dai tuoi altri progetti. Quindi ogni cinque giorni circa, era il tuo turno e potevi adattare le tue attività di sviluppo di conseguenza.

Al momento, abbiamo un caposquadra che fa un CR affrettato sul codice della squadra. A seconda di quale area dell'applicazione è stata aggiornata, dopo che il CR è stato completato, può essere sottoposto al team di revisione globale, dove controlliamo le cose che hanno un impatto globale sulle applicazioni, invece di cose che sono relativo a una singola funzione. Quando c'è una grande recensione da fare, solitamente la suddividiamo tra poche persone in modo che nessuna persona debba gestire le modifiche attraverso un numero ridicolo di file.

Detto questo, stiamo sempre rivedendo il codice che è stato impegnato nell'attuale dev branch / variante. Il codice deve passare Code Review, Global Review, DB Review e UI Review (ciascuno secondo necessità) prima che possa essere promosso all'ambiente successivo (ad esempio Alpha).

Infine, accettiamo un SLA su quanto velocemente le recensioni vengono girate. Quasi niente è in coda per più di 48 ore e la maggior parte delle recensioni viene eseguita in meno di 24 ore.

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 la più semplice - tu accetti (collettivamente e che deve includere la gestione) che la prima cosa che un dev fa ogni mattina è la revisione del codice - questo è semplice, comprensibile, efficace e ti dà una bella chiavetta per battere le persone 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 se avessero valore altrimenti non faranno mai una revisione del codice (che è percepita come non avere valore) quando potrebbero scrivere codice o fissare bug (che è sicuramente più importante ...?).

Se riesci a mettere insieme le due cose - in primo luogo assicurando che tutti credano (o comprendano) che ci sia un valore nelle revisioni del codice - nella maggior parte dei casi dovrebbe significare meno bug che significano più codice nuovo che di solito è più divertente - e poi sistemando le cose in modo che ci sia uno spazio chiaro nel programma per le revisioni del codice, speriamo che succedano cose buone ... diventerà parte della cultura.

Una volta che è parte della cultura, potrebbe non essere più necessario dire "prima cosa ogni giorno" - ma avendo detto che penso che si adatti bene al pattern, probabilmente uno dev deva lavorare.

The company I work for requires all code to be reviewed by other developers before it is committed. The members of my team are often frustrated...

A meno che non si stiano facendo software mission critical o patch critiche per il codice candidato alla release di produzione, non ci sono motivi validi per attenersi rigidamente a particolari tipi di revisioni del codice.

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

Camminando nei tuoi panni, vorrei innanzitutto segnalare alla dirigenza che le recensioni di codice post-commit sono considerate ugualmente rispettabili come pre-commit . Questi termini sono ricercabili sul Web - se necessario, trovare i riferimenti per eseguire il backup di questo. Uno non ha necessariamente bisogno di pre-commit recensioni per ottenere il codice revisionato al 100%.

In base a quanto sopra, vorrei suggerirli di abbandonare l'atteggiamento micromanagement e lasciare che gli sviluppatori prova il modo in cui ti sembra più conveniente. Le recensioni precedenti o successive al commit sono le migliori per i programmatori da scegliere. Se la società conosce meglio dei programmatori, perché non scrive loro stessi il codice?

Considera l'utilizzo di uno strumento come Review Board . È molto utile, specialmente per le revisioni lunghe.

Puoi caricare le tue diff e aspettare fino a quando un revisore ha terminato la loro revisione. Se hai recensioni aperte che ti impediscono di continuare il tuo lavoro, puoi segnalarlo durante le riunioni giornaliere (il tuo team vuole che le nuove funzionalità vengano verificate in modo che possano essere testate il prima possibile, vero?)

Alla 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 influisce sulla tua valutazione della performance. E sì, le recensioni sembrano sempre accadere nei momenti più inopportuni. Peccato, impara a includere il tempo di revisione nelle tue stime. Ad ogni modo, se la direzione crede veramente che le recensioni siano importanti (cioè impongono che tutto il codice venga revisionato), allora spingono una politica simile. Inoltre, se le persone non completano la revisione nel tempo assegnato, ciò vale come accettazione del materiale.

Alcuni punti da aggiungere che non sono nelle altre risposte.

Il codice da rivedere deve essere controllato

• in modo che tu stia rivedendo una versione stabile.
• Può trovarsi sul ramo di sviluppo principale se una versione è sufficientemente lontana
• Può essere sul ramo se c'è una buona ragione per non inquinare il principale

Le attività di blocco hanno la priorità, pertanto le revisioni del codice dovrebbero avere la priorità su altri lavori (ma cercare di non interrompere il flusso). Come sviluppatore, dovresti chiedere ad altri di rivedere il tuo codice (perché stai cercando di renderlo migliore). In quella conoscenza, dovresti eseguire prontamente le recensioni per gli altri.

Le domande più difficili sono quando e come eseguire correttamente le revisioni del codice.

Una regola che ha funzionato per noi sul momento in cui quel 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 basato su test) è meno importante.