Ho il sospetto che la mia revisione del codice principale si nasconda nella mia squadra. Troppe revisioni del codice vengono unite senza alcun commento.

Mi sembra che non esista una revisione del codice senza un singolo commento.

Come posso condurre un team come responsabile per monitorare adeguatamente che il mio team stia eseguendo un corretto processo di revisione del codice e come posso aiutarli a massimizzare i benefici del processo?

Aggiornare

Pensato che le persone potrebbero voler sapere di qualsiasi aggiornamento. Ho provato molti suggerimenti che sono stati dati qui. la maggior parte era già in uso. alcuni mi hanno aiutato un po '. Tuttavia, il problema è rimasto: alcune persone hanno ricevuto continuamente codice errato quando non stavo guardando.

Ho scoperto che il monitoraggio della revisione del codice non è utile quanto fornire agli strumenti del mio team per rendere il loro codice migliore per cominciare.

Quindi ho aggiunto una libreria denominata "jscpd" per rilevare le paste di copia. La compilazione non è riuscita sulle paste di copia. Ciò ha eliminato immediatamente un problema.

poi proveremo codeclimate.

Sto anche facendo una revisione manuale delle vecchie revisioni del codice una volta uno sprint per mezza giornata. Sto convertendo todoi messaggi in numeri / biglietti - come ho scoperto, le persone li scrivono, ma non verranno mai gestiti in un secondo momento. Sto anche facendo incontri con l'intero team per rivedere il codice quando è appropriato.

in generale sembra che ci stiamo muovendo nella giusta direzione.

Offrirò un approccio diverso dai miei compagni di risposta. Hanno ragione: sii coinvolto 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 il tuo team potrebbe ritenere che il processo sia interrotto / stupido / inefficace per la maggior parte dei commit? Ricorda, il processo sta documentando ciò che funziona bene, non le regole a cui obbedire . E come guida il team, sei lì per aiutarli a essere i migliori, non per far rispettare le regole.

Quindi nelle tue retrospettive (se agili) o uno contro uno (se sei un manager) o in incontri improvvisati casuali in corridoio (se sei un capofila non agile e c'è un altro manager che fa uno su quelli), tiralo su . Chiedi cosa pensano le persone del processo di revisione del codice. Come funziona? Come non è? Di 'che pensi che forse non giova alla squadra il più possibile. Assicurati di ascoltare .

Puoi fare un po 'di sostegno per le revisioni del codice in questi incontri, ma è meglio ascoltare il feedback. Molto probabilmente, scoprirai che o il tuo team pensa che il processo "corretto" debba essere modificato, o che ci sia una causa alla radice (pressione del tempo, mancanza di revisori, Bob si impegna semplicemente a scrivere il suo codice, quindi perché non possiamo)? .

Forzare uno strumento sopra un processo interrotto non migliorerà il processo.

Non mi piace pubblicare risposte di una riga, ma questa sembra appropriata:

Partecipa al processo.

Ottieni uno strumento, come ReviewBoard o il plugin codereview di Redmine . Quindi ogni recensione viene creata come attività che deve essere chiusa o commentata da qualcuno (proprio come un ticket bug). Quindi hai la tracciabilità di chi ha creato il ticket di revisione e di chi lo ha chiuso. È possibile associare i ticket di revisione ai check-in del codice sorgente, ovvero creare il ticket da una revisione.

Alcune cose (a dire il vero, la maggior parte di queste sono coperte attraverso le risposte, ma volevo metterle in un unico posto)

• Puoi mettere in atto processi e regole per assicurarti che avvenga una revisione del codice, ma è abbastanza impossibile inserirli in modo che la revisione del codice sia in realtà più di un esercizio di ticking. Alla fine, il team deve vedere i vantaggi del processo, se vuole affrontarlo utilmente

• Dare l'esempio. Partecipa alle recensioni. Come sviluppatore, mi sento male se il mio manager (un non-sviluppatore ora) individua cose che non conosco. Evidenzia i problemi che avrebbero dovuto essere presi in esame (in modo non biasimevole). Se si verifica un problema di produzione, se si verificano problemi durante il QA (se si dispone di un processo di QA separato), evidenziare dove potrebbero essere stati individuati nella revisione del codice. Discutere con il team su come possiamo garantire che problemi futuri del genere vengano colti

• Discutere con il team su cosa vogliono fare. Se non vedono alcun punto (come può accadere all'inizio), utilizzare le problematiche di produzione e le necessarie correzioni come prova del suo beneficio

• Utilizzare software di controllo del codice automatizzato come Sonarqube in modo che le revisioni del codice possano concentrarsi su problemi come codice incomprensibile, errori logici, mancanza di documentazione, ecc. Che non possono essere individuati automaticamente.

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

• Verifica che il codice faccia quello che dovrebbe fare, ovvero soddisfa i requisiti

• Stile di codice per garantire che gli sviluppatori stiano programmando uno stile coerente

• Ottimizzazione, ad es. Numero di chiamate di funzione

• Architettura e riusabilità

• Gestione e registrazione delle eccezioni

• Debito tecnico: il codice è in uno stato migliore rispetto a quando lo sviluppatore ha iniziato a lavorarci

• Dai un'occhiata e crea il codice (lo trovo utile ma altri sviluppatori nel mio team preferiscono lasciare questo ai tester)

• Usando uno strumento automatizzato (ho usato SonarQube ). Trovo utile integrarlo nel processo di compilazione per applicare miglioramenti al codice, ad esempio aumentando la copertura del test

Alcuni dei passaggi precedenti possono essere coperti da uno strumento automatico, ma mentre stai cercando di migliorare il modo in cui le revisioni del codice o sono state fatte, probabilmente vale la pena usare sia lo strumento che la revisione del bulbo oculare. Tuttavia, i passi 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 unire i diritti. Ad esempio, potresti voler iniziare con lo sviluppatore principale della squadra. Il compromesso con questo approccio è che quegli sviluppatori potrebbero diventare un collo di bottiglia nel processo di sviluppo, quindi tu e il team dovete decidere se lo desiderate. Personalmente accetterei questo compromesso e attraverso le revisioni del codice aumenterei la disciplina in tutto il resto del team e quindi, quando sarà pronto, potrai aumentare il numero di sviluppatori con diritti di unione.

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

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

Prima di tutto, lascia che ti faccia una domanda. Stai utilizzando un sistema di controllo della versione (ad esempio Mercurial, Git)?

Se la tua risposta è sì, procedi.

1. vietare a tutti di spingere qualsiasi cosa (anche piccole correzioni) direttamente nel ramo principale (trunk) *
2. sviluppare nuove funzionalità (o correzioni) in rami separati
3. quando gli sviluppatori ritengono che il ramo sia pronto per essere integrato nel master, creeranno una "richiesta pull"
4. vietare a tutti di unire la propria richiesta pull *
5. chiedi a un altro sviluppatore di valutare la richiesta pull e rivedere il nuovo codice
6. se il codice passa la revisione, bene, la richiesta pull può essere unita, altrimenti possono essere applicate delle correzioni
7. ripetere il passaggio 6 fino a quando il codice ha maturato abbastanza (può essere fatto senza ricominciare da capo) **
8. fatto, tutto il tuo nuovo codice viene rivisto (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 hook sul lato server

** questa procedura è pienamente supportata da GitHub (tra gli altri) ed è abbastanza facile da usare, dai un'occhiata

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 allora, dovresti partecipare inizialmente al processo di revisione.