L'arte di recensire

Non esagero se dico che passiamo almeno un'ora al giorno a rivedere il lavoro degli altri. Perché così tanto? La risposta è chiara. Grazie alla revisione tra pari, manteniamo la qualità dei nostri prodotti. Inoltre, impariamo molto da questa attività come destinatari e recensori di feedback. Ma completare una revisione non è un'impresa da poco. Dovete criticare in modo costruttivo il lavoro dei vostri colleghi, che in parte ha richiesto sangue, sudore e lacrime. Come si fa a rendere il feedback costruttivo e chiaro? Discutiamo tre metodi di peer review, tra cui il nostro preferito.

Soluzioni, soluzioni, soluzioni 

Per ottimizzare la qualità del vostro lavoro, è necessario un feedback profondo. Un modo di fare peer review è quello che io chiamo il metodo del sapere tutto. Fate vostro il codice o il testo. Avete visto ogni parola, ogni frase, ogni interpunzione o ogni stringa più volte e suggerite alternative per le parti che non soddisfano gli standard di qualità. A volte questo è accompagnato da una spiegazione del motivo per cui lo avete cambiato;

In passato ho utilizzato questo metodo. Guardate come ho modificato l'introduzione che il mio collega Jeroen ha scritto per il suo articolo "Perché non facciamo gli straordinari";

Lo riconoscete: siete impegnati in un progetto con una scadenza ravvicinata. Fate ore extra per arrivare alla scadenza. Dopo alcuni giorni di straordinari, tornate a casa tardi e stanchi, mangiate in modo poco salutare e andate subito a letto. Il mattino dopo ci si alza presto, non ancora riposati dalla breve notte. Siate forti ed eroici e portate a termine la scadenza. Promettete a voi stessi che la prossima volta sarà diverso. Che pianificherete meglio, che farete quei miglioramenti che avete saltato questa volta. Uscirete dall'ufficio in orario e mangerete con la famiglia o berrete un drink con gli amici. Solo che la volta successiva c'è un altro progetto importante con una scadenza. E la cosa si ripete.

_{Breve introduzione dell'articolo "Perché non facciamo gli straordinari", scritto da Jeroen.}

Ho suggerito di cambiarlo in questo modo per renderlo più attraente come introduzione:

Nella maggior parte dei lavori, spesso gli straordinari sono previsti. Non crediamo che gli straordinari siano la soluzione per portare a termine il lavoro e rispettare le scadenze. Sempre e comunque. Anzi, pensiamo che sia controproducente. Ecco perché concludiamo il lavoro dopo una giornata di otto ore, una normale giornata lavorativa nei Paesi Bassi.

_{Introduzione finale dell'articolo "Perché non facciamo gli straordinari", scritto da Jeroen.} 

A mio parere, l'introduzione di Jeroen era troppo lunga e consisteva in informazioni che si ripetevano nel corpo del testo. Ho impiegato un po' di tempo per proporre una nuova introduzione, che Jeroen ha accettato. 

Sostituire il proprio lavoro con quello di altri riduce il senso di completa appartenenza.

Cosa è andato storto? Ho dato subito la soluzione. Questo metodo di revisione non è migliore della semplice richiesta di approvazione. Naturalmente, chi riceve il feedback può intravedere il motivo del cambiamento. Ma non riscrivendo da soli, si perde l'opportunità di migliorare le proprie capacità di scrittura. Inoltre, sostituire il proprio lavoro con quello di altri riduce la sensazione di completa proprietà. Non sembra più il vostro lavoro. Inoltre, i livelli di insicurezza possono aumentare, con conseguente peggioramento della qualità del lavoro futuro. Il metodo del sapere tutto può anche facilitare qualcosa di completamente diverso: si dà per scontato il feedback e non lo si critica più. Questo è un aspetto che non vogliamo nemmeno noi, perché ogni feedback dovrebbe essere anche un'opportunità di apprendimento. A nostro avviso, rivedere il feedback ricevuto è fondamentale per il proprio sviluppo come sviluppatore o scrittore (front-end o back-end);

Veloce e sporco 

All'altra estremità dello spettro, c'è il metodo rapido e sporco. Questo consiste nel chiedere ai vostri colleghi di approvare il lavoro che avete fatto per passare alla fase successiva del processo. In realtà, non volete un feedback. Volete solo qualcosa online perché: 

1. Avete sviluppato il pezzo di codice insieme (pair programming).

2. Si tratta di una modifica talmente piccola che nulla può andare storto.

3. Si sente la pressione del tempo e i commenti causano un ritardo.

4. Si è discussa la soluzione con un collega e la si è implementata in seguito.

Nel caso delle ragioni A e B, il metodo rapido e sporco è consentito. Nel nostro lavoro quotidiano, lo facciamo spesso. Fa parte del nostro processo. Ma questo non vale per i motivi C, D e altri compiti complessi. In effetti, è necessario un paio di occhi in più, perché il diavolo si nasconde nei dettagli;

Incontrarsi nel mezzo 

I due metodi di peer review citati non sono ideali in termini di apprendimento. Ecco perché il nostro metodo preferito si colloca a metà strada. Secondo noi, un feedback tra pari di valore:  

• È costruttivo. Trattiamo i colleghi e il loro lavoro con rispetto. 

• Fa pensare. Vi aiuta a riflettere sul vostro lavoro e vi incoraggia a pensare ad altre soluzioni. 

• Consiste in domande. Perché l'avete fatto in questo modo? Qual è il motivo di questa impostazione? Avete pensato alle opzioni X e Y invece che alla sola Z?

• Rende possibile alle persone di elaborare da sole. Indica loro la giusta direzione, senza fornire l'intera soluzione. Tuttavia, a volte è molto difficile trattenersi, soprattutto quando si tratta di errori minori. Ad esempio: funzioni e variabili con nomi inappropriati (codice) o errori grammaticali (contenuto).

Consideriamo il feedback dei colleghi come un elemento di conversazione. Joan, sviluppatore back-end presso Easy LMS, spiega:  "Non rivelo l'intera soluzione, a volte solo una parte, ma discuto soprattutto di come sia possibile ottenere un'alternativa attraverso il refactoring. E questo a volte significa sedersi letteralmente accanto a qualcuno per guidarlo, invece di giocare a ping pong tramite GitHub o BitBucket, gli strumenti che utilizziamo per la revisione del codice".

"Quello che faccio anch'io a volte: Offro diverse alternative e lascio che sia il destinatario del feedback a decidere quale sia l'alternativa più adatta a lui. È un rompicapo perché bisogna considerare attentamente diverse opzioni".

_{Esempi di una conversazione di revisione del codice in GitHub.}

Secondo Joan, il feedback conversazionale non è sempre necessario. Dipende dal tipo di codice. "Supponiamo che qualcuno abbia accidentalmente inserito una vulnerabilità (di sicurezza) nel codice, allora è chiaro che deve essere rimossa. Naturalmente vi spiegherò perché va rimossa e come potete evitarla d'ora in poi, ma non è il momento ideale per una grande conversazione. In questo caso il metodo sapere tutto è più adatto".

Anna, la nostra consulente per l'implementazione e madrelingua inglese, controlla tutti i testi in inglese prima che vengano messi online e applica anche il metodo della conversazione . Solo poche settimane fa, correggeva lei stessa gli errori grammaticali. Ora fa riferimento più spesso alla nostra Guida di stile, in modo che le persone possano correggerli da sole".

Richiede più tempo, ma alla fine ripaga .

Più si elabora il feedback da soli, più si migliora e meno tempo ci vuole per fornire la qualità giusta la prossima volta.

Quest'ultimo metodo di revisione tra pari richiede molto tempo, soprattutto all'inizio. Questo è probabilmente uno dei motivi per cui a volte ricadiamo nelle nostre vecchie e comode abitudini. Ma ci ripetiamo sempre: più il feedback vi fa riflettere e più lo elaborate da soli, più migliorate il vostro lavoro. La prossima volta ci vorrà meno tempo per fornire la qualità giusta. I vantaggi sono duplici. In ultima analisi, anche il revisore impiegherà meno tempo per la revisione. Anche in questo caso è importante continuare a essere critici e a fornire un feedback prezioso, perché aiuta:

• Coinvolgere i colleghi nel lavoro quotidiano. Non ci sono isole di lavoro isolate. 

• Aumentare la fiducia nel lavoro che si crea perché qualcun altro pensa che valga la pena guardarlo.

• Migliorare la qualità del lavoro. È un investimento a lungo termine che previene (costosi) errori. 

Questo articolo è stato recensito in modo colloquiale?