Chiedere a TUTTI gli sviluppatori di fare recensioni di codice

13

Sono uno sviluppatore software in un team di sviluppatori 7-8. Facciamo revisioni del codice da un po 'di tempo e la qualità del codice è migliorata nel tempo.

Tuttavia, di recente ho notato che ad alcuni sviluppatori viene chiesto più revisioni del codice rispetto ad altri. Temo che sia a causa del loro atteggiamento flessibile.

Dal mio punto di vista, non è così che dovrebbero essere fatte le revisioni del codice: tutto il team dovrebbe essere responsabile e i revisori del codice non dovrebbero essere scelti per la loro disponibilità ad accettare facilmente le modifiche.

Come gestisci questo problema nel tuo team?

Hai stabilito regole per la scelta dei revisori del codice?

Pensi che i revisori dei codici dovrebbero essere ricompensati per il tempo che dedicano a fare (buone) revisioni del codice? E come dovrebbero essere premiati?

Grazie per le tue risposte / idee.

code-quality code-reviews software-craftsmanship

— guillaumegallois
fonte

7

Hai preso in considerazione la creazione di un sistema round robin in cui sia il programmatore sia al buio su chi sta rivedendo e il revisore sia al buio su chi è il programmatore?

— Neil,

1

Non l'ho fatto, ma mi piace questa idea! Grazie!

— Guillaumegallois,

1

Chi è il responsabile e perché non fanno il loro lavoro, il che dovrebbe comportare la garanzia che tutti gli altri facciano il loro?

— JeffO,

Nel mio team, i revisori vengono assegnati automaticamente ogni volta che viene aperta una richiesta pull. I revisori vengono selezionati dal round robin del team. Abbiamo un webhook per ciascuno dei nostri repository che assegna i revisori automaticamente ogni volta che viene aperto il PR. In pratica mantiene un elenco di tutti gli sviluppatori e chi è stato assegnato l'ultima volta, e si fa strada attraverso l'elenco.

— Dan Jones,

12

Non scegliamo revisori.

Nel nostro team:

Tutte le modifiche al codice devono essere riviste prima di completare la richiesta pull
Almeno uno sviluppatore deve rivedere il codice (due o più revisori sono migliori e avere anche tester, analisti e altri membri del team che eseguono la revisione del codice è estremamente utile)

Le recensioni di codice non vengono assegnate, le persone le raccolgono quando funziona per loro. La comprensione è 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".

— Liath
fonte

6

Introdurre una regola in base alla quale un bug può essere assegnato per la correzione, non solo per coloro che hanno eseguito la modifica, ma solo per coloro che lo hanno esaminato. Ciò dovrebbe creare una prospettiva corretta per la revisione del codice.

Quanto a,

Pensi che i revisori dei codici dovrebbero essere ricompensati per il tempo che dedicano a fare (buone) revisioni del codice?

Beh, non sono sicuro di come in genere gli sviluppatori vengano premiati per aver fatto il loro lavoro, tranne per il fatto di ottenere uno stipendio e di essere orgogliosi di ciò che hanno fatto. Ma poiché la revisione del codice fa parte del loro lavoro, il revisore dovrebbe avere tempo per la revisione e condividere il credito in qualche modo.

— max630
fonte

2

È un'idea interessante, ma molte volte quando si presenta un bug, il 90% del lavoro sta immaginando esattamente cosa sta causando il bug e il 10% del lavoro lo sta risolvendo. Fare un post-mortem per capire esattamente quale cambiamento ha introdotto il bug potrebbe anche non accadere, a meno che non aiuti a capire cosa sta succedendo o come fare una soluzione sicura.

— DaveG,

Hai sottolineato il merito che dovrebbe essere dato ai revisori del codice. Questo è sicuramente un problema che dovrebbe essere affrontato. Grazie per la tua risposta!

— Guillaumegallois,

Penso che potrebbe indurre le persone a provare a non fare affatto revisioni del codice o potrebbe essere che non avrai alcun lavoro fatto perché le persone inizieranno a fare il nitpicking.

— Mateusz,

5

Questa risposta presuppone che l'obiettivo delle revisioni del codice sia trovare bug. Non è questo il caso, l'obiettivo principale è quello di mantenere il codice in uno stato mantenibile ed evolutivo (e se sei fortunato, vengono trovati anche alcuni bug).

— Doc Brown,

@DocBrown per prevenire i bug e anche per assicurarsi che la correzione futura del bug sia più veloce (sia familiarizzando l'altro sviluppatore con il codice sia assicurandosi che il codice sia ben scritto)

— max630

4

Il problema principale che hai non è tecnico, ma alcuni strumenti possono ridurre lo sforzo richiesto dalle revisioni del codice. Ci sono alcune sfide da superare:

Capire qual è il cambiamento. Le richieste di Git Pull sui rami delle funzionalità aiutano davvero questo processo.
Trasformare il codice in 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 verificarsi quando il peer è pronto.
La capacità di fornire un feedback significativo quando si guarda il codice. Ad essere onesti, le funzionalità di commento riga per riga in GitHub, GitLab, richieste di pull di Bitbucket sono davvero più utili di una riunione faccia a faccia. Sembra meno politico.

Questo non vuol dire che non puoi usare SubVersion o altri strumenti (come Fisheye) per aiutare, ma l'integrazione integrata nella pipeline Git con i rami delle caratteristiche rende il lavoro meno faticoso.

Al di fuori degli strumenti, è necessario esaminare più sfide sociali:

Chiedi ai tuoi sviluppatori di iniziare la giornata esaminando tutte le richieste di pull aperte per firmare.
Chiedi ai tuoi sviluppatori di esaminare eventuali richieste pull aperte prima di iniziare una nuova attività
Richiedi l'approvazione di più di una persona per le tue richieste pull.

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

— Berin Loritsch
fonte

L'ultimo punto è buono. Una volta ho lavorato con uno sviluppatore in un piccolo team che avrebbe sempre e solo rivisto le modifiche al software che aveva scritto che causavano notevoli colli di bottiglia in altre parti del team.

— Robbie Dee,

In tal caso, sembra che tu abbia qualcuno che cerca di proteggere il proprio "territorio". Per quanto possibile, si desidera promuovere un senso di proprietà della comunità per il codice. In altre parole, non ci sono santuari protetti all'interno del codice che nessun altro sviluppatore, tranne i "beati", può toccare. Capisco se esiste un divario di specialità e non è possibile rivedere la matematica, ma si può almeno rivedere quanto bene il codice corrisponde al suo intento.

— Berin Loritsch,

2

Una buona idea è 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 più o meno un numero uguale di recensioni. Diffonde anche la conoscenza.

Ovviamente ci saranno eccezioni occasionali come le vacanze dove ci saranno picchi e depressioni.

Non ci dovrebbe essere distinzione tra juniores e senior / lead. Le revisioni del codice devono essere eseguite per il codice di tutti, indipendentemente dalla loro senior. Riduce l'attrito e aiuta a condividere diversi approcci.

Se dopo tutto ciò ti preoccupi ancora della qualità delle recensioni, considera di introdurre una serie di standard minimi per il superamento di una revisione del codice. Ciò che includi dipende interamente da te, ma alcune cose che potresti voler considerare sono la copertura del codice, i test unitari, la rimozione del codice commentato, le metriche, i commenti sufficienti, la qualità costruttiva, i principi SOLID, DRY, KISS ecc.

Per quanto riguarda l'incentivazione delle revisioni del codice, il codice di qualità è la ricompensa. Abbiamo sicuramente lavorato su basi di codice non ottimali in cui il dolore avrebbe potuto essere notevolmente ridotto se un altro sviluppatore avesse appena dato il codice una volta dall'inizio e suggerito cambiamenti costruttivi.

— Robbie Dee
fonte

0

Sembra che al team manchi un processo formale per la revisione 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:

Definire un set principale di revisori. Nessuna dichiarazione generale. Nomina le persone.

Questi dovrebbero essere i tuoi sviluppatori senior.
Richiede più di 1 revisore principale per firmare la recensione.
Identifica almeno 1 altro revisore non core per ogni sprint o release che è un revisore core temporaneo. Richiede la firma su tutte le revisioni del codice durante questo periodo.

L'articolo n. 3 consente agli altri sviluppatori di ruotare all'interno del gruppo revisore principale. Alcune settimane passeranno più tempo sulle recensioni di altre. È un atto di bilanciamento.

Per quanto riguarda le persone gratificanti? Molte volte riconoscendo lo sforzo che una persona sta facendo durante la revisione del codice di fronte a tutto il team può funzionare, ma non stressarti.

In caso di dubbio, definire il processo e dire al team che devono attenersi ad esso.

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

Lascia che il team fallisca, perché il processo di revisione del codice non viene seguito. Il management verrà coinvolto e le persone cambieranno. Questa è davvero solo una buona idea nei casi più estremi in cui hai già definito un processo e il team ha rifiutato di seguirlo. Se non hai l'autorità per licenziare le persone o disciplinarle (come la maggior parte degli sviluppatori principali non ha ), allora devi coinvolgere qualcuno che può 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 l'hamburger.

A volte devi solo lasciare che il Titanic colpisca l'hamburger del ghiaccio.

— Greg Burghardt
fonte