Come comportarsi con qualcuno a cui non piace l'idea delle revisioni del codice?

Resiste per paura . Questo conditioning potrebbe essere il risultato di precedenti esperienze negative relative alla recensione, da bambino, a scuola, al lavoro o anche nella tua squadra attuale. Nelle nostre società moderne, è molto comune per noi confondere la produzione di lavoro di qualcuno con il suo valore di essere umano. Questo perché le recensioni sul lavoro non sono ben percepite. Questo è anche il motivo per cui parla in pubblico in una delle fobie più diffuse (paura del giudizio).

Per evitare questo tipo di comportamento, avrai bisogno di un po 'di psicologia. Devi dimostrare al suo cervello della lucertola che non accadrà (non sarà giudicato, umiliato, ucciso, qualsiasi cosa. ..) di desensibilizzando a scrivere recensioni.

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 ', proponi a lui di leggere il suo codice per imparare da esso e perché no suggerire miglioramenti. Quando trovi qualcosa da cambiare, fai attenzione a ciò che scrivi. Capirà che non c'è nulla di cui aver paura, e prenderà la parte positiva del processo di revisione solo: imparando e aumentando le sue conoscenze .

Cercherò di lavorare in coppia - team qualcuno che odia l'idea con qualcuno a cui piace, e chiedere loro di rivedere il codice degli altri per un paio di settimane. Ovviamente questo può o non può essere d'aiuto, ma essere su entrambe le estremità della recensione fornirà almeno una visione più arrotondata del processo. Avere una coppia che lavora insieme permetterà loro di familiarizzare con lo stile e gli errori comuni degli altri e darà loro il tempo di aiutarsi reciprocamente a migliorare, piuttosto che timbrare. Questo può anche aiutarti a promuovere la programmazione delle coppie nel tuo ambiente di lavoro, poiché penso che potresti vedere una crescente tendenza non solo a rivedere, ma anche a ricodificare o addirittura pianificare e codificare da zero.

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

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

In questo caso vorrei riorientare l'obiettivo della recensione. Invece che la revisione del codice riguarda la ricerca di "problemi" nel codice, trattarla come una ricerca di obiettivi di ri-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 che questo programmatore possa sentirsi come se il tempo fosse messo a frutto.

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

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

2) Se disponi di 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 dagli una pacca sulla spalla - così sarà incoraggiare la partecipazione.

• Se non va bene, fagli anche sapere. Questo dovrebbe avere l'effetto di motivandoli a partecipare, per difendersi. Se è così no, puoi usare misure punitive: sanzioni finanziarie, demotions in status, ecc. Se nonostante i vostri sforzi questo dipendente non riesce a venire, IMO hai un cattivo dipendente e dovrebbero essere mostrato la porta.

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

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

La revisione del codice "dovrebbe" migliorare lo sviluppo, ma finché non hai un sistema che funziona davvero, perché qualcuno dovrebbe volerlo fare?

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

Riesco a vedere abbastanza ragioni per cui la programmazione delle coppie non funzionerebbe quando qualcuno è costretto a farlo.

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

La gestione può fare diverse cose per ridurre la resistenza a causa della produttività: 1) Accetta la riduzione della velocità per tutti gli sviluppatori. 2) Fornire strumenti appropriati per gestire la gestione e la fusione di più versioni a causa di cicli di revisione (ad esempio, consentendo agli sviluppatori di disporre di un repository git locale) 3) Applicare qualche forma di pressione sociale o di altro tipo per garantire la distribuzione del carico, la qualità e la tempestività delle recensioni.

Se lo fanno, è legittimo richiedere a tutti di partecipare, IMHO. La società che ora collaboro per le forze a livello globale - semplicemente non puoi presentare senza l'approvazione di un proprietario. E mentre questo rallenta, 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 sorgente è impossibile unire codice che non è stato firmato da qualcun altro e da chi lo ha spinto.

Sparali

È così semplice - o ottengono un progetto da soli, o devono andare. Allontane dalla tua squadra. Non stanno solo facendo la loro parte, ma erodono il morale e le pratiche della squadra.

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

Comprendere

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 sarà d'aiuto in questo caso - presumo che tu lavori costantemente contro i silos (cioè per ridurre il fattore bus), e gli individui del tuo team siano coinvolti in ciò che fanno gli altri.

Lavorare per garantire che le singole richieste di fusione siano piuttosto piccole. Se è più di 1 schermata di modifiche, è necessario un discorso in piedi o lampo per spiegare cosa si sta facendo. Se è 10 pagine, ha bisogno di una presentazione con diapositive e diagrammi di architettura.

Tutti quelli in questione lavorano allo stesso progetto?

Il progetto è già sepolto sotto una montagna di debiti tecnici?

Credono nel progetto e nel miglioramento continuo?