Dopo alcuni seri problemi di qualità nell'ultimo anno, la mia azienda ha recentemente introdotto revisioni del codice. Il processo di revisione del codice è stato rapidamente introdotto, senza linee guida o alcun tipo di elenco di controllo.

Un altro sviluppatore e io abbiamo scelto di rivedere tutte le modifiche apportate ai sistemi, prima che vengano unite nel trunk.

Siamo stati anche scelti come "Technical Lead". Ciò significa che siamo responsabili della qualità del codice, ma non abbiamo alcuna autorità per implementare cambiamenti nel processo, riassegnare gli sviluppatori o trattenere i progetti.

Tecnicamente possiamo negare l'unione, restituendola allo sviluppo. In realtà questo finisce quasi sempre con il nostro capo che richiede che venga spedito in tempo.

Il nostro manager è un MBA che si occupa principalmente di creare un programma di progetti imminenti. Mentre ci sta provando, non ha quasi idea di cosa faccia il nostro software da un punto di vista aziendale, e sta lottando per comprendere anche le richieste più elementari dei clienti senza spiegazioni da parte di uno sviluppatore.

Attualmente lo sviluppo avviene nelle filiali di sviluppo di SVN, dopo che lo sviluppatore pensa di essere pronto, riassegna il biglietto nel nostro sistema di biglietteria al nostro responsabile. Il manager quindi lo assegna a noi.

Le revisioni del codice hanno portato ad alcune tensioni all'interno del nostro team. Soprattutto alcuni dei membri più anziani mettono in dubbio i cambiamenti (vale a dire "L'abbiamo sempre fatto così" o "Perché il metodo dovrebbe avere un nome ragionevole, so cosa fa?").

Dopo le prime settimane la mia collega ha iniziato a lasciare che le cose scivolassero, per non creare problemi con i colleghi (mi ha detto lei stessa, che dopo che un cliente ha presentato una segnalazione di bug, sapeva di essere a conoscenza del bug, ma temeva che il lo sviluppatore sarebbe arrabbiato con lei per averlo sottolineato).

D'altra parte, ora sono noto per essere un asino per evidenziare problemi con il codice impegnato.

Non penso che i miei standard siano troppo alti.

La mia lista di controllo al momento è:

• Il codice verrà compilato.
• Esiste almeno un modo in cui il codice funzionerà.
• Il codice funzionerà con la maggior parte dei casi normali.
• Il codice funzionerà con la maggior parte dei casi limite.
• Il codice genererà una ragionevole eccezione se i dati inseriti non sono validi.

Ma accetto pienamente la responsabilità del modo in cui do feedback. Sto già dando punti concreti che spiegano perché qualcosa dovrebbe essere cambiato, a volte anche solo chiedendo perché qualcosa è stato implementato in un modo specifico. Quando penso che sia male, faccio notare che lo avrei sviluppato in un altro modo.

Quello che mi manca è la capacità di trovare qualcosa da indicare come "buono". Ho letto che si dovrebbe provare a mettere in cattive notizie cattive in buone notizie.

Ma faccio fatica a trovare qualcosa di buono. "Ehi, questa volta hai effettivamente commesso tutto quello che hai fatto" è più condiscendente che gentile o utile.

Revisione del codice di esempio

Ehi, Joe,

Ho alcune domande sulle tue modifiche nella classe Library \ ACME \ ExtractOrderMail.

Non ho capito perché hai contrassegnato "TempFilesToDelete" come statico? Al momento una seconda chiamata a "GetMails" genererebbe un'eccezione, perché si aggiungono i file ma non li si rimuovono mai, dopo averli eliminati. So che la funzione viene chiamata una sola volta per corsa, ma in futuro potrebbe cambiare. Potresti semplicemente renderlo una variabile di istanza, quindi potremmo avere più oggetti in parallelo.

... (Alcuni altri punti che non funzionano)

Punti minori:

• Perché "GetErrorMailBody" accetta un'eccezione come parametro? Ho dimenticato qualcosa? Non stai lanciando l'eccezione, basta passarla e chiamare "ToString". Perché?
• SaveAndSend Non è un buon nome per il metodo. Questo metodo invia messaggi di errore se l'elaborazione di un messaggio non è andata a buon fine. Potresti rinominarlo in "SendErrorMail" o qualcosa di simile?
• Per favore, non limitarti a commentare il vecchio codice, eliminalo completamente. Lo abbiamo ancora in sovversione.

Come trovare cose positive in una recensione di codice?

Dopo alcuni seri problemi di qualità nell'ultimo anno, la mia azienda ha recentemente introdotto revisioni del codice.

Fantastico, hai una reale opportunità di creare valore per la tua azienda.

Dopo le prime settimane la mia collega ha iniziato a lasciare che le cose scivolassero, per non creare problemi con i colleghi (mi ha detto lei stessa, che dopo una segnalazione di un bug è stata presentata da un cliente, che sapeva dell'errore, ma temeva che lo sviluppatore si arrabbierebbe con lei per averlo sottolineato).

Il tuo collega non dovrebbe fare la revisione del codice se non riesce a dire agli sviluppatori cosa c'è di sbagliato nel loro codice. Il tuo compito è trovare i problemi e risolverli prima che colpiscano i clienti.

Allo stesso modo, uno sviluppatore che intimidisce i colleghi chiede di essere licenziato. Mi sono sentito intimidito dopo una revisione del codice - l'ho detto al mio capo ed è stato gestito. Inoltre, mi piace il mio lavoro, quindi ho mantenuto il feedback, positivo e negativo. Come revisore, questo dipende da me, non da nessun altro.

D'altra parte, ora sono noto per essere un asino per evidenziare problemi con il codice impegnato.

Beh, è ​​un peccato, dici che sei discreto. Puoi trovare altro da elogiare, se hai altro da cercare.

Critica il codice, non l'autore

Fai un esempio:

Ho alcune domande sulle tue modifiche in

Evita di usare le parole "tu" e "tuo", ad esempio "modifica" invece.

Ho dimenticato qualcosa? [...] Perché?

Non aggiungere svolazzi retorici alle tue critiche. Non fare neanche battute. C'è una regola che ho sentito: "Se ti fa sentire bene dire, non dirlo, non va bene".

Forse stai lucidando il tuo ego a spese di qualcun altro. Tienilo solo ai fatti.

Alza l'asticella dando un feedback positivo

Alza il livello per lodare i tuoi colleghi sviluppatori quando soddisfano standard più elevati. Quindi questo significa che la domanda,

Come trovare cose positive in una recensione di codice?

è buono e vale la pena affrontarlo.

È possibile indicare dove il codice soddisfa gli ideali di pratiche di codifica di livello superiore.

Cerca loro di seguire le migliori pratiche e di continuare a alzare il tiro. Dopo che gli ideali più facili saranno attesi da tutti, ti consigliamo di smettere di lodarli e cercare pratiche di codifica ancora migliori per la lode.

Best practice specifiche della lingua

Se il linguaggio supporta la documentazione in codice, spazi dei nomi, funzioni di programmazione orientate agli oggetti o funzionali, è possibile richiamarli e congratularsi con l'autore per averli utilizzati ove appropriato. Queste questioni di solito rientrano nelle guide di stile:

• Soddisfa gli standard interni delle guide di stile linguistico?
• Incontra la guida di stile più autorevole per il linguaggio (che è probabilmente più severa di quella interna - e quindi ancora conforme allo stile interno)?

Buone pratiche generiche

Potresti trovare punti da elogiare su principi di codifica generici, sotto vari paradigmi. Ad esempio, hanno buoni unittest? Gli unittest coprono la maggior parte del codice?

Cercare:

• unit test che testano solo la funzionalità del soggetto - deridendo costose funzionalità che non sono destinate a essere testate.
• elevati livelli di copertura del codice, con test completi delle API e funzionalità semanticamente pubblica.
• test di collaudo e test del fumo che testano la funzionalità end-to-end, inclusa la funzionalità che viene derisa per i test unitari.
• buona denominazione, punti di dati canonici, quindi il codice è DRY (Don't Repeat Yourself), nessuna stringa o numero magico.
• denominazione delle variabili così ben fatta che i commenti sono in gran parte ridondanti.
• pulizie, miglioramenti oggettivi (senza compromessi) e opportuni refactoring che riducono le linee di codice e il debito tecnico senza rendere il codice completamente estraneo agli scrittori originali.

Programmazione Funzionale

Se la lingua è funzionale o supporta il paradigma funzionale, cerca questi ideali:

• evitando i globi e lo stato globale
• utilizzando chiusure e funzioni parziali
• piccole funzioni con nomi leggibili, corretti e descrittivi
• punti di uscita singoli, riducendo al minimo il numero di argomenti

Programmazione orientata agli oggetti (OOP)

Se la lingua supporta OOP, puoi elogiare l'uso appropriato di queste funzionalità:

• incapsulamento: fornisce un'interfaccia pubblica ben definita e piccola e nasconde i dettagli.
• eredità - codice riutilizzato in modo appropriato, forse attraverso i mixin.
• polimorfismo: le interfacce sono definite, forse classi base astratte, funzioni scritte per supportare il polimorfismo parametrico.

sotto OOP, ci sono anche principi SOLID (forse una ridondanza delle funzionalità OOP):

• singola responsabilità - ogni oggetto ha un stakeholder / proprietario
• aperto / chiuso - non modifica l'interfaccia degli oggetti stabiliti
• Sostituzione di Liskov - le sottoclassi possono essere sostituite da casi di genitori
• segregazione delle interfacce - interfacce fornite dalla composizione, forse mixin
• inversione di dipendenza - interfacce definite - polimorfismo ...

Principi di programmazione Unix :

I principi Unix sono modularità, chiarezza, composizione, separazione, semplicità, parsimonia, trasparenza, solidità, rappresentazione, minima sorpresa, silenzio, riparazione, economia, generazione, ottimizzazione, diversità ed estensibilità.

In generale, questi principi possono essere applicati sotto molti paradigmi.

I tuoi criteri

Questi sono troppo banali - mi sentirei condannato se lodato per questo:

• Il codice verrà compilato.
• Esiste almeno un modo in cui il codice funzionerà.
• Il codice funzionerà con la maggior parte dei casi normali.

D'altra parte, si tratta di elogi abbastanza alti, considerando ciò che sembra avere a che fare, e non esiterei a lodare gli sviluppatori per aver fatto questo:

• Il codice funzionerà con la maggior parte dei casi limite.
• Il codice genererà una ragionevole eccezione se i dati inseriti non sono validi.

Annotare le regole per passare la revisione del codice?

Questa è una grande idea in teoria, tuttavia, mentre di solito non rifiuterei il codice per una cattiva denominazione, ho visto una denominazione così cattiva che avrei rifiutato il codice con le istruzioni per risolverlo. Devi essere in grado di rifiutare il codice per qualsiasi motivo.

L'unica regola che mi viene in mente per il rifiuto del codice è che non c'è nulla di così eclatante da tenerlo fuori produzione. Un nome davvero brutto è qualcosa che sarei disposto a tenere fuori produzione - ma non puoi renderlo una regola.

Conclusione

Puoi lodare le migliori pratiche seguite sotto molteplici paradigmi, e probabilmente sotto tutti, se la lingua li supporta.

Non preoccuparti di scegliere qualcosa di buono a meno che non sia un solido esempio conciso ed è direttamente correlato al problema focalizzato.

Non lo ricopro di zucchero - dai suoni di ciò che hai a che fare con almeno una persona che è insicura delle proprie capacità e che gestisce le sfide del proprio lavoro in modo immaturo. Probabilmente sono anche cattivi nel loro lavoro - un buon sviluppatore dovrebbe sempre essere disposto a riflettere su se stesso, a prendere critiche costruttive ed essere aperto a cambiare i loro modi.

Ora che è fuori nell'aria, parliamo di te. Indipendentemente se pensi di essere ragionevole, devi fare molta attenzione con persone come questa per far rotolare la palla. Ho trovato che il modo migliore per affrontare queste persone è stare molto attenti a come pronunci le cose.

Assicurati di dare la colpa al codice e non all'autore . Concentrati sull'unica questione a portata di mano piuttosto che sulla cacca di montagna che è la tua base di codice, che potrebbero aver avuto una mano significativa nella creazione e sarebbero visti come un ulteriore attacco personale. Scegli le tue battaglie inizialmente, concentrati su questioni critiche che si manifestano ai tuoi utenti in modo da non lanciare una serie di critiche alla persona che li porta a respingere tutto ciò che stai dicendo.

Il linguaggio del corpo e il tono sono importanti se parli con loro di persona, sii chiaro con quello che stai dicendo e assicurati di non parlargli o di respingere le loro capacità tecniche. Molto probabilmente saranno sulla difensiva subito dopo la mazza, quindi devi sistemare le loro preoccupazioni invece di confermarle. Devi essere consapevole di questa conversazione senza essere troppo ovvio in modo che inconsciamente pensino che tu stia dalla loro parte e, si spera, accettano di dover apportare i cambiamenti che sono stati portati all'attenzione.

Se questo non funziona, puoi iniziare a diventare un po 'più aggressivo. Se il prodotto è eseguibile da una sala conferenze, visualizzalo sul proiettore durante la revisione del codice e mostra in prima persona il bug, è meglio se un manager è proprio lì, quindi la persona non può tornare indietro. Questo non è per vergognarli, ma per costringerli ad accettare che il problema è reale per l'utente e che deve essere risolto, anziché solo una lamentela che hai con il loro codice.

Alla fine, se non vai da nessuna parte, sei stanco di trattare la persona come uno studente dell'asilo e la direzione è completamente inconsapevole del problema, o si riflette male sulle tue prestazioni come revisore del codice o ti preoccupi del benessere del tuo società e / o prodotto, devi iniziare a parlare con il tuo capo del loro comportamento. Sii il più specifico e impersonale possibile: fai valere il caso in cui la produttività e la qualità ne soffrono.

Le revisioni del codice possono essere tossiche, sprecare tempo, volontà di vivere guerre di secchioni. Basta guardare la divergenza di opinioni su cose come codice pulito rispetto a commenti, convenzioni di denominazione, test di unità e integrazione, strategie di verifica, RESTfulness, ecc., Ecc.

L'unico modo per evitarlo è scrivere le regole per passare una revisione del codice.

Quindi non è una persona che non riesce o approva il check-in. Stanno semplicemente controllando che le regole siano state seguite.

E poiché sono scritti in anticipo, quando scrivi il tuo codice puoi seguire le regole e non devi spiegare il tuo ragionamento o avere argomenti in seguito.

Se non ti piacciono le regole, organizza un incontro per cambiarle.

Non vorrei ricoprire il tuo feedback perché potrebbe essere considerato condiscendente.

Secondo me, la migliore pratica è quella di concentrarsi sempre sul codice e mai sull'autore.

È una revisione del codice , non una recensione dello sviluppatore , quindi:

• "Questo ciclo while potrebbe non finire mai", non "Il tuo ciclo potrebbe non finire mai"
• "È necessario un caso di test per lo scenario X", non "Non hai scritto il test per coprire questo scenario"

È anche molto importante applicare la stessa regola mentre si parla della recensione con altri:

• "Anne, cosa ne pensi di questo codice?", Non "Anne, cosa ne pensi del codice di Jon?"

La revisione del codice non è il momento per una revisione delle prestazioni, ma deve essere eseguita separatamente.

Sono sorpreso che non sia stato menzionato finora in nessuna risposta, e forse la mia esperienza con le revisioni del codice è insolita, ma:

Perché stai esaminando l'intera richiesta di unione in un singolo messaggio?

La mia esperienza con le revisioni del codice è tramite GitLab; Ho sempre immaginato che altri strumenti di revisione del codice funzionassero in modo simile.

Quando sto dando una recensione del codice, commento specifiche linee individuali del diff. Questo è estremamente improbabile che venga ricevuto come critica personale, perché è un commento sul codice - ed è effettivamente visualizzato come commento sul codice, mostrato direttamente sotto il codice su cui è un commento.

Posso anche commentare l'intera richiesta di unione e spesso lo faccio. Ma punti specifici possono essere evidenziati su linee specifiche del diff. (Inoltre, quando viene aggiunto un nuovo commit in modo tale che il diff cambi, i commenti sul "diff obsoleto" vengono nascosti per impostazione predefinita.)

Con questo flusso di lavoro, le revisioni del codice diventano molto più modulari e meno coerenti. Una riga di una revisione del codice può semplicemente dire:

Bel approccio, avvolgendolo in una funzione dedicata!

O potrebbe dire

Questo nome di oggetto non corrisponde realmente allo scopo dell'oggetto; forse potremmo usare un nome come 'XYZ' invece?

O se ci sono problemi importanti con una sezione, potrei scrivere:

Vedo che questo codice funziona (e vedo perché funziona) ma richiede uno studio mirato per capirlo. Potresti per favore trasformarlo in funzioni separate in modo che sia più facile da mantenere in futuro?

(Esempio: la funzione ABC in realtà sta facendo tre cose qui: abbagliare il foo, escludere il boz e schioccare lo zorf. Quelle potrebbero essere tutte funzioni separate.)

Dopo aver scritto tutto quanto sopra, posso fare un commento di riepilogo sull'intera richiesta di unione, qualcosa del tipo:

Questa è una nuova grande funzionalità e sarà davvero utile una volta unita. Potete per favore ripulire la denominazione della funzione e gestire il refactoring menzionato nei singoli commenti che ho fatto, e poi farmi sapere di rivederlo? :)

Anche se la richiesta di unione è una colazione completa per cani, i singoli commenti possono essere semplici. Ce ne saranno solo altri. Quindi il commento di sintesi potrebbe dire:

Mi dispiace, ma questo codice non è davvero all'altezza. Esistono molti casi limite (come dettagliato nei singoli commenti) che verranno gestiti in modo errato e daranno una brutta esperienza all'utente, o addirittura la corruzione dei dati in un caso. (Vedere il commento su commit 438a95fb734.) Anche alcuni casi d'uso normali comporteranno prestazioni delle applicazioni estremamente scadenti (specifiche annotate nei singoli commenti sul diff per somefile.c).

Per essere pronta per la produzione, questa funzione avrà bisogno di una riscrittura completa con maggiore attenzione a ciò che i presupposti sono sicuri da fare in ogni punto del flusso. (Suggerimento: nessuna ipotesi è sicura a meno che non sia stata verificata.)

Sto chiudendo la richiesta di unione in attesa di una riscrittura completa.

Riepilogo: rivedere gli aspetti tecnici del codice come commenti su singole righe di codice. Quindi riepilogare tali commenti in un commento complessivo sulla richiesta di unione. Non diventare personale, tratta solo i fatti e secondo te sul codice , non sul programmatore. E basa la tua opinione su fatti, osservazioni accurate e comprensione.

Sono davvero sorpreso che nessuno l'abbia preso in considerazione, ma c'è qualcosa che non va nella recensione del campione pubblicata.

Semplicemente non vi è alcun motivo per cui si dovrebbe rivolgersi direttamente a Joe. Che Joe risolva i suoi fallimenti non è affar tuo. Che qualcuno lo faccia, sono affari tuoi. La tua preoccupazione è la qualità del codice. Quindi, invece di scrivere richieste / ordini / richieste (che, se fossi Joe, potrei semplicemente rifiutare perché non sei legittimo per questo), rimanere nel tuo ruolo e scrivere un semplice elenco di todo anonimo.

Cercare di essere onesti nel dare punti positivi e negativi non è solo impossibile, ma completamente fuori dal tuo ruolo.

Ecco un esempio di riformulazione con contenuti tratti dalla tua recensione:

• Prima di inserire le modifiche nella classe Library \ ACME \ ExtractOrderMail, dobbiamo risolvere alcuni problemi.
• A meno che non mi sia perso qualcosa, "TempFilesToDelete" non dovrebbe essere statico.
• In futuro, potremmo chiamare la funzione più di una volta per corsa, ecco perché abbiamo bisogno (cosa deve essere fatto qui).
• Devo capire perché "GetErrorMailBody" accetta un'eccezione come parametro. (e, sono al limite qui, perché ormai dovresti già avere una conclusione )
• SaveAndSend dovrebbe essere rinominato per adattarsi meglio al suo comportamento, come ad esempio "SendErrorMail"
• Il codice commentato deve essere eliminato per motivi di leggibilità. Usiamo la sovversione per eventuali rollback.

Se formulerai la recensione in questo modo, non importa quanto il lettore ti odia personalmente, tutto ciò che può vedere qui sono le note sui miglioramenti che qualcuno deve portare avanti in seguito. Chi ? Quando ? A nessuno importa. Che cosa ? Perché ? CHE dovresti dire.

Ora, affronterai la ragione stessa per cui le revisioni del codice stanno aumentando la tensione eliminando il fattore umano dall'equazione.

L'intero punto della revisione del codice è trovare problemi. Se c'è qualche bug, la cosa migliore che puoi fare è scrivere un caso di test che non funziona.

Il tuo team (manager) dovrebbe comunicare che la produzione di bug fa parte del gioco, ma trovarli e risolverli salverà il lavoro di tutti .

Potrebbe essere utile tenere riunioni regolari (squadra o coppia) e affrontare un paio di problemi. Il programmatore originale non ha introdotto intenzionalmente problemi, e talvolta potrebbe pensare che fosse abbastanza buono (e talvolta potrebbe anche esserlo). Ma avere quel secondo paio di occhi offre una visione completamente nuova, e potrebbe imparare molto guardando i problemi.

È davvero una cosa culturale e ha bisogno di molta fiducia e comunicazione. E il tempo di lavorare con i risultati.

Penso che la cosa positiva da fare sarebbe ottenere un consenso sugli standard di codifica prima di fare recensioni. Altri tendono a comprare di più in qualcosa quando hanno input.

Per qualcosa come le convenzioni di denominazione, chiedi agli altri se questo è importante. La maggior parte degli sviluppatori concorderà soprattutto con i loro colleghi. Chi vuole essere la persona che non vuole essere d'accordo con qualcosa di così prevalente nel mondo della programmazione? Quando inizi il processo selezionando il codice di qualcuno e sottolineando il difetto, diventano molto difensivi. Una volta stabiliti gli standard, ci sarà disaccordo sull'interpretazione o su ciò che è considerato "abbastanza buono", ma stai meglio di quanto lo sia ora.

Un'altra parte di questo processo è determinare come le revisioni del codice gestiranno le obiezioni. Questo non può diventare un dibattito senza fine. Ad un certo punto, qualcuno deve prendere la decisione. Forse ci può essere una terza parte per essere il giudice o il revisore ottiene tutto il potere. Le cose da fare dovrebbero essere l'obiettivo.

Il pezzo finale di questo è far sapere a tutti che le Recensioni di Codice non erano la tua idea, rimarranno, quindi tutti dovrebbero fare uno sforzo per trarne il meglio. Se tutti si sentono impotenti, forse possono essere autorizzati a rivedere il tuo codice?

Speriamo che un risultato misurabile per la gestione sia quello di limitare bug, reclami dei clienti, ritardi ecc. Altrimenti, qualcuno ha appena sentito la parola d'ordine "revisione del codice" e ha pensato che se lo aggiungessero al tuo processo, i miracoli avverranno senza molto tempo, energia e lo sforzo messo in questo.

Questo può essere duro, ma non preoccuparti di dare un buon feedback se non c'è niente di buono da misurare.

Tuttavia, in futuro, quando i tuoi sviluppatori inizieranno a migliorare il loro codice, è allora che vorrai dare loro un buon feedback. Ti consigliamo di evidenziare i miglioramenti del codice e di sottolineare anche i vantaggi per il team nel suo insieme. Quando inizi a vedere miglioramenti, lo faranno anche loro e le cose dovrebbero lentamente iniziare a capitare.

Un'altra cosa; ci può essere un'aria difensiva perché si sentono come se non avessero voce in capitolo. Perché non lasciare che si rivedano reciprocamente il codice? Poni loro domande specifiche e cerca di coinvolgerle. Non dovresti essere tu contro di loro; dovrebbe essere uno sforzo di squadra.

1. Cosa cambieresti di questo codice se avessi il tempo?
2. Come miglioreresti quest'area della base di codice?

Chiedilo ora e chiedilo tra sei mesi. C'è un'esperienza di apprendimento qui.

Il punto principale: non dare lode in termini di codice dove non è garantito, ma riconosci gli sforzi e riconosci sicuramente il miglioramento. Cerca di trasformare le recensioni in un esercizio di gruppo anziché in un contraddittorio.

Qualità senza tensione

Hai chiesto come puoi trovare cose positive da dire sul codice, ma la tua vera domanda è come evitare "tensioni all'interno del [tuo] team" affrontando "seri problemi di qualità".

Il vecchio trucco del sandwich "cattive notizie in buone notizie" potrebbe ritorcersi contro. È probabile che gli sviluppatori lo vedano per quello che è: un inganno.

La tua organizzazione Problemi top-down

I tuoi capi ti hanno incaricato di garantire la qualità. Hai creato un elenco di criteri per la qualità del codice. Ora, vuoi idee per il rinforzo positivo da fornire al tuo team.

Perché chiederci cosa devi fare per rendere felice la tua squadra? Hai pensato di chiedere alla tua squadra?

Sembra che tu stia facendo del tuo meglio per essere gentile. Il problema non è come stai consegnando il tuo messaggio. Il problema è che la comunicazione è stata a senso unico.

Costruire una cultura della qualità

Una cultura della qualità deve essere coltivata per crescere dal basso verso l'alto.

Fai sapere al tuo capo che sei preoccupato che la qualità non stia migliorando abbastanza velocemente e che vuoi provare ad applicare alcuni consigli da The Harvard Business Review .

Incontra la tua squadra. Modella i comportamenti che vuoi vedere nella tua squadra: umiltà, rispetto e impegno per migliorare.

Di 'qualcosa del tipo: "Come sai, [collaboratore] e io abbiamo avuto il compito di garantire la qualità del codice, per prevenire il tipo di problemi di produzione che abbiamo subito di recente. Personalmente non penso di aver risolto questo problema. Penso che il mio più grande errore non sia stato coinvolgere tutti voi all'inizio. [collaboratore] ed io siamo ancora responsabili nei confronti della direzione per la qualità del codice, ma andando avanti, stiamo tutti insieme nello sforzo di qualità ".

Ottieni idee dal team sulla qualità del codice. (Una lavagna sarebbe di aiuto.) Assicurati che i tuoi requisiti entrino lì entro la fine. Offri le tue intuizioni in modi rispettosi e fai le domande quando necessario. Siate disposti a essere sorpresi di ciò che la vostra squadra ritiene importante. Sii flessibile, senza compromettere le esigenze aziendali.

(Se hai un vecchio codice di cui ti vergogni, potresti trottarlo, incoraggiando tutti a essere sinceri. Alla fine, fai sapere alla gente che l'hai scritto. Modella la reazione matura che speri quando gli altri ricevono critiche costruttive. )

Recensioni di codice collaborativo

Non ho lavorato in un posto come tu descrivi, dove alcuni programmatori senior riesaminano tutto il codice e apportano correzioni. Non c'è da stupirsi che la gente risponda come se fossi un insegnante che fa dei segni rossi sui loro fogli.

Se puoi vendere l'idea alla direzione, inizia a fare revisioni del codice dei pari . È meglio farlo in piccoli gruppi, incluso te o l'altro sviluppatore responsabile. Garantire che tutti siano trattati con rispetto.

Un importante obiettivo del peer review code è garantire che il codice possa essere compreso da tutti i membri del team. Considera il tuo esempio di nomi di funzioni poco chiari: sentire da uno sviluppatore più giovane che trovano confuso il nome della funzione può essere più facile da accettare di un'altra "correzione" da parte dello sviluppatore senior.

La qualità è un viaggio

Un'altra cosa da fare è eliminare qualsiasi idea che una revisione del codice sia una cosa pass / fail. Tutti dovrebbero aspettarsi di apportare alcune modifiche dopo una revisione del codice. (E il tuo compito è assicurarti che accadano.)

Ma se non funziona ...

Supponiamo che tu faccia qualche passo avanti stabilendo una cultura della qualità. Potresti ancora non avere tutti a bordo. Se qualcuno non ha ancora un programma di qualità, ora il problema è che non si stanno adattando alla squadra, piuttosto che c'è un problema tra voi due. Se devono essere espulsi dalla squadra, il resto della squadra comprenderà meglio i motivi.

Ci scusiamo per l'ennesima risposta lunga, ma non credo che gli altri abbiano affrontato completamente l'elemento umano di questo problema.

a volte anche solo chiedendo perché qualcosa è stato implementato in un modo specifico. Quando penso che sia male, faccio notare che lo avrei sviluppato in un altro modo.

Il problema con "Perché l'hai implementato in questo modo?" è che metti subito lo sviluppatore sulla difensiva. La domanda stessa può implicare ogni sorta di cose a seconda del contesto: sei troppo stupido per pensare a una soluzione migliore? Questo è il meglio che sai fare? Stai cercando di rovinare questo progetto? Ti preoccupi anche della qualità del tuo lavoro? ecc. Chiedere "perché" il codice è stato sviluppato in un certo modo sarà solo conflittuale e ciò sovverte qualsiasi intento pedagogico che il tuo commento avrebbe potuto avere.

Allo stesso modo "Avrei fatto diversamente ..." è anche conflittuale, perché l'immediato pensiero che lo sviluppatore avrà è " Beh, l'ho fatto in questo modo ... Hai un problema con esso? " E ancora, è più conflittuale di deve essere e allontana la discussione dal miglioramento del codice.

Esempio:

Invece di chiedere "Perché hai scelto di non utilizzare la variabile costante per questo valore?", Indica semplicemente "Questo valore hardcoded deve essere sostituito con la costante XYZnel file Constants.h" Porre la domanda suggerisce che lo sviluppatore ha attivamente scelto di non utilizzare il costante già definita, ma è del tutto possibile che non sapessero nemmeno che esistesse. Con una base di codice abbastanza grande, ci saranno molte cose che ogni sviluppatore non sa. Questa è semplicemente una buona opportunità di apprendimento per quello sviluppatore per conoscere le costanti del progetto.

C'è una linea sottile per camminare con le recensioni del codice: non è necessario ricoprire con zucchero tutto ciò che dici, non è necessario inserire cattive notizie con buone notizie e non è necessario attenuare il colpo. Potrebbe essere la cultura in cui mi trovo, ma i miei colleghi e io non ci complimentiamo mai a vicenda nelle revisioni del codice: le parti del codice che sviluppiamo che sono prive di difetti sono abbastanza un complimento. Quello che devi fare è identificare il difetto che vedi e forse dare un motivo (il perché è meno utile quando è ovvio / semplice).

Buono:

• "Il nome di questa variabile deve essere modificato per corrispondere al nostro standard di codifica."

• "La 'b' in questo nome di funzione deve essere maiuscola per essere PascalCase."

• "Il codice di questa funzione non è rientrato correttamente."

• "Questo codice è un duplicato del codice trovato ABC::XYZ()e dovrebbe invece utilizzare quella funzione."

• "Dovresti usare prova con le risorse in modo che le cose siano garantite per essere chiuse correttamente in questa funzione, anche se si verificano errori." [Ho solo aggiunto un link qui in modo che gli utenti non Java sappiano cosa significa provare con le risorse]

• "Questa funzione deve essere rifattorizzata per soddisfare i nostri standard di complessità n-path".

Male:

• " Penso che potresti migliorare questo codice modificando il nome della variabile in modo che corrisponda al nostro standard"

• " Forse sarebbe meglio usare try-with-resource per chiudere correttamente le cose in questa funzione"

• " Potrebbe essere desiderabile dare un'altra occhiata a tutte le condizioni di questa funzione. La complessità del percorso N è superiore alla massima complessità consentita dal nostro standard."

• "Perché i rientri qui sono 2 spazi anziché i 4 del nostro standard?"

• "Perché hai scritto una funzione che rompe il nostro standard di complessità n-path?"

Nelle cattive dichiarazioni le parti in corsivo sono cose che le persone comunemente usano quando vogliono attenuare il colpo, ma tutto ciò che fa realmente in una revisione del codice è farti sembrare incerto di te stesso. Se tu, il revisore, non sei sicuro di come migliorare il codice, allora perché qualcuno dovrebbe ascoltarti?

Le "buone" dichiarazioni sono schiette, ma non accusano lo sviluppatore, non attaccano lo sviluppatore, non sono conflittuali e non si chiedono perché il difetto esista. Esiste; ecco la soluzione. Non sono certamente così conflittuali come l'ultima domanda "perché".

Il problema che vedi è: gli sviluppatori non sono contenti che il loro codice sia criticato. Ma non è questo il problema. Il problema è che il loro codice non è buono (supponendo ovviamente che le recensioni del codice siano buone).

Se agli sviluppatori non piace che il loro codice attiri critiche, allora la soluzione è semplice: scrivere codice migliore. Dici di avere seri problemi con la qualità del codice; ciò significa che è necessario un codice migliore.

"Perché il metodo dovrebbe avere un nome ragionevole, so cosa fa?" è qualcosa che trovo particolarmente inquietante. Sa cosa fa, o almeno lo dice, ma io no. Qualsiasi metodo non dovrebbe avere solo un nome ragionevole, dovrebbe avere un nome che renda immediatamente chiaro al lettore ciò che fa. Potresti voler visitare il sito Web di Apple e cercare un video WWDC sulle modifiche da Swift 2 a Swift 3 - un numero enorme di modifiche apportate solo per rendere tutto più leggibile. Forse quel tipo di video potrebbe convincere i tuoi sviluppatori che gli sviluppatori che sono molto più intelligenti di loro ritengono che i nomi dei metodi intuitivi siano molto, molto importanti.

Un altro elemento inquietante è stato il tuo collega che ha detto "mi ha detto se stessa, che dopo che un cliente ha segnalato un bug bug, che era a conoscenza del bug, ma temeva che lo sviluppatore si sarebbe arrabbiato con lei per averlo sottolineato". V'è la possibilità che ci sia un malinteso, ma se uno sviluppatore si arrabbia se vi segnalo un bug per loro, che è male.

Non sarei d'accordo con il metodo di revisione del codice che hai descritto. Due membri del personale che escono in una "stanza chiusa" e escono con critiche istituzionalizzano il tipo di nozione contraddittoria che dovrebbero essere evitate da buone recensioni di codice .

Rendere la revisione del codice un'esperienza positiva nella misura del possibile è essenziale per riuscire. Il primo passo è rimuovere la nozione contraddittoria di revisione. Trasformalo in un evento di gruppo settimanale o bisettimanale ; assicurarsi che tutti sappiano che sono invitati a partecipare. Ordina in pizza o sandwich o altro. Non chiamarlo nemmeno una "revisione del codice" se questo provoca connotazioni negative. Trova qualcosa da festeggiare, incoraggiare, condividere, anche se non è altro che il progresso attraverso lo sprint o l'iterazione corrente. A turno, assegnando la leadership alla revisione.

Rendere il processo uno sforzo per servire il prodotto e le persone. Se sono fatti in modo costruttivo, positivo, in cui le buone tecniche o schemi sono condivisi e incoraggiati proprio come quelli poveri sono scoraggiati - tutti ne traggono beneficio. Tutti vengono allenati in pubblico. Se hai un programmatore problematico che non lo "capisce", dovrebbero essere indirizzati privatamente e separatamente - mai di fronte al gruppo più ampio. È separato dalla revisione del codice.

Se hai difficoltà a trovare qualcosa di "buono" da sollevare, questo per me fa una domanda: se si stanno facendo progressi nel progetto e le persone stanno lavorando, quel progresso in sé e per sé è qualcosa da festeggiare. Se non trovi davvero nulla di buono, ciò implica che tutto ciò che è stato fatto dall'ultima recensione è cattivo o niente di meglio che neutrale . È davvero così?

Per quanto riguarda i dettagli, gli standard comuni sono essenziali. Dare a tutti un interesse in ciò che viene fatto. E consentire l'integrazione di tecniche nuove e migliori nella tua base di codice. L'incapacità di garantire che le vecchie abitudini non vengano mai eliminate con il pretesto di "l'abbiamo sempre fatto in quel modo".

Il punto in tutto ciò è che le revisioni del codice hanno un po 'di brutto rap perché sono mal implementate, usate come martelli per sminuire i programmatori meno esperti o meno abili, e questo è al servizio di nessuno. Anche i manager che li usano in questo modo non sono probabilmente manager molto efficaci. Buone recensioni di codice in cui tutti sono partecipanti servono tutti: il prodotto, i dipendenti e l'azienda.

Ci scusiamo per la lunghezza del post, ma essendo stato in un gruppo in cui la revisione del codice è stata in gran parte ignorata, ha portato a un'eredità di codice non mantenibile e solo una ristretta gamma di sviluppatori in grado anche se gli è stato permesso di apportare modifiche a una base di codice vecchia di anni. Era un percorso che avrei scelto di non percorrere di nuovo.

Il paradosso del buon codice è che non si distingue affatto e sembra che sia molto semplice e facile da scrivere. Mi piace molto l'esempio del giocatore di biliardo da questa risposta . Nelle revisioni del codice, questo rende davvero facile la lettura, a meno che non si tratti di un refattore da un codice errato.

Faccio un punto per cercarlo. Se sto rivedendo il codice e ho esaminato un file che era così facile da leggere che sembra ingannevolmente facile da scrivere, ho appena lanciato un breve "Mi piace come i metodi qui sono brevi e puliti" o qualunque cosa sia appropriata .

Inoltre, dovresti dare l'esempio. Dovresti insistere affinché anche il tuo codice venga rivisto e devi modellare il modo in cui vuoi che il tuo team si comporti quando riceve la correzione. Ancora più importante, dovresti ringraziare sinceramente le persone per il feedback. Questo fa più differenza di qualsiasi feedback unilaterale che puoi dare.

Sembra che il vero problema sia che sono solo due le persone che stanno facendo tutte le revisioni del codice, di cui sei solo tu a prenderle sul serio, che ti ha portato a finire in una situazione sfortunata con molte responsabilità e molte pressione da parte degli altri membri del team.

Un modo migliore sarebbe quello di distribuire la responsabilità di eseguire le revisioni del codice sul team e far partecipare tutti quanti, ad esempio lasciando agli sviluppatori la scelta di chi rivedere il proprio codice. Questo è qualcosa che lo strumento di revisione del codice dovrebbe supportare.

L'ho visto accadere in prima persona e voglio metterti in guardia dalle risposte sfidate dall'intelligenza emotiva : possono uccidere intere squadre. A meno che tu non voglia reclutare, formare e normalizzare nuovi sviluppatori ogni anno, è essenziale creare un rapporto positivo con i tuoi colleghi. Dopotutto, non è il punto di fare queste recensioni per migliorare la qualità del codice e promuovere una cultura in cui la qualità del codice è più elevata in primo luogo? Direi che è davvero parte del tuo lavoro fornire rinforzi positivi come mezzo per integrare questo sistema di revisione del codice nella cultura del team.

Ad ogni modo, sembra che tu debba rivedere il tuo sistema di Code Review. In questo momento, dai suoni di tutto ciò che è nel tuo processo di revisione è, o può essere interpretato, soggettivo piuttosto che oggettivo. È facile farsi male quando si ha la sensazione che qualcuno stia semplicemente separando il codice perché non gli piace, piuttosto che avere un motivo per cui possono citare quando qualcosa non si adatta alle linee guida. In questo modo, è facile rintracciare e "celebrare" miglioramenti positivi nella qualità del codice (rispetto al sistema di revisione) in qualunque modo sia appropriato per la cultura del vostro ufficio.

I responsabili tecnici devono riunirsi al di fuori di una sessione di revisione e redigere una guida per la codifica / Elenco di controllo per la revisione del codice e devono essere rispettati e citati durante la revisione. Questo dovrebbe essere un documento vivente che può essere aggiornato e perfezionato man mano che il processo si sviluppa. Queste riunioni del Lead Tech dovrebbero anche essere quando si dovrebbe verificare la discussione sul "Modo in cui abbiamo sempre fatto le cose" rispetto a "Nuove e migliorate modalità di fare le cose", senza che lo sviluppatore venga esaminato sentendo che il disaccordo è il risultato del loro codice. Una volta che la linea guida iniziale è stata più o meno appianata, un altro modo per rafforzare positivamente gli sviluppatori è quello di chiedere il loro feedback e quindi effettivamente agire su di esso ed evolvere il processo come una squadra, questo fa miracoli per renderli più veloci per iniziare a rivedere il codice per gli onboard in modo da non rimanere bloccati a fare recensioni fino al ritiro.

Locali ...

I programmatori risolvono i problemi. Siamo condizionati per iniziare il debug quando viene presentato un problema o un errore.

Il codice è un supporto in formato struttura. Il passaggio a una narrazione in formato paragrafo per il feedback introduce una disconnessione che deve essere tradotta. Inevitabilmente qualcosa viene perso o frainteso. Inevitabilmente, il revisore non parla nella lingua del programmatore.

I messaggi di errore generati dal computer vengono raramente messi in discussione e mai considerati un affronto personale.

Gli articoli di revisione del codice sono messaggi di errore generati dall'uomo. Hanno lo scopo di cogliere i casi limite che mancano ai programmatori e gli strumenti automatizzati, nonché gli inevitabili effetti collaterali su altri programmi e dati.

Conclusioni ...

Pertanto, più elementi di revisione del codice possono essere incorporati in strumenti automatizzati, migliore sarà la loro ricezione.

L'avvertenza è che, per rimanere indiscutibili, tali strumenti devono essere continuamente aggiornati, di solito giornalmente o settimanalmente, per essere conformi ad ogni modifica di procedure, standard e pratiche. Quando un manager o un team di sviluppatori decide di apportare una modifica, gli strumenti devono essere modificati per imporlo. Gran parte del lavoro del revisore del codice diventa quindi il mantenimento delle regole negli strumenti.

Feedback sulla revisione del codice di esempio ...

Una riscrittura dell'esempio dato che incorpora queste tecniche:

• Soggetto:

  • Libreria \ ACME \ ExtractOrderMail Class.

• Problema di principio ...

  • TempFilesToDelete è statico
    • Le chiamate successive a GetMails generano un'eccezione poiché i file vengono aggiunti ma non rimossi mai dopo l'eliminazione. Anche se solo una chiamata ora, le prestazioni potrebbero essere migliorate in futuro con un po 'di parallelismo.
    • TempFilesToDelete come variabile di istanza consentirebbe di utilizzare più oggetti in parallelo.
• Questioni secondarie ...
  • GetErrorMailBody ha un parametro di eccezione
    • Dal momento che non genera un'eccezione stessa e la passa a ToString, è necessario?
  • Salva e invia nome
    • L'e-mail può o non può essere utilizzata per segnalarlo in futuro e questo codice contiene la logica generale per l'archiviazione di una copia persistente e la segnalazione di eventuali errori. Un nome più generico consentirebbe tali cambiamenti previsti senza modificare i metodi dipendenti. Una possibilità è StoreAndReport.
  • Commentando il vecchio codice
    • Lasciare una riga commentata e contrassegnata OBSOLETE può essere molto utile nel debug, ma un "muro di commenti" può anche oscurare errori nel codice adiacente. Lo abbiamo ancora in Subversion. Forse solo un commento che fa riferimento esattamente dove in Subversion?

Se non hai niente di carino da dire sul codice esistente (che sembra comprensibile), prova a coinvolgere lo sviluppatore nel migliorarlo.

In una patch per una modifica funzionale o correzione di bug, non è utile avere altre modifiche (ridenominazione, refactoring, qualunque cosa), raggruppate nella stessa patch. Dovrebbe apportare la modifica che corregge il bug o aggiunge la funzionalità, nient'altro.

Dove sono indicati la ridenominazione, il refactoring e altre modifiche , fatele in una patch separata, prima o dopo.

• Questo è piuttosto brutto, ma immagino sia coerente con tutti gli altri nostri codici cattivi. Ripuliamolo più tardi (in una patch, idealmente, senza modifiche funzionali).

  Aiuta anche se ti unisci al refactoring e permetti loro di rivedere il tuo codice. Ti dà la possibilità di dire perché pensi che qualcosa sia buono, piuttosto che cattivo, e anche di mostrare un esempio di come prendere bene le critiche costruttive.

Se è necessario aggiungere test unitari a una nuova funzionalità, va bene la patch principale. Ma se stai risolvendo un bug, i test dovrebbero andare in una patch precedente e non passare in modo da poter dimostrare che la correzione ha effettivamente risolto il bug.

Idealmente il piano (per come testare una correzione, o cosa refacturing e quando) dovrebbe essere discusso prima che il lavoro sia fatto, quindi non hanno sprecato un sacco di sforzo in qualcosa prima di scoprire che hai un problema.

Se scopri che il codice non gestisce gli input che ritieni debbano essere, potrebbe anche non corrispondere a ciò che lo sviluppatore considera un input ragionevole. D'accordo anche in anticipo, se possibile. Almeno avere qualche discussione su cosa dovrebbe essere in grado di far fronte e con quanta facilità si può permettere che fallisca.

Penso che sia un errore presumere che esista una soluzione tecnica o semplice a: "i miei colleghi sono sconvolti quando giudico il loro lavoro secondo i miei standard e hanno un certo potere per imporlo".

Ricorda che le recensioni dei codici non sono solo una discussione di ciò che è buono o cattivo. Sono implicitamente un "chi è il bastone da giardino che stiamo usando", un "chi prende la decisione" e quindi - insidiosamente - un rango.

Se non affronti questi punti, fare delle revisioni del codice in un modo che non abbia i problemi che incontrerai sarà difficile. Ci sono alcuni buoni consigli qui su come farlo, ma ti sei posto un compito difficile.

Se hai ragione, senza spazio di manovra, segnalarlo è un attacco: qualcuno ha fatto un casino. In caso contrario: il tuo altro MBA che non lo capisce. Ad ogni modo, sarai il cattivo.

Tuttavia, se ciò che la recensione sta cercando e perché , è chiaro e concordato, hai buone possibilità di non essere il cattivo. Non sei il guardiano, solo un correttore di bozze. Ottenere questo accordo è un problema difficile da risolvere [1]. Vorrei darti un consiglio, ma non ho ancora capito da solo ...

[1] Non è risolto solo perché la gente ha detto "ok" o ha smesso di litigare. Nessuno vuole essere il ragazzo a dire che X non è pratico per la nostra {intelligenza, esperienza, potere umano, scadenze, ecc.} Ma ciò non significa quando si tratta effettivamente di un caso specifico di fare X ...

Le revisioni del codice dovrebbero essere reciproche. Tutti hanno criticato tutti. Lascia che il motto sia "Non arrabbiarti, diventa pari". Tutti commettono errori e una volta che le persone hanno detto a un colpo caldo come correggere il loro codice, capiranno che questa è solo la normale procedura e non un attacco a loro.

Vedere il codice di altre persone è educativo. Comprendere il codice al punto in cui è possibile evidenziarne il punto debole e dover spiegare che la debolezza può insegnarti molto!

C'è poco spazio per gli elogi in una revisione del codice, dal momento che il punto è trovare difetti. Tuttavia, puoi elogiare le correzioni . Sia la tempestività che la pulizia possono essere elogiate.