Quanto è importante il feedback positivo nelle revisioni del codice?

È importante sottolineare le parti buone del codice durante una revisione del codice e i motivi per cui è buono? Un feedback positivo potrebbe essere altrettanto utile per lo sviluppatore in fase di revisione e per gli altri partecipanti alla revisione.

Stiamo facendo recensioni utilizzando uno strumento online, in modo che gli sviluppatori possano aprire recensioni per il loro codice impegnato e altri possono rivedere il loro codice entro un determinato periodo di tempo (ad esempio 1 settimana). Altri possono commentare il codice o i commenti di altri revisori.

Dovrebbe esserci un equilibrio tra feedback positivo e negativo?

Migliorare la qualità e il morale usando le recensioni del codice peer
http://www.slideshare.net/SmartBear_Software/improve-quality-and-morale-using-peer-code-reviews

Cose che tutti dovrebbero fare: revisione del codice
http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

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 a una riunione ed essere criticato?

Quando faccio le revisioni del codice, tendo ad avere solo un monologo in esecuzione, quindi, dato che ho un senso di ciò che sto leggendo, ci sarà un sacco di "Ok, vedo quello che fa .. Bene, si collega a questo e chiama quello, va bene .. e quel pezzo dipende da entrambi, va bene ".

Penso che in questo modo non sia "oo la la this is great!", Potrebbe essere un codice noioso perfettamente banale, ma ascoltare qualcun altro effettivamente analizzare e mostrare la comprensione di ciò che hai scritto è una forma di feedback positivo in sé e 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 a un altro ingegnere perché tutti noi vogliamo che il nostro codice sia compreso da altri, dà una forma di convalida implicita.

Detto questo, se vedi parti del codice che sono caratteristiche buone o positive (anche un codice banale noioso può essere buono se è la forma minima di se stesso) Tendo sicuramente a dichiarare quelle caratteristiche, ancora una volta non le attribuisco come "Wow grande!" tanto quanto "Vedo che questa è un'implementazione minima" o "Ok, questo complesso algoritmo ha molti commenti", concentrati sugli attributi del codice non tanto quanto sulla 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 in basso o tenuto su un piedistallo non dire che qualcosa è buono o cattivo, ma piuttosto parlare attraverso la causa e l'effetto di il 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 toccarlo"

"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 toccano quel dizionario potremmo imbatterci in alcune condizioni di gara"

Nota, non sto dicendo nulla di buono o cattivo, ma se l'ingegnere debba cambiarlo o no sarà compreso dall'ingegnere il cui codice è in fase di revisione. Ovviamente devi terminare la revisione del codice con un yay o un no, ma accumulare queste affermazioni nel corso di esso ammorbidirà il no poiché la spiegazione è già stata fatta sotto forma di dichiarazioni di causa ed effetto quando dici loro "Mi piacerebbe quei numeri magici corretti prima di fare il check in ".

Se vedessi qualcosa in una recensione del codice che mi piaceva molto ed era al di là del codice "abbastanza buono", darei un feedback positivo.

In generale, penso che se qualcuno scrive un codice pezzo che in realtà ti fa dire "Wow, è davvero bello!" quindi sì, il feedback positivo è importante: fa sapere all'autore che ciò che hanno fatto è stato apprezzato dagli altri e dovrebbero provare a farlo di nuovo. Tuttavia, deve essere molto più che seguire le linee guida e le pratiche standard. Dare elogi perché qualcuno ha indentato bene o ha aggiunto commenti sulla piastra di cottura potrebbe impostare il livello piuttosto basso.

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

Se questo è richiesto o meno (e nella misura in cui è richiesto) è una funzione della disposizione e del trucco emotivo della persona con cui stai parlando. Alcune persone rispondono alla correzione in modo molto più efficace se associato a lode. Altri considerano lode insincero quando vengono consegnati con correzione.

La formula generale è talvolta chiamata "Feedback Sandwich": prima cose buone, cose cattive in secondo luogo, ultime cose buone. L'idea è di mantenere positivo il tono generale e allo stesso tempo assicurarsi che il feedback negativo sia ricevuto. Ciò può aiutare a prevenire lo stress durante l'anticipazione di una revisione e successivamente a prevenire rimuginamenti autoassorbenti. Entrambi sono molto importanti in termini di produttività e qualità. Questo non è solo un frullato emotivo permaloso; È un comportamento umano 101.

Ancora una volta, devi conoscere la persona con cui lavori e capire a cosa rispondono. Gestire le persone è ciò che riguarda la gestione e i bravi manager sanno come far rispondere le persone.

Penso che il feedback positivo sia molto importante e provenga principalmente da una dinamica personale, realpolitik. Siamo tutti seduti a scrivere codice per ore, giorni, settimane, mesi e la maggior parte di noi è orgogliosa di ciò che facciamo. Le revisioni 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 positivi), l'incontro potrebbe facilmente essere intitolato in prospettiva "Scopri come le persone cattive pensano che tu faccia schifo". Di conseguenza, gli sviluppatori inizieranno a essere infastiditi o addirittura a temere revisioni del codice, e questo è chiaramente un danno per il team. Gli sviluppatori "dimenticheranno" di far rivedere il loro codice o svilupperanno impotenza appresa e chiederanno semplicemente ai loro critici costanti cosa fare di tutto per evitare di essere fatti esplodere in questi incontri.

Va bene e va bene dire che, in teoria, è più logico riparare il male e chiedere a tutti di lasciare le emozioni alla porta, ma è proprio l'atteggiamento come quello che è responsabile per gli sviluppatori del rappresentante di essere sordo dal punto di vista interpersonale. Teorie a parte, a noi umani e umani piace di tanto in tanto dare una pacca sulla spalla, anche nominale. Quella roba conta.

È più importante se stai facendo recensioni fianco a fianco o di squadra. In una recensione scritta, nessuna notizia è una buona notizia. L'obiettivo è 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 del team. Ci sono molte opportunità di dare un feedback positivo senza ingombrare il database di revisione del codice. È possibile estrarre esempi da condividere con altri.

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

L'unico modo in cui riesco a pensare a dove fornire feedback positivi sul codice potrebbe ritorcersi contro di te è se non stai attento a evitare il "complimento rovescio". Molte persone hanno familiarità con questo ... è indicato da frasi come "Ottimo lavoro, ma ..."

Se tutti arrivano all'incontro 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 feedback "buoni". Il feedback che evidenzia i modi per migliorare la pratica di codifica diventa altrettanto importante del feedback che evidenzia un nuovo metodo utile per gestire un problema.

Per lo meno, se non si arriva a quella lunghezza, si dovrebbe sottolineare che sforzarsi di fare un ciclo di "feedback positivo, feedback negativo, feedback positivo, feedback negativo" all'interno del processo di revisione si imbatterà solo nel stessa sensazione di complimento per il rovescio. Non cercare di forzare un buon feedback, prova a rafforzare il buon sforzo e solleva buchi nella conoscenza.

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

• "Questo è un approccio interessante. Cosa succede se dobbiamo accogliere [qualche altro caso d'uso]?"
• "Bel tentativo! Lo sapevi che abbiamo già un metodo per farlo? Forse dovremmo fare alcuni 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 patch sulla mailing list / strumento online.
2. Tutti coloro che hanno bisogno di cure guardano la patch, suggeriscono miglioramenti.
3. Dev torna al numero 1
4. Se non è necessario alcun miglioramento, la gente dice "Buon lavoro, per favore, commetti". <- RISPOSTE POSITIVE. Tutto il codice accettato è buono. Meno persone devono dirti di cambiare le cose, meglio stai facendo.
5. Dev si impegna, passa all'elemento successivo.

Di solito ciò che accade è che i nuovi sviluppatori otterrebbero un feedback molto più "correttivo" man mano che acquisiranno familiarità con la base di codice.

I vantaggi di questo approccio sono:

1. Tutti sanno cosa stanno facendo tutti. Non vi è alcuna conoscenza che monopolizza o che il mistero commette.
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, qualcuno dall'altra parte della stanza non beneficia allo stesso modo come farebbe se fosse successo nella mailing list.
3. Altri sviluppatori di solito possono individuare alcuni bug prima di essere nel controllo della versione.

Non posso essere affatto d'accordo. Qual è la differenza tra le buone tecniche di sviluppo e i cosiddetti programmatori ninja che possono scrivere codice fantastico ma inspiegabile per i semplici mortali? Lo sviluppo software è ora (IMO) una disciplina di denominazione comune più bassa in cui talento e astuzia sono evitati a favore della manutenibilità e della comprensione. È troppo rischioso.

Non riesco a pensare a una volta in cui ho mai visto il codice in una recensione che mi avrebbe fatto andare "Oh, che bello". Posso solo supporre che se incontrassi un codice del genere, cadrebbe nel campo freddo ma inaccettabile.

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

Le revisioni del codice sono lì per diffondere la responsabilità della qualità del codice tra il team, vale a dire che un singolo sviluppatore non può essere incolpato se in seguito si presenta un problema serio. Usalo per trovare problemi, usalo per ottenere spiegazioni dallo sviluppatore originale di cose strane nel caso in cui dovessi finire per mantenerlo. Personalmente, sono più interessato a ricevere feedback negativi. I clienti non si preoccupano della freddezza del tuo codice, solo che fa quello che vogliono.

Lascia il backslapping al pub.

Mi è importato. Non voglio commenti fluff o positività per motivi di positività. Se tutto il codice che ho scritto è scadente, dimmi perché, correggiamolo e impariamo. Ma se faccio qualcosa di giusto, è bello ascoltarlo una volta ogni tanto. Non ho bisogno di rinforzi positivi per tutto ciò che ho fatto che fosse "corretto", ma anche se è un "miglioriamo X, Y e Z, ma il resto sembra buono" è importante.

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

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

Ciò può significare che le revisioni del codice sono eccessivamente critiche, ma non è questo il punto. Dovremmo anche essere critici con noi stessi. Trovo che il presupposto che il codice che ho scritto sia probabilmente spazzatura completa e sicuramente potrebbe essere migliorato mi spinge a migliorare il mio codice e il mio livello di abilità.

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

Mantra è semplice: se si desidera un codice di qualità (che è meno nella realtà), è necessario praticare metodi di revisione adeguati. Detto questo, un feedback positivo aiuta uno sviluppatore / programmatore a pensare e elaborare idee / soluzioni / soluzioni. Non essere troppo duro, ma sii fermo sul punto. I manager di domande e risposte devono essere consapevoli delle buone metodologie e pratiche in modo da poter guidare il team (o un membro) nella giusta direzione. Ciò si traduce in qualità. Periodo.

Quando il codice è per un concorso o inviato per un colloquio di lavoro (in altre parole, codice scritto e che non può essere riscritto), i commenti positivi sono indispensabili. In effetti, dovresti assicurarti che ci sia un feedback positivo (dove possibile!) Oltre che 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, in cui il codice può essere riscritto. In tal caso, stai cercando di far uscire i bug dal tuo sistema. Quindi, in quella situazione, valgono solo i bug negativi.

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

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