Come rendere la revisione del codice meno come un modo per * spostare * la responsabilità? [duplicare]

Se la prima cosa che uno sviluppatore pensa quando il loro codice fallisce sta spostando la colpa, sembra una questione culturale più ampia. Lo sviluppatore si sente troppo attaccato al loro codice e così è il loro ego da biasimare? Lo sviluppatore è inesperto o ritiene di avere qualcosa da dimostrare?

In alternativa, la direzione urla agli sviluppatori per i difetti e non dice nulla quando le cose funzionano? La squadra è sotto pressione per perdere l'organico? Gli sviluppatori sono a disagio con tecnologie e processi? Quando agli sviluppatori viene chiesto di risolvere un problema, si sentono incolpati?

Tutti fanno errori. I migliori sviluppatori di software lo ammettono, imparano da esso e vanno avanti. Tuttavia, se un singolo errore da parte di una singola persona è sufficiente a causare un grosso problema, questo è un problema di sistema più ampio e la responsabilità della gestione.

Supponendo che nessuno di questi sia il problema e tornando alle revisioni del codice, le recensioni di codice sono molto più che trovare bug. Ad esempio, è la condivisione delle conoscenze, garantendo che lo stile del codice sia coerente, garantendo che i test unitari siano eseguiti e che la documentazione sia aggiornata.

Le migliori recensioni di codice sono discussioni a due vie tra i revisori e gli autori e sono presto ricambiate con il codice dei revisori. Se gli sviluppatori si divertono e ottengono valore da esso, la colpa non si verificherà. La responsabilità per il codice di qualità spetta al team e non a Xyz.

L'unico modo per farlo è allontanarsi da una percezione della revisione del codice come una "revisione" di ciò che qualcuno ha fatto, a un sistema di passaggio delle informazioni. Quindi, anziché il revisore che guida la recensione e critica il codice dello sviluppatore, lo sviluppatore guida la recensione per insegnare al revisore cosa (e perché) ha fatto.

In definitiva si ottiene lo stesso risultato, ma in un modo che ha connotazioni molto meno negative.

Potresti apprezzare una pratica Agile chiamata "The Perfection Game", che fa parte dei Core Protocols .

In sintesi questo è il modo in cui funziona:

• il programmatore chiede ad un potenziale revisore se è OK a giocare a un gioco di perfezione
• se il revisore è OK, il revisore controlla il codice e dà un valore compreso tra 1 e 10, a seconda del valore che ritiene possa aggiungere al codice (ad esempio se dice 1 potrebbe significare che si tratta di un pezzo di merda ma non ne capisco un po ', non sarà di alcun aiuto, o può significare che questo è quasi perfetto, non potrei fare di meglio Se il recensore dice 10 d'altra parte significherebbe: il tuo codice è un pezzo di merda, ma tu hai fortuna: posso aiutarti con questo perché sono un esperto di questo tipo di merda).
• il revisore spiega ciò che gli piace ( non ciò che non piace ) nel codice revisionato
• il programmatore chiede quindi cosa sarebbe necessario per rendere quel codice perfetto e il revisore lo spiega.
• il programmatore quindi ringrazia il revisore e, se necessario, modifica il suo codice.

Naturalmente questo può essere iterato fino a quando il programmatore smette di cercare la perfezione, o il revisore non può più aiutarlo (darà una valutazione bassa e il programmatore si fermerà qui).

Questo è un po 'formale dato che proviene dai Core Protocol, ma il programmatore è sempre responsabile delle modifiche al codice e chiede la revisione come servizio. Di solito non usa questo tipo di revisione per respingere la responsabilità, al contrario il programmatore dovrebbe chiedere ad un altro revisore se un dato non sarà in grado di aiutare.