Come gestire qualcuno a cui non piace l'idea delle recensioni di codice?

Ovviamente, se la gestione si impegna a passare del tempo con le revisioni del codice, allora tutti devono farlo.

Ma ci sono sempre quei ragazzi (o ragazze) che resistono con ogni oncia del loro essere.

Come gestite efficacemente la gestione di questo scenario quando vi trattate come peer reviewer?

Resiste a causa della paura . Questo condizionamento può essere il risultato di precedenti esperienze negative sulla revisione, da bambino, a scuola, al lavoro o persino nella tua squadra attuale. Nelle nostre società moderne, è molto comune per noi confondere l'output lavorativo di qualcuno con il suo valore come essere umano. Ecco perché le recensioni sul lavoro non sono ben percepite. Questo è anche il motivo per cui parlare in pubblico in una delle fobie più diffuse (paura del giudizio).

Per evitare tale comportamento, avrai bisogno di un po 'di psicologia. Devi dimostrare al suo cervello di lucertola che non accadrà (non sarà giudicato, umiliato, ucciso, niente ...) desensibilizzandolo alle recensioni dei codici.

Uno dei metodi più efficaci che ho trovato per sbloccare qualcuno è chiedergli di rivedere il tuo codice , prima di chiedere di rivedere il suo codice.

Dopo un po ', proponigli di leggere il suo codice per imparare da esso e perché non suggerire miglioramenti. Quando trovi qualcosa da cambiare, fai attenzione a ciò che scrivi. Capirà che non c'è nulla di cui aver paura e prenderà solo la parte positiva del processo di revisione: l' apprendimento e l'aumento delle sue conoscenze .

Proverei a lavorare in coppia - fare squadra con qualcuno che odia l'idea con qualcuno a cui piace e fare in modo che si rivedano reciprocamente il codice per un paio di settimane. Ovviamente questo può o non può essere d'aiuto, ma essere su entrambe le estremità della recensione darà almeno una visione più arrotondata del processo. Avere una coppia che lavora insieme permetterà loro di acquisire familiarità con lo stile reciproco e gli errori comuni e darà loro il tempo di aiutarsi a vicenda per migliorare, piuttosto che il timbro di gomma. Questo può anche aiutarti a promuovere la programmazione di coppie nel tuo ambiente di lavoro, poiché penso che potresti vedere una crescente tendenza a non solo rivedere, ma ricodificare o persino pianificare e programmare da zero.

Finché le parti disinteressate sono disposte a provare, questo potrebbe aiutare. Se si rifiutano di considerarlo, non c'è molto che puoi fare al riguardo fintanto che sono nella squadra.

@La risposta di Pierre è sulla buona strada per qualcuno che teme una revisione del codice. Posso immaginare un'altra situazione. Un programmatore stellare che sente una revisione del codice è una perdita di tempo perché lì il codice raggiunge uno standard accettabile di qualità e correttezza. In questo caso potrebbero ritenere che una revisione del codice sia una perdita di tempo e una caccia alle streghe. (Questa è una ricerca di un problema quando non esiste nessuno.)

In questo caso, vorrei riorientare l'obiettivo della recensione. Invece che la revisione del codice riguarda la ricerca di "problemi" nel codice, trattalo come una ricerca di obiettivi di factoring o potenziali miglioramenti futuri o funzionalità di progettazione aggiuntive. In questo modo, sia il programmatore che il revisore sono coinvolti nel processo e, si spera, questo programmatore capace si sentirà come se il tempo fosse messo a frutto.

Francamente, questa domanda non ha alcun senso se hai un negozio ben gestito:

1) Se fa parte del lavoro, devi farlo, o sei insubordinato. Qualcuno che rifiuta categoricamente di svolgere una parte del lavoro che deve svolgere dovrebbe essere inscatolato. La programmazione è un mestiere e una professione: revisori e manager sono lì per aiutare a portare a termine il lavoro, non a trattare con bambini viziati (di qualsiasi età).

2) Se hai un sistema di controllo del codice sorgente ben gestito (che è un must in qualsiasi negozio di software professionale), il loro codice può essere rivisto indipendentemente dal fatto che gli piaccia o meno. Quindi rivedi il loro codice:

• Se va bene, avvisali e dai loro una pacca sulla spalla - ciò incoraggerà la partecipazione.

• Se non va bene, faglielo sapere. Ciò dovrebbe avere l'effetto di motivarli a partecipare, al fine di difendersi. In caso contrario, è possibile utilizzare misure punitive: sanzioni pecuniarie, declassamento dello status, ecc. Se, nonostante i tuoi sforzi, questo dipendente non riesce a presentarsi, IMO hai un cattivo dipendente e dovrebbero essere mostrati alla porta.

Hanno esperienze negative in luoghi in cui le revisioni del codice non sono state eseguite correttamente? Potrebbero avere preoccupazioni legittime.

Se non vedono assolutamente alcun merito all'esercizio, chiedi loro di essere pazienti e di vedere cosa succede al loro codice e soprattutto agli altri (se pensano che siano perfetti) come risultato.

Code Review 'dovrebbe' migliorare lo sviluppo, ma fino a quando non si dispone di un sistema che funziona davvero, perché qualcuno dovrebbe voler farlo?

Personalmente, ci sono alcuni combattimenti che non possono essere vinti con il 100% della popolazione.

Riesco a vedere abbastanza motivi per cui la programmazione di coppia non funzionerebbe quando qualcuno è costretto a farlo.

Ma le revisioni del codice sono diverse: cambiano la tua produttività, non necessariamente le tue abitudini di lavoro.

Il management può fare diverse cose per ridurre la resistenza dovuta alla produttività: 1) Accettare la riduzione di velocità per tutti gli sviluppatori. 2) Fornire strumenti adeguati per gestire la gestione e l'unione di più versioni a causa di cicli di revisione (ad esempio, consentire agli sviluppatori di disporre di un repository git locale) 3) Applicare alcune forme di pressione sociale o di altro tipo per garantire la distribuzione del carico, qualità e tempestività di recensioni.

Se lo fanno, è legittimo richiedere a tutti di partecipare, IMHO. La società con cui lavoro ora lo fa a livello globale - semplicemente non puoi presentare senza l'approvazione del proprietario. E mentre questo rallenta le cose, previene molti incidenti.

Abbiamo utilizzato misure tecniche per rendere obbligatoria la revisione del codice.

Il modo in cui abbiamo introdotto la revisione del codice è che nel nostro controllo del codice sorgente è impossibile unire il codice che non è stato firmato da qualcun altro, quindi da quello che lo ha spinto.

Licenziali

È così semplice - o ottengono un progetto solitario, o devono andare. Allontanali dalla tua squadra. Non solo non fanno la loro parte, ma erodono il morale e le pratiche della squadra.

Ora, se sembra che devi licenziare il 50% della tua squadra, allora ...

Capire

Perché alcuni rifiutano? Non hanno tempo? Sono bruciati? Sono recensioni su qualcosa con cui non hanno esperienza? Pensano che sia una perdita di tempo, se sì perché?

La metodologia agile aiuterà qui: presumo che tu lavori costantemente contro i silos (cioè per ridurre il fattore bus) e gli individui del tuo team sono coinvolti in ciò che fanno gli altri.

Lavorare per garantire che le singole richieste di unione siano piuttosto piccole. Se si tratta di più di una schermata di modifiche, ha bisogno di una discussione in piedi o lampo per spiegare cosa viene fatto. Se è di 10 pagine, ha bisogno di una presentazione con diapositive e diagrammi di architettura.

Tutti gli interessati lavorano allo stesso progetto?

Il progetto è già sepolto sotto una montagna di debito tecnico?

Credono nel progetto e nel miglioramento continuo?