Frustrazione tra peer / code review

Non mi definirei uno sviluppatore superstar, ma relativamente esperto. Cerco di mantenere la qualità del codice ad alto livello e cerco sempre di migliorare il mio stile di codifica, cerco di rendere il codice efficiente, leggibile e coerente, nonché di incoraggiare il team a seguire schemi e metodologie per garantire coerenza. Comprendo anche la necessità di un equilibrio tra qualità e velocità.

Per raggiungere questo obiettivo, ho presentato al mio team il concetto di peer review. Due pollici in su nella richiesta pull-pull di github per un'unione. Fantastico - ma non secondo me senza i singhiozzi.

Vedo spesso commenti di peer review degli stessi colleghi come -

• Sarebbe bene aggiungere uno spazio dopo <INSERT SOMETHING HERE>
• Linea extra indesiderata tra i metodi
• L'arresto completo deve essere utilizzato alla fine dei commenti nei blocchi di documenti.

Ora dal mio punto di vista - il recensore sta guardando superficialmente l'estetica del codice - e non sta davvero eseguendo una revisione del codice. La recensione del codice cosmetico mi appare come mentalità arrogante / elitaria. Manca di sostanza, ma non puoi davvero litigare troppo perché il recensore è tecnicamente corretto . Preferirei di gran lunga vedere meno dei precedenti tipi di recensioni e più recensioni come segue:

• È possibile ridurre la complessità ciclomatica di ...
• Esci presto ed evita if / else
• Estrarre la query DB in un repository
• Questa logica non appartiene davvero qui
• Non ripetere te stesso: astratto e riutilizzo
• Cosa accadrebbe se Xfosse passato come argomento al metodo Y?
• Dov'è il test unitario per questo?

Trovo che sono sempre gli stessi tipi di persone a fornire i tipi di recensioni cosmetiche e gli stessi tipi di persone che secondo me danno le revisioni tra pari "Qualità e logica".

Qual è (se esiste) l'approccio corretto alla revisione tra pari. E ho ragione a sentirmi frustrato con le stesse persone fondamentalmente che passano in rassegna il codice alla ricerca di errori di ortografia e difetti estetici piuttosto che reali difetti del codice?

Se avessi ragione, come potrei incoraggiare i colleghi a cercare effettivamente i difetti nel codice in armonia con la proposta di ritocchi cosmetici?

Se non sono corretto, per favore illuminami. Ci sono delle regole empiriche per ciò che costituisce effettivamente una buona revisione del codice? Ho perso il punto di quali revisioni del codice sono?

Dal mio punto di vista, la revisione del codice riguarda la responsabilità condivisa per il codice. Non mi sentirei a mio agio nel dare il pollice in su al codice senza affrontare / controllare la logica, la leggibilità e la funzionalità. Inoltre non mi preoccuperei di bloccare una fusione per un solido pezzo di codice se notassi che qualcuno ha omesso un punto fermo in un blocco di documenti.

Quando rivedo il codice, trascorro forse tra 15-45 minuti per 500 Loc. Non riesco a immaginare che queste recensioni superficiali impieghino più di 10 minuti in assoluto se questa è la profondità della revisione che stanno eseguendo. Inoltre, quanto valore è il pollice in su del recensore superficiale? Sicuramente questo significa che tutti i pollici non hanno lo stesso peso e potrebbe essere necessario un processo di revisione in 2 passaggi. Un pollice per recensioni approfondite e un secondo pollice per la "lucidatura"?

Tipi di recensioni

Non esiste un vero modo per eseguire revisioni tra pari. Esistono molti modi per giudicare se il codice è di qualità sufficientemente elevata. Chiaramente c'è la questione se si tratta di un bug o se ha soluzioni che non si adattano o che sono fragili. Questioni di conformità agli standard e alle linee guida locali, sebbene forse non critiche come alcune delle altre, fanno anche parte di ciò che contribuisce al codice di alta qualità.

Tipi di revisori

Proprio come abbiamo criteri diversi per giudicare il software, anche le persone che fanno il giudizio sono diverse. Tutti abbiamo le nostre capacità e predilezioni. Alcuni potrebbero pensare che aderire agli standard locali sia estremamente importante, così come altri potrebbero essere più interessati all'utilizzo della memoria, alla copertura del codice dei test e così via. Vuoi tutti questi tipi di recensioni, perché nel loro insieme ti aiuteranno a scrivere codice migliore.

Una revisione tra pari è collaborazione, non un gioco di tag

Non sono sicuro che tu abbia il diritto di dire loro come fare il loro lavoro. A meno che tu non sappia diversamente con certezza, supponi che questa persona stia cercando di contribuire nel modo che ritiene opportuno. Tuttavia, se vedi margini di miglioramento o sospetti, forse non capiscono cosa ci si aspetta da una revisione tra pari, parla con loro .

Il punto di una revisione tra pari è coinvolgere i tuoi pari . Il coinvolgimento non sta gettando codice sopra un muro e aspettando che una risposta venga respinta. Il coinvolgimento sta lavorando insieme per rendere il codice migliore. Partecipa a una conversazione con loro.

Consigli

Verso la fine della tua domanda hai scritto:

come potrei incoraggiare i colleghi a cercare effettivamente difetti nel codice in equilibrio con evidenti errori estetici?

Ancora una volta, la risposta è comunicazione. Forse puoi chiedere loro "ehi, apprezzo che tu rilevi questi errori. Mi aiuterebbe moltissimo se potessi anche concentrarti su alcuni problemi più profondi come se sto strutturando il mio codice correttamente. So che ci vuole tempo, ma davvero Aiuto."

Su una nota più pragmatica, divido personalmente i commenti di revisione del codice in due campi e li esprimo in modo appropriato: cose che devono essere riparate e cose che sono più estetiche. Non impedirei mai il check in di un solido codice funzionante se ci fossero troppe righe vuote alla fine di un file. Lo sottolineo, tuttavia, ma lo farò con qualcosa del tipo "le nostre linee guida dicono di avere una sola riga vuota alla fine, e ne hai 20. Non è uno spettacolo, ma se hai una possibilità tu potrebbe voler aggiustarlo ".

Ecco qualcos'altro da considerare: potrebbe essere una tua piscia di animali domestici che fanno una revisione così superficiale del tuo codice. Può darsi che una loro piccola sbirciatina sia che tu (o qualche altro compagno di squadra che ottiene una recensione simile) sei sciatto rispetto agli standard di codifica della tua organizzazione, ed è così che hanno scelto di comunicarlo con te.

Cosa fare dopo la recensione

Infine, un po 'di consigli dopo la revisione: quando si commette un codice dopo una revisione, si potrebbe prendere in considerazione la possibilità di prendersi cura di tutte le cose cosmetiche in un commit e dei cambiamenti funzionali in un altro. Mescolare i due può rendere difficile differenziare i cambiamenti significativi da quelli insignificanti. Apporta tutte le modifiche cosmetiche e poi commetti con un messaggio come "cosmetico; nessuna modifica funzionale".

Le persone commentano la formattazione del codice e i refusi perché sono facili da individuare e non richiedono molto sforzo da parte loro.

Questa parte è facile da risolvere: quasi tutte le lingue dispongono di un linter o di uno strumento di controllo dello stile. Inseriscilo nel tuo processo di compilazione, in modo da non riuscire la compilazione in caso di spazio ridondante. Di conseguenza non ci saranno problemi di stile su cui commentare.

Far loro trovare problemi reali potrebbe essere una vera sfida. Non solo ciò richiede una particolare mentalità curiosa e orientata al dettaglio, ma anche una motivazione significativa.

E questa motivazione viene dall'esperienza. Esperienza nel provare a lavorare con codice scadente scritto da sviluppatori precedenti. Gli ingegneri senior ne hanno in abbondanza. Nuotare nell'oceano di merda ti dà il desiderio di non tornarci.

Se dovessi scegliere una cosa principale da controllare durante la revisione del codice, sarebbe la manutenibilità del codice. In ogni momento, gli sviluppatori che esaminano questo codice dovrebbero capirlo ed essere pronti a migliorarlo e modificarlo. Se non ha la minima idea di cosa stia succedendo qui, deve dirlo subito e il codice deve essere riscritto.

Ecco la risposta pratica:

Scenario 1 : sei il membro senior e qualcuno che può decidere la pratica

Chiamare una riunione e definire le regole e le linee guida per la revisione del codice. Fidati di me, le linee guida chiare funzionano meglio di qualsiasi sistema o formazione "d'onore". Chiarire che i problemi di formattazione del codice non devono essere sollevati affatto. Alcuni membri obietteranno. Ascoltali e poi chiedi loro di seguire le linee guida per i primi mesi come esperimento. Mostra disponibilità a cambiare se le attuali linee guida non funzionano.

Scenario 2 : non sei qualcuno che decide la pratica o sei un membro relativamente junior della squadra

La soluzione migliore è risolvere i problemi di revisione del codice fino a quando non riesci a raggiungere lo scenario 1 .

La semplice risposta per evitare commenti "banali" sulla revisione del codice è di insistere (per motivi di efficienza) che il revisore dovrebbe essere quello che li risolverà. Quindi, se il recensore scopre di aver perso (orrore!) Un fullstop o di aver scritto un commento in modo errato, dovrebbe semplicemente aggiustarlo e andare avanti.

Nella mia esperienza questo significa che:

• i tuoi revisori smettono di fare questi commenti di revisione relativamente inutili e di passarli indietro per essere corretti.
• solo la maggior parte dei revisori OCD li risolverà, il che significa che passerà la maggior parte delle recensioni. questo ha l'effetto a catena di richiedere agli sviluppatori di eseguire revisioni più sostanziali, quelli che segnalano curiosità perché non stanno effettivamente rivedendo il codice finiranno per giustificare il motivo per cui tutte le loro recensioni passano senza commenti.

Ad ogni modo, questo è un vantaggio. Il costo di una recensione fallita è elevato in termini di fermare uno sviluppatore su ciò che sta lavorando e rivisitare il suo codice, e la successiva revisione di follow-up. Se una recensione rileva la vera qualità del codice o problemi di architettura, questo costo vale ogni centesimo, ma non lo è pagare questo costo per curiosità.

Rivedere il processo di revisione

Oltre alle revisioni del codice, suggerirei di rivedere regolarmente anche il processo di revisione. Certamente ci sono molte cose che le persone possono imparare anche qui, ad esempio come fornire recensioni di codice adeguate.

Di solito alcuni dei ciclomotori sono solo inesperti e non sanno cosa cercare. Hanno bisogno di un po 'di guida non solo per quanto riguarda il loro codice, ma anche per fare utili revisioni del codice. Fornire feedback sulle recensioni porterà a un processo di apprendimento che (si spera) si tradurrà in recensioni migliori e codice migliore.

Successivamente, potrebbe essere una buona idea formalizzare (liberamente) un insieme di valori e criteri, ciò che l'organizzazione o il team percepisce come Good Code ™ e quali sono gli anti-schemi che dovrebbero essere evitati. Non si tratta di impostare sth. in concreto, ma per ottenere un consenso comune sulla qualità del codice sin dall'inizio .

Come qualcuno che è stato su entrambi i lati di questo (rivedere il codice scritto da altri, oltre a avere il codice che ho scritto rivisto), direi che ho tre categorie in cui rientra qualsiasi feedback. Bene, quattro, c'è anche il delizioso caso di "tutto va bene".

"Sarebbe bello, ma non ti bloccherà" (se tutti i feedback rientrano in questa categoria, potrei inviare la richiesta di unione con un "si fonderanno a XX: XX, a meno che tu non mi dica che vuoi risolverli" o "certo, vai avanti per fare il check-in, qualunque blocco il sistema lanci è stato disabilitato"):

• Dimenticare le interruzioni complete alla fine delle frasi (in stringhe di documenti o commenti). Grammatica grammatica in tutto ciò che non viene emesso dagli utenti in alcun modo forma o forma (di nuovo, stringhe di documenti e commenti)
• Codice che ha un modo più elegante, ma cosa c'è di comprensibile e idiomatico (probabilmente inserirò anche il mio suggerimento, quindi è facile lasciare o risolvere)

"Cose che devono essere riparate, ma mi fiderò di farlo" (se tutte le cose rientrano in questa o nella categoria precedente, risponderò con "correggi queste, mi unirò quando mi dirai ' re done "(e a quel punto probabilmente eseguirò rapidamente la scansione per vedere che nient'altro è spuntato)):

• Piccoli cavilli ("stai paragonando un booleano a true, è un po 'paranoico ...", ...)
• Violazioni di stile minori ("la guida di stile dice X, quello che hai fatto è al di fuori di quello; farei Y o Z, a seconda di come vuoi andare")
• Alcuni casi di test mancanti, che non dovrebbero essere difficili da scrivere

Infine, "le cose che sono problematiche, dovrò rivedere il tuo codice una volta risolti questi problemi" (se ce ne sono in questa categoria, ci dovrà essere un altro giro di revisione, quindi inserisci un commento che dice " ci sono anche un paio di cose minori, sarebbe bello vedere alcune di quelle riparate mentre ci sei "se c'è qualcosa dalle prime due categorie presenti):

• Si tratterebbe di "no, esiste davvero un modo MOLTO migliore per scrivere", "non stai calcolando ciò che ti aspetti, perché il tuo test unitario manca questi casi limite" e tutti gli altri problemi gravi.

Sembra che alcune persone abbiano dimenticato la domanda più importante: che cosa vuoi veramente ottenere con le revisioni del codice?

Lo scopo delle revisioni del codice è ottenere un codice privo di bug e gestibile più rapidamente. Le revisioni del codice raggiungono questo obiettivo in diversi modi: gli sviluppatori scrivono un codice migliore in primo luogo perché sanno che verrà esaminato, la conoscenza viene condivisa come parte del processo di revisione, i bug verranno trovati perché il revisore non è cieco ai propri errori come sviluppatori può essere.

Se vedi il processo di revisione come un'opportunità per mettere giù i tuoi colleghi o per creare lavoro per loro, allora stai sbagliando.