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

Attualmente sto lavorando come senior dev con 3 junior sotto di me e ho introdotto un processo di revisione del codice per aiutare a gestire la qualità del codice in produzione.

Ritengo sia molto utile per tutti noi rivedere a vicenda il lavoro, tuttavia dopo circa 5 settimane di processo sono l'unico a fare commenti nello strumento (BitBucket).

Penso che ci siano alcune questioni culturali in atto, e forse una naturale riluttanza nel caso in cui i loro commenti siano sbagliati, ma c'è un modo e posso aiutare gli junior a sentirsi più a loro agio nel criticare il mio e gli altri funzionano?

Per me, la domanda qui è "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 osservando ciò che si spera sia un buon codice; se riscontrano problemi anche nel tuo codice, è un vantaggio.

Se stai cercando il tuo staff junior per imparare dalle recensioni del codice, la cosa più importante che devi fare è creare un ambiente in cui l'apprendimento è valutato e non visto come una perdita di tempo. Ciò significa una serie di cose:

• Non esiste una domanda stupida . Se qualcuno non capisce un po 'di codice, perché hai usato un certo schema o altro, devono sentirsi liberi di chiedere, senza mai farsi sentire che stanno sprecando il tuo tempo o quello degli altri sviluppatori .
• Il tempo dedicato all'apprendimento è tempo ben speso . Volete che i vostri sviluppatori junior trascorrano del tempo guardando il codice e imparando da esso, perché in futuro li renderà il personale migliore e più produttivo. A meno che non sia una correzione critica che deve essere rivista ora , incoraggiali a dedicare più tempo, piuttosto che meno, alle recensioni del codice.
• Il personale senior non ha sempre ragione . Solo perché lo fai da più tempo non significa che hai ragione. Se pensano di aver trovato un bug, probabilmente hanno ragione. Se pensano che un altro modello di progettazione sia appropriato per questo bit di codice, devono sentirsi liberi di dirlo senza ricevere feedback negativi.

Avere riunioni di revisione del codice di persona all'ora stabilita ogni settimana. L'ho venduto al mio compagno di squadra in questo modo (in realtà siamo entrambi sviluppatori senior, ma comunque):

"La recensione del codice è parzialmente lì per me per conoscere un po 'meglio il tuo codice e sapere cosa sta succedendo nel tuo lato delle cose nel caso in cui un giorno verrai colpito da un camion e mi viene ordinato di finire lo sprint. Ma soprattutto è lì per te per spiegare il tuo codice a qualcun altro, perché quando lo fai, coinvolge una parte diversa del tuo cervello, e spesso volte la tua spiegazione a loro, e / o le loro domande o commenti, potrebbero farti ricordare qualcosa che hai dimenticato nel codice o potrebbe farti capire un modo migliore per renderlo più leggibile o progettarlo meglio. Ciò porta a un codice più bello ".

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

Tuttavia, penso che usare strumenti di revisione del codice in cui non vi siano interazioni umane, riunioni in una stanza, nessuna lavagna .. diventa solo un'altra "cosa" fastidiosa da fare. Non è che non dovrebbero esserci 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 aiutare dando un buon esempio. Non puoi essere difensivo quando qualcuno segnala i tuoi errori. Fai 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 avrà un pestaggio per avere un bug nel loro codice.

Avere un lavoro significa assumersi la responsabilità e l'orgoglio nel proprio lavoro. Se la revisione del codice fa parte di questo, la partecipazione alla revisione del codice dovrebbe essere inclusa nelle valutazioni. Ho preso lezioni online in cui la partecipazione alle 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 in base a numeri di vendita, reclami degli utenti o altre valutazioni se si scrive un codice per uso interno. La realtà è che il tuo codice ha qualche scopo e il tuo team dovrebbe essere misurato da quanto bene servono a tale scopo. Coloro che decidi contribuiscono al successo, condividono proporzionalmente i premi.

Concentrati sul rilascio del codice di qualità. L'obiettivo non è che tutti si sentano bene con se stessi evitando gli insetti. Scrivo codice errato; Devo correggere il codice errato. Questo è lavoro e vita. Odio correggere i bug, quindi cerco di evitarli. Sono orgoglioso del mio lavoro, quindi mi dà fastidio quando il mio codice non funziona. Mi sento male per gli utenti o chiunque altro debba prendere il loro tempo per sottolineare queste cose e questo mi motiva a voler risolverlo.

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 corrette vanno ai test.

Se i test rilevano errori introdotti nella modifica, anche l'autore e il revisore hanno la colpa.

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