Come incoraggiare gli sviluppatori junior a partecipare alla revisione del codice?

Per me, la domanda qui è "che cosa stai cercando i tuoi sviluppatori junior per uscire dalle recensioni del codice?". Per me, potenzialmente la cosa più importante è che gli sviluppatori junior imparino guardando quello che è sperabilmente un buon codice; se capita di trovare problemi nel codice, questo è un bonus.

Se stai cercando il tuo personale junior per imparare dalle recensioni del codice, la cosa più importante che devi fare è creare un ambiente in cui l'apprendimento sia apprezzato e non visto come una perdita di tempo. Questo significa un certo numero di cose:

• Non esiste una domanda stupida . Se qualcuno non capisce un po 'di codice, perché hai usato un determinato schema o qualsiasi altra cosa, hanno bisogno di sentirsi liberi di chiedere, senza mai essere fatti sentire che stanno sprecando il tuo tempo o quello degli altri sviluppatori .
• Il tempo dedicato all'apprendimento è il tempo speso bene . vuoi i tuoi sviluppatori junior di dedicare del tempo a guardare il codice e imparare da esso, perché renderà loro uno staff migliore e più produttivo in futuro. A meno che non si tratti di una correzione critica che deve essere rivista ora , incoraggiali a dedicare più tempo, piuttosto che meno, alle revisioni del codice.
• Il personale senior non ha sempre ragione . Solo perché lo hai fatto più a lungo non significa che tu abbia ragione. Se pensano di aver trovato un bug, probabilmente hanno ragione. Se pensano che un altro modello di progettazione sarebbe appropriato per questo bit di codice, allora hanno bisogno di sentirsi liberi di dirlo senza ottenere un feedback negativo.

Fai riunioni di revisione del codice di persona al tempo stabilito ogni settimana. Ho venduto questo al mio compagno di squadra in questo modo (siamo in realtà entrambi gli sviluppatori senior, ma qualunque cosa):

"La revisione del codice è parzialmente lì per farmi conoscere meglio il tuo codice e sapere cosa sta succedendo nel tuo lato delle cose nel caso in cui un giorno venga investito da un camion e mi viene ordinato di finire lo sprint. Ma principalmente è lì per te a spiegare il tuo codice a qualcun altro, perché quando lo fai, coinvolge una parte diversa del tuo cervello, e spesso la tua spiegazione per loro, e / o le loro domande o commenti, potrebbe farti ricordare qualcosa che hai dimenticato di fare nel codice, o potresti farti realizzare un modo migliore per renderlo più leggibile o meglio configurarlo, il che porta a un codice più bello. "

Mi piace pensarlo come un gioco di parole. Le persone possono mostrare il loro lavoro ai loro coetanei. Non si tratta dei tuoi pari che trovano cose sbagliate nel tuo lavoro, a cui a nessuno piace la sensazione. Si tratta di impressionare i tuoi coetanei con il tuo codice fantastico, che a tutti piace.

Comunque penso che usare strumenti di revisione del codice in cui non ci sia interazione umana, nessuna riunione in una stanza, nessuna lavagna ... diventa solo un'altra fastidiosa "cosa" da fare. Non è che non ci dovrebbero essere tali strumenti, ma dovrebbero essere qualcosa a cui ricorrere se, durante la riunione di revisione del codice, si è reso conto che potrebbe essere necessaria una revisione più approfondita di una determinata sezione di codice. Quindi potresti assegnare uno degli sviluppatori junior per rivedere il codice dell'altro su una determinata area.

Puoi aiutarti dando il buon esempio. Non puoi metterti sulla difensiva quando qualcuno indica i tuoi errori. Esegui una revisione del codice sul tuo codice e nota le aree di miglioramento. Condividi questo con il team. Alla fine, impareranno che questo è incoraggiato e nessuno ha intenzione di ottenere un pestaggio per avere un bug nel loro codice.

Avere un lavoro significa assumersi responsabilità e orgoglio nel proprio lavoro. Se la revisione del codice è parte di ciò, la partecipazione alla revisione del codice dovrebbe essere inclusa nelle valutazioni. Ho preso lezioni online in cui la partecipazione a discussioni online fa parte del voto. I commenti devono essere elaborati. "Sono d'accordo" non è accettabile.

La revisione del codice dovrebbe migliorare il codice. A seconda della situazione, potrebbe essere misurato dai numeri di vendita, dai reclami degli utenti o da qualche altra valutazione se si scrive codice per uso interno. La realtà è che il tuo codice ha uno scopo e il tuo team dovrebbe essere misurato dal modo in cui servono a tale scopo. Quelli che determini contribuiscono al successo, arrivano a condividere proporzionalmente i premi.

Concentrati sul rilascio del codice di qualità. L'obiettivo non è che tutti si sentano bene con se stessi evitando i bug. Scrivo codice cattivo; Devo riparare il codice errato. Questo è lavoro e vita. Odio correggere bug, quindi cerco di evitarli. Sono orgoglioso del mio lavoro, quindi mi infastidisce quando il mio codice non funziona. Mi sento in colpa per gli utenti o per chiunque altro debba prendersi il tempo necessario per segnalare queste cose e mi motiva a volerle risolvere.

Come nota a margine, se hai un ambiente in cui nessuno può dare o accettare critiche costruttive, hai un problema.

Il processo: qualcuno vuole impegnare i suoi cambiamenti. Qualcuno viene assegnato come revisore e rivede le modifiche. Quindi le modifiche riviste e fissate vanno a test.

Se il test rileva errori introdotti nella modifica, anche l'autore e il revisore devono essere ugualmente da biasimare.

Quindi fare una recensione senza commenti ti porterà nei guai a meno che il codice non sia perfetto.