Quanto è importante il feedback positivo nelle revisioni del codice?

Migliora la qualità e il morale utilizzando le recensioni dei codici peer
link

Cose che tutti dovrebbero fare: revisione del codice
link

Entrambi questi articoli affermano che uno degli scopi della revisione del codice è condividere le conoscenze sulle buone tecniche di sviluppo, non solo trovare errori.

Quindi direi che è molto importante. Chi vuole andare ad una riunione e solo essere criticato?

Quando eseguo le revisioni del codice tendo ad avere solo un monologo in esecuzione, così come sto dando un senso a ciò che sto leggendo ci sarà un sacco di "Ok, vedo cosa fa .. Buono si connette a questo e lo chiama, va bene ... e quel pezzo dipende da entrambi. ".

Penso che in questo modo non sia "oo la la è così bello!", potrebbe essere un codice noioso e banale, ma ascoltare qualcun altro effettivamente analizzare e mostrare la comprensione di ciò che hai scritto è una forma di feedback positivo dentro e di per sé, il feedback è "Questo codice ha senso", quando mi imbatto in parti che non capisco chiedo spiegazioni e quando lo capisco esclamano "Ah, ho capito".

Penso che il semplice trasferimento di comprensione sia un elogio per un altro ingegnere perché tutti vogliamo che il nostro codice sia compreso dagli altri, fornisce una forma di convalida implicita.

Detto questo, se vedi parti del codice che sono caratteristiche positive o positive (anche il noioso codice banale può essere buono se è la forma minima di se stesso), io tendo decisamente a indicare quelle caratteristiche, di nuovo non le attribuisco come "Wow fantastico!" così come "Vedo che questa è un'implementazione minima" o "Ok, questo algoritmo complesso ha molti commenti", si concentra sugli attributi del codice non tanto per la sua intrinseca bontà o cattiveria.

Ogni volta che attribuisci "bontà" o "cattiveria" al codice in una revisione del codice per evitare di far sentire l'ingegnere guardato dall'alto in basso o tenuto su un piedistallo, non dire che qualcosa è buono o cattivo, ma piuttosto parlare attraverso la causa ed effetto del loro codice.

"Ok questa parte ha senso, ah c'è un numero magico qui, il significato di quel valore potrebbe non essere ben compreso dal prossimo ingegnere per toccare questo"

"Vedo che hai un contenitore DI qui ok, quindi avrai un accoppiamento lento con quel repository"

"Ah c'è un dizionario statico qui, se più thread stanno toccando quel dizionario potremmo imbattersi in alcune condizioni di gara"

Notate che non sto dicendo che tutto sia buono o cattivo, ma se l'ingegnere dovrebbe cambiarlo o no sarà capito dall'ingegnere il cui codice è in fase di revisione. Ovviamente devi terminare la revisione del codice con un yay o un nay, ma l'accumulo di queste affermazioni nel corso di esso ammorbidirà le noia come la spiegazione è già stata fatta sotto forma di dichiarazioni di causa ed effetto quando dici loro "Vorrei quei numeri magici sono stati risolti prima di verificarlo in ".

Se ho visto qualcosa in una revisione del codice che mi è piaciuto molto e al di sopra del codice "abbastanza buono", darei un feedback positivo.

In generale, penso che se qualcuno scrive un codice pezzo che effettivamente ti fa dire "Wow, questo è davvero bello!" allora sì, il feedback positivo è importante - rende noto all'autore che ciò che hanno fatto è stato apprezzato da altri, e dovrebbero provare a farlo di nuovo. Tuttavia, deve essere ben più che seguire le linee guida e le pratiche standard. Rinunciare a lodi perché qualcuno ha fatto rientrare bene o ha aggiunto commenti di tipo "standard" potrebbe impostare la barra piuttosto in basso.

Questa non è una domanda di programmazione in quanto è una questione di gestione generale e di interazione umana. Il feedback positivo nelle revisioni del codice è tanto importante quanto il feedback positivo in qualsiasi tipo di recensione.

Se questo è richiesto o meno (e la misura in cui è richiesto) è una funzione della disposizione e della composizione emotiva della persona con cui stai parlando. Alcune persone rispondono alla correzione molto più efficacemente quando è accoppiato con lode. Altri considerano le lodi insincere quando vengono fornite con la correzione.

La formula generale è talvolta definita "Feedback Sandwich": roba buona prima, seconda roba cattiva, ultima roba buona. L'idea è di mantenere il tono generale positivo mentre allo stesso tempo si assicura che il feedback negativo sia ricevuto. Questo può aiutare a prevenire lo stress nell'anticipare una revisione, e aiuta a prevenire in seguito cova autoassorbita. Entrambi sono molto importanti per quanto riguarda la produttività e la qualità. Questo non è solo un toccasana emotivo commovente; È un comportamento umano 101.

Ancora una volta, devi conoscere la persona con cui stai lavorando e capire a cosa rispondono. Affrontare le persone è ciò di cui si occupa la gestione e i buoni manager sanno come far rispondere le persone.

Penso che il feedback positivo sia molto importante ed è principalmente da una dinamica personale, realpolitik. Ci sediamo e scriviamo codice per ore, giorni, settimane, mesi e la maggior parte di noi è orgogliosa di ciò che facciamo. Le recensioni del codice sono un'occasione per dimostrarlo.

Se vai a una revisione del codice e il risultato migliore che puoi sperare è "nessun commento" (cioè non c'è equilibrio di feedback positivo), l'incontro potrebbe facilmente essere intitolato in prospettiva "Scopri come le persone ti pensano male Succhiare". Di conseguenza, gli sviluppatori inizieranno a essere infastiditi o addirittura terrorizzati dalla revisione del codice, e questo è chiaramente un danno per il team. Gli sviluppatori "dimenticheranno" per rivedere il loro codice o svilupperanno l'impotenza appresa e semplicemente chiederanno ai loro critici costanti che cosa fare su ogni piccola cosa per evitare di essere fatti saltare in questi incontri.

Va tutto bene e dire che, in teoria, è più logico correggere il male e chiedere a tutti di lasciare le emozioni alla porta, ma sono proprio atteggiamenti come quello che è responsabile per gli sviluppatori di ripetitori come interpersonali stonato. A parte le teorie, siamo umani e gli umani amano ricevere una pacca sulla schiena di tanto in tanto, anche se nominali. Quella roba conta.

È più importante se si eseguono analisi affiancate o di team. In una recensione scritta, nessuna notizia è una buona notizia. L'obiettivo è quello di ottenere il codice in produzione. Quando è il tuo codice, dovresti sentirti bene con te stesso.

La revisione del codice dovrebbe essere utilizzata come fonte di informazioni per aiutare con il mentoring e la gestione della squadra. Ci sono molte opportunità per dare un feedback positivo senza ingombrare il database di revisione del codice. Gli esempi possono essere estratti per condividerli con gli altri.

C'è molto di più nella revisione dello sviluppatore oltre al loro codice. Il tempo di revisione del codice di dirottamento può essere controproducente per ottenere un'app fuori dalla porta. Imposta il tempo specifico per aiutare lo sviluppatore al di fuori delle recensioni del codice, ma ciò non significa che dovresti escludere il feedback della revisione del codice.

L'unico modo in cui posso pensare a dove fornire feedback positivi sul codice potrebbe ritorcersi contro di te è se non stai attento a evitare il "complimento di rovescio". La maggior parte delle persone ha familiarità con questo ... è significato da frasi come "Ottimo lavoro, ma ..."

Se tutti si incontrano con l'atteggiamento che questa non è una recensione personale del programmatore, ma uno sforzo per migliorare le pratiche di codifica per la qualità dell'intero sistema, allora tutti i feedback sono "buoni" feedback. Il feedback che evidenzia i modi per migliorare la pratica della codifica diventa altrettanto importante quanto il feedback che evidenzia un nuovo metodo utile per gestire un problema.

Per lo meno, se uno non va a quella lunghezza, dovrebbe essere sottolineato che sforzarsi di fare un ciclo di "feedback positivo, feedback negativo, feedback positivi, feedback negativi" all'interno del processo di revisione sta per venire attraverso con la stessa sensazione di complimento di rovescio. Non cercare di forzare un buon feedback, cercare di rinforzare il buon sforzo e puntellare buchi nella conoscenza.

Frasi che ho imparato di più, nel corso degli anni:

• "È un approccio interessante. Cosa succede se dobbiamo accogliere [qualche altro caso d'uso]?"
• "Bel tentativo! Sapevi che abbiamo già un metodo per farlo? Forse dovremmo fare un po 'di benchmark per vedere quale approccio è più efficiente."

Il flusso di lavoro che mi è piaciuto di più con le revisioni del codice è stato questo:

1. Dev invia la patch sulla mailing list / strumento online.
2. Chiunque abbia bisogno di cure guarda la patch, suggerisce miglioramenti.
3. Dev torna al # 1
4. Se non sono necessari miglioramenti, le persone dicono "Buon lavoro, per favore, commetti". < - FEEDBACK POSITIVO. Tutto il codice accettato è buono. Meno persone devono dirti di cambiare le cose, meglio sta facendo.
5. Dev commit, passa all'elemento successivo.

Di solito ciò che succederebbe è che i nuovi sviluppatori ottengono molto più feedback "correttivi" man mano che acquisiscono familiarità con il codebase.

I vantaggi di questo approccio sono:

1. Tutti sanno cosa stanno facendo tutti. Non c'è conoscenza che monopolizzi o commetta mistero.
2. Tutti imparano dal feedback degli altri. Questo è importante. Se il feedback avviene solo tra 2 persone in una conversazione faccia a faccia durante l'accoppiamento, allora qualcuno dall'altra parte della stanza non beneficia nello stesso modo in cui lo farebbe se fosse accaduto sulla mailing list.
3. Gli altri sviluppatori possono di solito individuare alcuni bug prima che siano nel controllo della versione.

Non posso assolutamente essere d'accordo. Qual è la differenza tra le Good Development Techniques e i cosiddetti Ninja Coders che possono scrivere un codice fantastico, ma inspiegabile nei confronti dei mortali? Lo sviluppo del software è ora (IMO) una disciplina con il minimo comune denominatore in cui flair e astuzia sono evitati a favore della manutenibilità e della facilità di comprensione. È troppo rischioso.

Non riesco a pensare a un momento in cui ho mai visto il codice in una recensione che mi avrebbe fatto dire "Oh, è bello". Posso solo supporre che se avessi incontrato un codice come questo, sarebbe caduto nel campo di Non-accettabile.

Avresti anche problemi con le persone che non ricevono feedback positivi, magari provando troppo e facendo un casino finale. "Fidati di me, funziona!".

Le revisioni del codice servono a diffondere la responsabilità della qualità del codice all'interno del team, vale a dire che un singolo sviluppatore non può essere incolpato se in seguito si presenta un problema serio. Usalo per trovare i problemi, usalo per ottenere spiegazioni dallo sviluppatore originale di cose strane nel caso tu finissi per doverlo mantenere. Personalmente, sono più interessato a ricevere feedback negativi. I clienti non si preoccupano della freschezza del tuo codice, solo che fa ciò che vogliono.

Lascia il backslapping al pub.

Ha importanza per me. Non voglio commenti flug o positività per motivi di positività. Se tutto il codice che ho scritto è schifoso, dimmi perché, correggilo e impara. Ma se faccio qualcosa di giusto, è bello sentirlo una volta tanto. Non ho bisogno di rinforzi positivi per tutto quello che ho fatto che era "corretto", ma anche se è un "miglioriamo X, Y e Z, ma il resto sembra buono" importa.

Non altrettanto importante quanto il feedback onesto. Lavoro per una grande società finanziaria, e ai nostri clienti non importa se il programmatore si sta impegnando o è un bravo ragazzo, o di solito scrive un buon codice! Richiedono un software che funziona.

Penso che sia importante essere completamente obiettivi. Cercare di aumentare il morale facendo commenti positivi è una perdita di tempo nella mia mente.

Ciò può significare che le revisioni del codice sono eccessivamente critiche, ma non è questo il punto. Dovremmo anche essere critici nei confronti di noi stessi. Trovo che il presupposto che il codice che ho scritto sia probabilmente completo e sicuramente possa essere migliorato mi spinge a migliorare il mio codice e il mio livello di competenza.

Se non ricevi commenti, puoi considerare di aver fatto un buon lavoro.

Mantra è semplice: se si vuole un codice di qualità (che è meno nella realtà), allora devono essere praticati metodi di revisione adeguati. Detto questo, un feedback positivo aiuta uno sviluppatore / programmatore a pensare e trovare idee / soluzioni / correzioni. Non essere troppo duro, ma essere fermo sul punto. Q & A I manager dovrebbero essere consapevoli di buone metodologie e pratiche in modo che lui / lei possa guidare la squadra (o un membro) nella giusta direzione. Ciò si traduce in qualità. Periodo.

Quando il codice è per una competizione o viene inviato per un colloquio di lavoro (in altre parole, il codice è scritto e non può essere riscritto), i commenti positivi sono indispensabili. In effetti, dovresti assicurarti che ci sia un feedback positivo (ove possibile!) E negativo. In questo modo, il programmatore sa dove si trovano i suoi punti di forza e di debolezza e può compensare.

Tuttavia, sembra che tu stia parlando in un ambiente di lavoro, dove il codice può essere riscritto. In tal caso, stai cercando di ottenere bug fuori dal tuo sistema. Quindi, in quella situazione, solo gli errori negativi sono di qualche valore.

Se ti senti a disagio, organizza una riunione di revisione del codice settimanale, in cui tutti possono discutere sia del codice corretto che del codice errato.

EDIT: Anche se lo dirò, se qualcosa ti colpisce abbastanza, non c'è nulla che ti impedisca di esprimere la tua lode di persona. Il tracker, tuttavia, sembra essere solo per la revisione del codice di produzione.