Qual è il modo migliore per un programmatore di gestire la revisione del codice?

Sono abbastanza nuovo per la revisione del codice, ma ho programmato per anni durante il mio dottorato di ricerca - il che non sempre ti rende un buon programmatore!

Se il revisore modifica il codice e lo analizza riga per riga, cosa fai se non sei d'accordo? A volte hai fatto la scelta X e il revisore lo ha cambiato in Y e avevi in ​​mente Y ma hai deciso di non farlo a causa degli svantaggi, ma il revisore afferma che tali svantaggi non sono importanti. Dovresti verbalizzare il tuo disaccordo, o semplicemente no e ascoltarli?

È difficile se non sei bravo ad accettare le critiche e se il revisore è una persona più anziana nell'organizzazione. Non sarebbe bello trovarsi troppo difensivo.

È vero, trovarsi difensivo non è utile; ma poi - nessuno dei due viene criticato, quindi se ritieni che ciò stia accadendo dovresti davvero esprimere le tue preoccupazioni sul fatto che la revisione del codice non ti aiuti a scrivere codice migliore all'interno dell'organizzazione.

Il revisore ha la responsabilità di rivedere il codice per non conformità e difetti reali, non usarlo come mezzo per scrivere il codice come avrebbe fatto. Ciò significa che la recensione è lì per rivedere come hai fatto qualcosa, e sottolineare le aree in cui hai commesso un errore (qualcosa che il meglio di noi fa) o non hai capito il quadro o gli standard o "ragioni storiche" in cui alcuni codici sono scritti come è dove sei.

Quindi, se ci sono diversi modi per fare qualcosa, ci deve essere una buona ragione per cui il tuo codice viene cambiato in un modo alternativo, altrimenti è semplicemente una zangola non costruttiva che non ti aiuterà.

Inoltre, ricorda che neanche il recensore è perfetto. Potrebbero avere l'idea che Y sia il modo di farlo, e non si sono resi conto che X è migliore. Dovresti spiegare i motivi per cui l'hai fatto nel modo X. Il revisore potrebbe essere d'accordo con te, o potrebbe dirti perché Y è una soluzione migliore - potrebbero esserci altri fattori che non sai che lo fa.

In breve, le recensioni sono un modo per far comunicare ai membri del team le loro modifiche al codice. Quindi parlane con il recensore.

Se aiuta, parla in modo imparziale, come se non fossi nemmeno l'autore del codice in revisione. Dopotutto, il codice appartiene alla società o al team e il team dovrà mantenerlo. Ti è capitato di essere il tipo che l'ha scritto, non è un fattore così importante come molti credono.

La scrittura di codice informatico è un ottimo esempio di decisione in condizioni di incertezza . Ci sono sempre pressioni contrastanti e il modo in cui decidi in una determinata domanda dipende da quali pressioni percepisci e da quanto grandi le consideri.

Pertanto, quando un revisore non è d'accordo con la tua decisione, significa che vedono pressioni / rischi diversi da te, o ne considerano alcuni più grandi / più piccoli di te. Devi assolutamente parlare di queste differenze, perché non farlo perpetua i problemi che hanno portato al disaccordo in primo luogo.

Se il tuo revisore è più senior, la sua esperienza potrebbe dire correttamente che questo o quel rischio non è molto rilevante nella pratica, oppure potrebbero sapere che un certo tipo di errore ha una lunga storia di eventi nella tua organizzazione e vale la pena prestare particolare attenzione per evitarlo. Viceversa, se ritieni di sapere qualcosa che il tuo recensore probabilmente non conosce, devi assolutamente esprimerlo; tacere equivale a una rinuncia al dovere da parte tua.

La parte più importante di gestire la situazione è capire che le critiche di decisioni di progettazione è praticamente sempre non è una critica della personalità di qualcuno. (Nei rari casi in cui è effettivamente, lo noterai abbastanza presto, e se davvero non puoi piacere a qualcuno, niente che fai fa alcuna differenza, quindi dov'è il danno nel seguire le migliori pratiche? Molto meglio trovare una posizione migliore come il più presto possibile.) È solo il risultato di persone diverse che hanno percezioni diverse dei molti rischi e benefici connessi al codice del computer, e dato quanto sia complesso il codice del computer moderno, è prevedibile. Parlare delle differenze aiuta a migliorare il codice e a migliorare la cooperazione in questo caso e in casi futuri.

Le altre risposte contengono già ottime informazioni. Vorrei ampliare un po 'alcuni aspetti che sono stati accennati da gbjbaanb (vedi il mio commento alla sua risposta).

Nella mia esperienza ho osservato diversi tipi di feedback durante le revisioni del codice:

1. "Credo sinceramente che questo sia sbagliato / non ottimale e che dovresti cambiarlo in questo modo." Normalmente prendo sul serio questo tipo di feedback e mi opporrò al cambiamento suggerito solo se penso di avere un punto di forza contro di esso.
2. "Trovo la tua soluzione OK, considera questa alternativa ma spetta a te accettare o meno la modifica." Prendo sul serio anche questo tipo di feedback: il recensore sta suggerendo un'alternativa, anche se non hanno una forte opinione che la loro soluzione sia migliore. Ho l'opportunità di imparare qualcosa e accetterò il cambiamento se mi piace di più. Altrimenti, il revisore trova OK se mantengo il codice secondo i miei gusti.
3. "L'avrei fatto diversamente, quindi dovresti cambiarlo, punto", o anche "Oh, ho cambiato il tuo codice perché ...", la modifica non è stata suggerita, è già stata impegnata! Viene fornita una breve spiegazione della modifica, con il suggerimento che non c'è molto tempo per discutere i dettagli perché dobbiamo passare all'attività successiva.
4. Il revisore suggerisce piccoli cambiamenti di natura banale che non migliorano il codice ma lo rendono diverso. Quando ti viene chiesto di discutere le modifiche suggerite, il revisore inizia lunghe discussioni su dettagli banali fino a quando non ti arrendi per sfinimento.

Le opzioni 3, 4 possono essere mascherate da 1 e 2: "Era davvero importante farlo nel modo che ho suggerito." o "Puoi rifiutare il cambiamento se vuoi davvero", ha detto con un tono che in realtà significa esattamente l'opposto di ciò che viene detto. Nel caso in cui ti opponga a cambiamenti che ritieni non necessari, la proprietà del codice condiviso può essere utilizzata come giustificazione di questo atteggiamento: "Il codice non ti appartiene, appartiene alla squadra!" Puoi capire quando l'intenzione del revisore non è onesta se il revisore non è molto aperto alla discussione, si irrita e cerca di spingere la propria soluzione a tutti i costi. Fondamentalmente hanno già deciso, e ogni ulteriore discussione è solo una perdita di tempo.

Le opzioni 1 e 2 dell'IMO sono un segno di un recensore onesto che sta cercando di aiutarti, sta cercando di insegnarti qualcosa nel rispetto del tuo lavoro ed è anche aperto a imparare qualcosa da solo. In questo scenario, cerco di non essere troppo orgoglioso quando ricevo un feedback costruttivo da un revisore.

Le opzioni 3, 4 suggeriscono che è in corso un gioco di potere: l'importante è se lo facciamo a modo mio o nel modo che preferisci, non che cerchiamo di trovare una buona soluzione che soddisfi entrambi. Ciò può essere correlato all'ego del revisore, ma anche alla loro incapacità di comprendere qualsiasi codice che non segue il loro modo di pensare. Normalmente sono disturbati da un codice che non sembra familiare e vorrebbero imporsi su tutta la base di codice.

Se le situazioni 3 e 4 si verificano troppo spesso, il lavoro di squadra può diventare piuttosto spiacevole. In una situazione del genere prenderei in considerazione la possibilità di lasciare la squadra.

Per risolvere il problema su cosa fare quando non si è d'accordo ...

Parlarlo è il nostro modo di procedere, come molti hanno già sottolineato.

Se l'hai già fatto, forse anche più di una volta, una tecnica utile che usiamo è se c'è ancora disaccordo in alcune aree è dire 'sì, sarebbe bene rifattarlo -

Possiamo mettere un biglietto separato per quello?

Un biglietto separato ti consente di ottenere il codice, invece della temuta modalità "churn and never on on" che ho conosciuto bene in alcuni punti. Questo si adatta bene con l'agile, facendo il minimo "possibile" e distribuendo il carico. A volte yagni finirà per fare domanda. Alcune volte il product manager deciderà che ci sono esigenze più pressanti di quel refactor in termini di valore per il cliente, scadenze e risorse.

La revisione del codice è probabilmente una buona cosa in generale, ma dalla mia esperienza è meglio servire come strumento per gli sviluppatori di nuovi team utilizzando nuove linee guida di codifica o per correggere bug importanti, in modo da ridurre il rischio di errori. Se ritieni di conoscere meglio del revisore, dovresti chiederti perché la soluzione che lui o lei propone è migliore e discutere con le tue intuizioni sulla questione. Nessuno sa tutto meglio, quindi la revisione del codice dovrebbe o potrebbe essere una preziosa esperienza di apprendimento per entrambi.

La revisione del codice è sia un'opportunità per cogliere potenziali problemi che per trasmettere conoscenze, sia per i revisori che per i programmatori.

In qualità di revisore del codice, la responsabilità è quella di evidenziare possibili aree di rischio, non conformità alla pratica standard, miglioramenti e in genere solo un altro punto di vista sulla stessa area di codice.

Ciò non dovrebbe comportare una modifica del codice senza discutere / comprendere le decisioni dei programmatori al momento dello sviluppo.

Se il revisore sta apportando modifiche, potrebbe avere difficoltà a delegare il lavoro ad altri, il che è difficile da fare per molte persone intelligenti.

Come programmatore che riceve una recensione sei protetto da un possibile problema quando viene distribuito, ti viene data la possibilità di imparare qualcosa di nuovo e l'opportunità di condividere le tue conoscenze con il revisore.

Indipendentemente dall'anzianità, il tuo modo di pensare può trovare una soluzione che per alcuni non si presenta, quindi la recensione può essere la tua occasione per brillare semplicemente facendo ciò che ritieni giusto.

Fintanto che sia il programmatore che il revisore accettano che possono sbagliare e che va bene sbagliare, una revisione diventa qualcosa che rafforza il team perché si lavora insieme sulla soluzione.

Sembra che tu non abbia ancora avuto una revisione del tuo codice :-)

L'obiettivo della revisione del codice è ottenere un codice di qualità decente e sapere che hai un codice di qualità decente. Quando il codice di uno sviluppatore inesperto viene rivisto, può essere utilizzato per insegnare come scrivere codice migliore, evitando al contempo di frustrare quello sviluppatore.

Il revisore non dovrebbe mai modificare il codice. Possono dare suggerimenti più o meno forti su come vorrebbero che il tuo codice venisse modificato e possono decidere se accettare o meno il tuo codice.

Se la revisione va a destra / se ho rivedere il codice, quello che probabilmente otterrete è alcuni commenti come ho avrei scritto il codice che si può imparare da, o ignorare - queste sono cose in cui ho un parere e si è liberi di avere una opinione diversa. Nella mia area, una buona denominazione di funzioni, variabili e così via è considerata importante, quindi potresti ricevere alcuni suggerimenti per migliorare la denominazione. Di solito dovresti apportare modifiche in quel caso (a volte trovando un nome ancora migliore per qualcosa). A volte troverò bug. Li aggiusti. A volte trovo cose che penso siano bug e mi sbaglio. Se è difficile vedere che il codice è corretto, lo si rende più ovvio corretto. Se ho appena sbagliato, dimmelo tu.

Se penso che il design non sia generalmente corretto, allora questo avrebbe dovuto essere discusso in precedenza. Dovremmo quindi pensare se il tuo design è abbastanza buono, tenendo conto di quanto lavoro è coinvolto in una modifica, o forse ho sbagliato e il tuo design è migliore. Dovremmo concludere con un accordo.

Se revisore e revisore non possono essere d'accordo, abbiamo un problema. Perché significa che uno di noi è incapace di lavorare in gruppo, o uno di noi non è in grado di distinguere tra un design buono o cattivo, o entrambi. Questo non è necessariamente colpa tua. Sfortunatamente ci sono sviluppatori che sono senior e all'oscuro, e questo sarà un problema per l'azienda e per te.

Se succede, pensa molto, molto forte: hai problemi ad accettare critiche fondate? In tal caso, devi cambiare atteggiamento. Sei troppo inesperto per capire perché il recensore ha ragione? In tal caso, non è un problema. Fidati del revisore e impara. Sei sicuro di conoscere meglio del recensore? Accetta la recensione, ma chiedi a un terzo sviluppatore di fiducia la sua opinione. Ricorda che puoi essere veramente sicuro di te stesso e avere ragione, ma puoi anche essere davvero sicuro di te stesso e avere torto.