Offrirò una presa diversa dai miei compagni di risposta. Hanno ragione - essere coinvolti se vuoi vedere come vanno le cose. Se vuoi più tracciabilità, ci sono strumenti per questo.

Ma nella mia esperienza, sospetto che ci sia qualcos'altro in corso.

Hai considerato che la tua squadra potrebbe ritenere che il processo sia rotto / stupido / inefficace per la maggior parte dei commit? Ricorda che il processo sta documentando ciò che funziona bene, non le regole per obbedire . E mentre il team è al comando, sei lì per aiutarli a essere i loro migliori, non le regole di rinforzo.

Quindi nelle tue retrospettive (se agile) o una su quelle (se sei un manager) o in riunioni estemporanee casuali (se sei un capo non agile e c'è un altro manager che ne fa uno su uno), portarlo. Chiedi cosa pensa la gente del processo di revisione del codice. Come funziona? Come non è? Dì tu pensi che forse non sta avvantaggiando la squadra quanto potrebbe. Assicurati di ascolta .

Puoi fare un po 'di sostegno per le revisioni del codice in questi incontri, ma è meglio ascoltare il feedback. Molto probabilmente, scoprirai che entrambi i team pensano che il processo "corretto" debba essere aggiustato, o che ci sia una causa (pressione temporale, mancanza di revisori, Bob impegna il suo codice, quindi perché non possiamo) per affrontare .

Forzare uno strumento in cima a un processo rotto non renderà il processo migliore.

Non mi piace pubblicare risposte su una sola riga, ma questo sembra appropriato:

Partecipa al processo.

Ottieni uno strumento, come ReviewBoard o Plugin per il codice di Redmine . Quindi ogni recensione viene creata come un compito che deve essere chiuso o commentato da qualcuno (proprio come un bug ticket). Quindi è possibile rintracciare chi ha creato il ticket di revisione e chi lo ha chiuso. È possibile associare i ticket di revisione ai controlli del codice sorgente, ovvero creare il ticket da una revisione.

Poche cose (ad essere onesti, la maggior parte di queste sono coperte tra le risposte, ma volevo metterle in un unico posto)

• Puoi mettere in atto processi e regole per assicurarti una revisione del codice succede, ma è piuttosto impossibile inserirli in questo modo la revisione del codice è in realtà più di un esercizio di box-ticking. In definitiva il team deve vedere i benefici del processo, se devono avvicinarsi utilmente

• Guida con l'esempio. Partecipa alle recensioni. Come sviluppatore, mi sento male se il mio manager (un non sviluppatore ora) vede cose che non conosco. Evidenzia i problemi che avrebbe dovuto essere preso in esame (in modo non incolpevole). Se si verifica un problema di produzione, se si verificano problemi durante il QA (se tu avere un processo di controllo qualità separato), evidenziare dove avrebbero potuto essere catturato nella revisione del codice. Discutere con il team come può noi possiamo garantire problemi futuri come quello sono presi

• Parla con il team di ciò che vogliono che il processo faccia. Se non lo fanno vedere qualsiasi punto (come può accadere all'inizio) usa il problemi di produzione e refili necessari come prova del suo vantaggio

• Utilizza un software di controllo automatico dei codici come Sonarqube le recensioni di codice possono concentrarsi su problemi come codice incomprensibile, logica errori, mancanza di documentazione, ecc. che non possono essere individuati automaticamente.

Potresti documentare ciò che il team vuole nelle revisioni del codice che hai discusso e concordato con gli sviluppatori. Alcune cose che potresti considerare come parte delle recensioni del codice sono:

• Verifica che il codice faccia ciò che deve fare, ovvero che soddisfi i requisiti

• Stile del codice per garantire che gli sviluppatori stiano codificando per uno stile coerente

• Ottimizzazione ad es. numero di chiamate di funzioni

• Architettura e riusabilità

• Gestione e registrazione delle eccezioni

• Debito tecnico: il codice è migliore di quando lo sviluppatore ha iniziato a lavorarci

• Guarda e costruisci il codice (trovo questo utile ma altri sviluppatori del mio team preferiscono lasciare questo ai tester)

• Utilizzo di uno strumento automatico (ho usato SonarQube ). Trovo utile integrare questo nel processo di creazione per applicare miglioramenti al codice, ad es. aumentando la copertura del test

Alcuni dei passaggi precedenti possono essere coperti da uno strumento automatico, ma mentre stai provando a migliorare il modo in cui le revisioni del codice o sono state fatte, probabilmente vale la pena usare entrambi la recensione di tool e eyeball. Tuttavia, i passaggi più importanti per prevenire il debito tecnico (architettura e riusabilità) non possono essere completamente automatizzati.

Se il tuo team non è coerente nell'applicazione di questo, puoi provare a consentire solo agli sviluppatori che eseguono correttamente le revisioni del codice di avere diritti di fusione. Ad esempio, potresti voler iniziare con lo sviluppo principale della squadra. Il compromesso con questo approccio è che quegli sviluppatori potrebbero diventare un collo di bottiglia nel processo di sviluppo, quindi voi e il team dovete decidere se volete questo. Personalmente accetterò questo trade-off e attraverso le revisioni del codice aumenterò la disciplina nel resto del team e, una volta pronto, potremo aumentare il numero di sviluppatori con diritti di fusione.

Infine, vale la pena rivedere le recensioni. Quindi una volta alla settimana si riuniscono con gli sviluppatori e discutono in modo costruttivo le recensioni e i modi per migliorarle.

Ti dirò in che modo il mio team ha rapidamente integrato la revisione del codice nel suo flusso di lavoro.

Per prima cosa, lascia che ti faccia una domanda. Stai usando un sistema di controllo della versione (ad esempio Mercurial, Git)?

Se la risposta è sì, quindi procedere.

1. proibisci a tutti di inviare qualsiasi cosa (anche piccole correzioni) direttamente al ramo principale (trunk) *
2. sviluppa nuove funzionalità (o correzioni) in rami separati
3. quando gli sviluppatori credono che il ramo sia pronto per essere integrato nel master, creeranno una "richiesta di pull"
4. proibisce a tutti di unire la propria richiesta pull *
5. chiedi a un altro sviluppatore di valutare la richiesta di pull e di rivedere il nuovo codice
6. se il codice supera la recensione, bene, la richiesta pull può essere unita, altrimenti è possibile applicare le correzioni
7. ripeti il passaggio 6 finché il codice non diventa abbastanza maturo (può essere eseguito senza ricominciare) **
8. fatto, tutto il tuo nuovo codice viene revisionato (almeno sommariamente), da qualcuno con un nome

Ora hai un punto preciso nel tuo flusso di lavoro in cui viene eseguita la revisione del codice.

Agisci lì.

* può essere applicato automaticamente, con ganci lato server

** questa procedura è completamente supportata da GitHub (tra gli altri), ed è abbastanza facile da usare, check it out

Penso che dovresti creare un modello e chiedere ai membri del tuo team di aggiornarlo ogni volta che eseguono una revisione del codice. Ma anche in questo caso, dovresti partecipare inizialmente al processo di revisione.