Ottenere TUTTI gli sviluppatori fanno revisioni del codice

Non scegliamo i revisori.

Nel nostro team:

• Tutte le modifiche al codice devono essere esaminate dal codice prima che la richiesta di pull sia completata
• Almeno uno sviluppatore deve eseguire la revisione del codice (due o più revisori sono migliori e avere anche tester, analisti e altri membri del team che eseguono la revisione del codice è estremamente vantaggioso)

Le recensioni dei codici non sono assegnate, le persone le raccolgono quando funziona per loro. L'intesa è che non possiamo spingere storie attraverso la pipeline. A volte qualcuno menzionerà che stanno aspettando un CR in stand-up, ma questo è tutto.

Mi piace questo modello, dà alle persone la possibilità di raccogliere ciò che possono ed evita di "dare lavoro alle persone".

Introdurre una regola in base alla quale è possibile assegnare un bug per la correzione, non solo a coloro che hanno commesso il cambiamento, ma solo a coloro che lo hanno revisionato. Questo dovrebbe creare una prospettiva corretta per la revisione del codice.

Per quanto riguarda,

Do you think code reviewers should be rewarded for the time they spend doing (good) code reviews?

Beh, non sono sicuro di quanto generalmente gli sviluppatori siano ricompensati per aver fatto il loro lavoro tranne che per ottenere uno stipendio ed essere fieri di ciò che hanno fatto. Ma poiché il codice di revisione fa parte del loro lavoro, il revisore dovrebbe ottenere il tempo per la revisione e condividere il credito in qualche modo.

Il problema principale che hai non è tecnico, ma alcuni strumenti possono ridurre la quantità di sforzi richiesti dalle revisioni del codice. Ci sono alcune sfide da superare:

• Capire cos'è il cambiamento. Le richieste di pull Git sui rami di funzionalità aiutano davvero questo processo.
• Rendere la revisione del codice un evento in cui le persone devono trovarsi nella stessa stanza. Ciò aggiunge lo stress della pianificazione, della riunione delle risorse, ecc. GitHub, GitLab e BitBucket consentono revisioni asincrone in modo che possano accadere quando il peer è pronto.
• La capacità di fornire un feedback significativo quando si guarda al codice. Per essere onesti, la funzione di commento line-by-line in GitHub, GitLab, le richieste pull di Bitbucket sono davvero più utili di una riunione faccia a faccia. Sembra meno politico.

Questo non vuol dire che non si possa usare SubVersion o altri strumenti (come Fisheye) per aiutare, ma l'integrazione incorporata nella pipeline di Git con i branch delle feature rende davvero il lavoro meno complicato.

Al di fuori degli strumenti, devi guardare ad altre sfide sociali:

• Fai in modo che i tuoi sviluppatori inizino la giornata esaminando eventuali richieste di pull aperte da firmare.
• Chiedi ai tuoi sviluppatori di esaminare eventuali richieste di pull aperte prima di iniziare una nuova attività
• Richiedi l'approvazione di più di una persona per le tue richieste di pull.

Potrebbe anche valere la pena controllare quali tipi di attività vengono esaminate dal codice da parte delle persone più coinvolte. Potrebbero afferrare tutte le recensioni facili, il che rende le cose più dolorose per tutti gli altri.

Una buona idea è quella di farlo su base round robin: scegli qualcuno che ha fatto il minor numero di recensioni per il tuo codice. Nel corso del tempo, tutti i membri del team avrebbero dovuto fare all'incirca un numero uguale di recensioni. Si diffonde anche la conoscenza.

Ovviamente ci saranno eccezioni occasionali come le vacanze in cui ci saranno picchi e avvallamenti.

Non dovrebbe esserci alcuna distinzione tra junior e senior / lead. Le revisioni del codice dovrebbero essere eseguite per il codice di tutti, indipendentemente dalla loro anzianità. Riduce l'attrito e aiuta a condividere approcci diversi.

Se dopo tutto ci si preoccupa ancora della qualità delle recensioni, si consideri l'introduzione di una serie di standard minimi per il passaggio di una revisione del codice. Ciò che includi dipende interamente da te, ma alcune cose che potresti prendere in considerazione sono la copertura del codice, i test unitari, la rimozione del codice commentato, le metriche, i commenti sufficienti, la qualità di costruzione, i principi SOLIDI, SECCO, BACIO ecc.

Per incentivare le recensioni del codice, il codice di qualità è il premio. Abbiamo lavorato tutti su basi di codice sub-ottimali in cui il dolore avrebbe potuto essere ridotto considerevolmente se un altro sviluppatore avesse dato il codice una volta fin dall'inizio e suggerito modifiche costruttive.

Sembra che alla squadra manchi un processo formale per le revisioni del codice.

Non sto parlando di creare un documento Word di 350 pagine, ma solo alcuni semplici punti elenco su ciò che il processo comporta.

I bit importanti:

1. Definire un nucleo di revisori. Nessuna dichiarazione generale Assegna un nome alle persone.

   Questi dovrebbero essere i tuoi sviluppatori senior.

2. Richiede più di 1 revisore del nucleo a firmare la recensione.

3. Identifica almeno un altro revisore non principale per ogni sprint o release che è un revisore nucleo temporaneo. Richiedere l'approvazione per tutte le revisioni del codice durante questo periodo.

L'elemento n. 3 consente agli altri sviluppatori di ruotare all'interno del gruppo di revisori nucleo. Alcune settimane passeranno più tempo sulle recensioni di altri. È un atto di bilanciamento.

Come ricompensare le persone? Molte volte riconoscere lo sforzo che una persona sta compiendo durante la revisione del codice di fronte a tutto il team può funzionare, ma non stressarti su questo.

In caso di dubbio, definisci il processo e comunica al team di cui hanno bisogno per attenervisi.

E c'è un'ultima cosa che puoi provare - per quanto possa essere controverso: lascia che il @ # $% colpisca il fan, se posso usare un idioma.

Lascia che il team fallisca, perché il processo di revisione del codice non viene seguito. La gestione sarà coinvolta, e quindi le persone cambieranno. Questa è davvero solo una buona idea nei casi più estremi in cui hai già definito un processo e il team si è rifiutato di rispettarlo. Se non hai l'autorità per licenziare o disciplinare le persone (come la maggior parte degli sviluppatori leader non ), devi coinvolgere qualcuno che possa fare queste cose.

E non c'è niente come l'incapacità di far cambiare le cose. Nonostante ciò che la gente potrebbe dire, puoi guidare il Titanic - ma non prima che colpisca il ghiaccio.

A volte devi solo lasciare che il Titanic colpisca il ghiaccio.