Come si fa a far accettare la revisione del codice? [duplicare]

Rendi la revisione del codice una parte obbligatoria del commit del codice nel repository principale.

Questo è ciò che faccio fare al mio team e aumenta la qualità del codice e elimina quasi completamente la possibilità di codice discutibile facendolo entrare nella base di codice senza essere specificamente contrassegnato come "debito tecnico".

Usiamo Git e Gitorious per gestire le nostre basi di codice e repository.

C'è un repository mainline , nessuno si impegna direttamente a questo, ma lo carica nei cloni privati sul server Gitorious.

Il lavoro e il push si impongono sul clone del server privato e poi eseguono unire le richieste per richiedere che le loro modifiche vengano incorporate nella linea principale .

Qualcun altro risponde alla richiesta di fusione, preferibilmente al capo tecnico di squadra / progetto, rivede il codice delle modifiche, le applica, compila ed esegue i test e, se tutto è a posto, spinge le modifiche al mainline repository e chiude la richiesta di fusione.

Team / Project I leader tecnici hanno risposto alle richieste di fusione a qualcun altro del team, che è una grande esperienza di apprendimento per i membri junior se un peer non è disponibile a farlo.

In entrambi i casi ora più di una persona è al corrente perché il codice errato viene impegnato nel repository mainline e interessa il resto del team e dell'azienda nel suo complesso. Se un membro più anziano del team risponde alla maggior parte delle richieste di unione, sono più qualificati per correggere o rifiutare implementazioni o progetti scadenti prima che possano influire sull'intera base di codice.

Queste recensioni di codici mini sono molto più utili delle tradizionali revisioni di codice che di solito sono una perdita di tempo. Le revisioni del design sono molto più preziose, perché un'implementazione corretta * di un ** design scadente è molto peggiore di un'implementazione scarsa di un design appropriato .

Mi sono stupito che nessuno abbia ancora menzionato la pratica Agile denominata "The Perfection Game", che fa parte dei Core Protocols . Core Protocols suggerisce una sorta di revisione del codice più facile da accettare per i programmatori.

In sintesi funziona così:

• 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 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 un riesame 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.

Il gioco della perfezione potrebbe non essere applicabile a tutti i casi in quanto funziona su base volontaria (comprendo la domanda come una domanda sulle revisioni obbligatorie del codice). Ha anche messo in luce che l'etichetta "code review" copre molte pratiche differenti sottostanti (nell'agile World solo Perfection Game e Pair Programming sono ad esempio due tipi completamente diversi di revisioni del codice).

Alcune pratiche sono più facili da accettare rispetto ad altre e possono anche dipendere dal team e dal programmatore individuale. Come postulato, risponderei anche alla domanda originale dicendo che le revisioni del codice sono più facili quando c'è fiducia tra i membri di una squadra.

Indipendentemente dalle pratiche scelte, Fiducia verso gli altri collaboratori di squadra è certamente al centro dell'accettazione delle revisioni del codice da parte dei programmatori.

Questo dipende molto dal programmatore. Ho avuto un sacco di recensioni di codice e alcuni ignorano qualsiasi cosa tu dica - a volte perché non capiscono, ma soprattutto perché semplicemente ignorano i consigli - specialmente quando li stanno spingendo. Sembra spesso che "scrivono codice cattivo" (cosa che più spesso e poi meno fanno - sospiro) e lo prendono personalmente - anche se non è inteso in quel modo (positività positiva).

Interessante, il modo migliore che ho trovato per convincere le persone a scrivere codice più pulito è quello di introdurre strumenti di controllo automatico del codice al momento del check-in. Pertanto, quando il loro codice non soddisfa determinati standard (vale a dire casi di test, commenti, blocchi di codice non salvati), il commit viene rifiutato. Ci sono ancora alcune persone che cadono attraverso i loop e scrivono falsi, ma ha aiutato più di quanto faccia male (nella mia esperienza).

Assicurati che sia facile scoprire il nuovo codice. Preferibilmente, notifica agli sviluppatori quando il codice cambia, non contare sugli sviluppatori per cercare il codice modificato. In un team di dimensioni ragionevoli l'invio automatico di diff SVN su commit è un ottimo modo per ottenere questo risultato. Insieme al differenziali colorati addon per il codice Thunderbird, le recensioni sono un gioco da ragazzi. Leggo la maggior parte del codice impegnato (siamo sei sviluppatori del mio team). Non tutti gli sviluppatori dovranno leggere i commit facendo ciò, ma diventeranno davvero convenienti per coloro che sono motivati a farlo.