Nel web development, come del resto in ogni attività umana, evitare del tutto gli errori è pressoché impossibile. Il codice di siti web e applicazioni, quindi, contiene spesso bug che possono causare problemi agli utenti. Strumenti per il testing e il debugging possono essere d’aiuto, ma non bisogna sottovalutare i benefici della code review effettuata da un altro web developer. In questo articolo vedremo vantaggi e potenziali svantaggi, illustreremo gli approcci più diffusi alla code review e forniremo alcuni consigli su come realizzarla al meglio.
Che cos’è la code review
In breve, la code review è il processo di controllo della qualità del codice sorgente scritto da uno sviluppatore web da parte di un altro developer. Grazie a questo passaggio ci si assicura che non siano presenti problemi rilevanti prima di aggiungere il codice alla codebase. A seconda del tipo di progetto e delle risorse a disposizione può trattarsi di un controllo informale con alcuni suggerimenti per migliorare, oppure di un processo strutturato e documentato con cura in base a standard di qualità predefiniti.
Nonostante richieda del lavoro aggiuntivo, non va vista come una perdita di tempo: con un approccio efficace e l’ausilio dei tool giusti può essere inserita con successo anche in un flusso di lavoro Agile.
Hai bisogno di informazioni? 🙋🏻♂️
Parliamone! Scrivici su Whatsapp e risponderemo a tutte le tue domande per capire quale dei nostri corsi è il più adatto alle tue esigenze.
Vantaggi e svantaggi della code review
Un ovvio vantaggio della code review è un miglioramento della qualità del codice, e di conseguenza del prodotto finale. Il controllo da parte di un altro programmatore informatico permette, infatti, di identificare bug, potenziali rischi per la sicurezza o problemi di performance. Al tempo stesso, i suggerimenti di un collega aiutano a rendere il codice più leggibile e a facilitarne in futuro la revisione e il mantenimento. Inoltre, attraverso la code review si promuove la collaborazione positiva tra diversi web developers, rafforzando il team e offrendo preziose opportunità di apprendimento e di condivisione delle proprie conoscenze.
Per quanto riguarda gli svantaggi, il più evidente è la necessità di investire tempo e risorse aggiuntive, rallentando così il progetto in corso. Pur con le migliori intenzioni, poi, è difficile evitare del tutto il rischio di fraintendimenti o di effetti negativi sull’umore e sulla fiducia nelle proprie capacità del developer che riceve correzioni e feedback. Infine, preferenze personali e approcci alla risoluzione dei problemi possono essere differenti per ogni programmatore, con potenziali contrasti di opinioni durante la code review.
Diversi approcci alla code review
Vediamo adesso alcuni approcci comuni per effettuare la code review. Uno di questi è l’invio del codice attraverso un thread di e-mail a diversi colleghi, che risponderanno con i loro suggerimenti appena possibile. Seppur flessibile e relativamente semplice, questo approccio risulta spesso in una casella e-mail intasata da risposte a volte in contrasto tra loro.
Un’alternativa che funziona bene per progetti complessi è il pair programming, durante cui due developer lavorano insieme allo stesso codice, effettuando correzioni e dando suggerimenti in tempo reale. Pur con molti benefici, questa opzione impegna però due programmatori per una sola attività, con un calo della produttività del team.
L’approccio “over-the-shoulder” è uno dei più diretti, rapidi e intuitivi. In questo caso, lo sviluppatore mostra il codice a un collega, spiegando le ragioni per cui lo ha scritto proprio in questo modo. Un possibile svantaggio, qui, è l’assenza di documentazione adeguata.
Infine, la code review attraverso tool appositi è l’approccio forse più efficace. Permette di effettuare il controllo in modo asincrono, di fornire commenti e suggerire soluzioni, e di ricevere notifiche al completamento del processo.
Consigli per una buona code review
Per realizzare la code review al meglio è necessario, prima di tutto, creare una lista di elementi da controllare, così da non dimenticare aspetti importanti. Tra questi citiamo rischi per la sicurezza, leggibilità, struttura e riusabilità del codice.
È bene, inoltre, seguire alcuni criteri per evitare stanchezza eccessiva e perdita di concentrazione. Controllare circa 200 righe di codice per volta, limitando il tempo per la code review a circa un’ora per sessione, aiuta a mantenere l’attenzione e a identificare efficacemente tutti i problemi. Lo sviluppatore di siti web che ha scritto il codice, poi, dovrebbe preparare per tempo documentazione e appunti per facilitare il processo. Spesso capita che, così facendo, si trovino errori prima ancora di condividere il codice con chi effettuerà il controllo.
Le richieste di pull devono essere mantenute a un numero ragionevole, più vicino alle cento che alle mille righe di codice. Ciò dipende, naturalmente, dal numero di file e dalle dimensioni del progetto in questione. Quando possibile, è bene spezzare modifiche consistenti in parti più piccole per facilitare il processo.
Infine, imparare a fornire feedback in modo positivo è cruciale per una buona code review, ma anche per il lavoro di squadra più in generale. Insieme alle necessarie correzioni, è buona norma offrire feedback positivo sugli aspetti migliori del lavoro di chi ha scritto il codice. Le modifiche vanno limitate agli errori principali, senza correggere puntigliosamente ogni cosa. Per ogni correzione, bisogna impegnarsi a spiegare ragioni oggettive, evitando di basarsi solo sulle preferenze personali. Quando diverse soluzioni sono possibili è bene farlo presente, invece di imporre la propria opinione. Ciò che conta è mantenere le proprie osservazioni strettamente sul codice, senza mai dare un giudizio negativo sul programmatore che lo ha scritto.
Seguendo questi consigli si può fare della code review un momento di apprendimento, rafforzamento delle relazioni tra colleghi, oltre che di miglioramento della qualità di applicazioni e siti web realizzati.
