Nei due precedenti episodi della nostra serie abbiamo parlato dei primi passi nella professione di sviluppatore e di cosa valga davvero la pena imparare all'inizio della carriera.
Ora arriviamo al momento che spaventa quasi ogni Junior.
Primo Code Review. Prime annotazioni sul codice. Prime correzioni.
E il primo pensiero: "Ho davvero scritto il codice così male?"
Tranquillo.
Tutti noi ci siamo passati.
Il Code Review non è un esame
Probabilmente è il malinteso più grande tra gli sviluppatori alle prime armi.
Molti Junior percepiscono i commenti sul loro codice in modo molto personale. Nasce stress. Insicurezza. A volte persino frustrazione.
Eppure l'obiettivo del Code Review non è dimostrare a qualcuno che ha fatto un errore. Anzi. È uno degli elementi più importanti del processo di creazione di buon software.
Grazie al Code Review:
- riduciamo il rischio di errori,
- miglioriamo la leggibilità del codice,
- impariamo gli uni dagli altri,
- ci prendiamo cura della coerenza dell'intero progetto,
- trasmettiamo conoscenza tra i membri del team.
I team migliori non considerano il Code Review come un controllo. Lo considerano uno scambio quotidiano di esperienze.
"Hai 37 commenti"
Suona minaccioso? All'inizio sì.
Il primo Pull Request spesso assomiglia esattamente a questo:
- Commento.
- Correzione.
- Un altro commento.
- Un'altra correzione.
Dopo un'ora hai l'impressione che tutto il codice sia da buttare. È normale.
Ricordati solo una cosa. Il senior non cambia il codice per mostrare la sua superiorità. Lo fa perché fra qualche mese scriverai codice molto migliore.
Ed è proprio questo il punto.
Un buon Senior non dice solo "sbagliato"
I migliori sviluppatori con cui abbiamo lavorato spiegavano sempre:
- perché conviene fare una cosa in modo diverso,
- quali saranno le conseguenze della soluzione attuale,
- quali alternative esistono,
- quale soluzione sarà più facile da mantenere tra uno o due anni.
C'è una grande differenza.
Si può dire: "Questo è sbagliato."
Oppure si può dire: "Funziona, ma se tra sei mesi dovessimo evolvere questo modulo, sarebbe molto più semplice mantenerlo con questa struttura."
Nel secondo caso impari qualcosa di molto più prezioso della singola correzione. Impari un modo di pensare.
Clean Code non significa codice bello
È un altro concetto spesso frainteso.
Clean Code non significa codice esteticamente impressionante. Non si tratta del numero di righe vuote. Non si tratta della lunghezza delle funzioni. Non si tratta neppure di pattern specifici.
Si tratta di qualcosa di più semplice: il codice dovrebbe essere leggibile.
Se tra sei mesi aprirai il tuo progetto e non ricorderai cosa intendevi...
...probabilmente il codice non era sufficientemente leggibile.
C'è un detto: Scriviamo codice per le persone. Il compilatore controlla solo la sintassi.
E c'è molta verità in questo.
Non innamorarti del tuo codice
Questa è una delle lezioni più importanti.
Il codice non è un'opera d'arte. Non è un quadro. Non è una scultura.
È uno strumento per risolvere un problema concreto.
Se qualcuno propone una soluzione migliore...
...vale la pena valutarla.
Non perché quella persona abbia più autorità. Perché forse è davvero migliore.
Imparano di più gli sviluppatori che riescono a dire: "Hai ragione. Facciamolo diversamente."
"Da me funziona"
Bene. Siamo finalmente arrivati a quella famosa frase. Ogni software house ha la sua versione di questa battuta...
Immagina la situazione.
Il tester segnala un bug.
Lo sviluppatore risponde: "Da me funziona."
Il tester ricontrolla. - Non funziona.
Il Project Manager guarda. - Non funziona.
Anche il cliente prova. - Non funziona.
Ma... per l'autore del codice continua a funzionare.
Ti suona familiare?
Quasi sempre il problema non è nel codice in sé.
Le cause possono essere molte:
- versione diversa dei dati,
- ambiente diverso,
- cache,
- configurazione,
- permessi,
- browser,
- sistema operativo,
- un caso che nessuno aveva previsto prima.
Perciò il programmatore professionista non si limita alla frase: "Da me funziona."
Pone una domanda successiva.
Perché da me funziona e altrove no?
Ed è proprio allora che inizia il vero debug.
"È solo una piccola modifica"
Un'altra frase che fa sorridere la maggior parte delle software house.
Il cliente dice: "È solo una piccola correzione."
Lo sviluppatore sa già che tra poco aprirà un file che nessuno ha toccato da sei anni.
E quella "piccola correzione" si rivelerà una modifica in cinque moduli, tre integrazioni e due database.
Per questo gli sviluppatori esperti prendono molto cautamente la parola "solo".
Le frasi più famose del settore
Ogni professione ha i suoi detti. Anche i programmatori.
Alcuni di essi li conoscono forse tutti:
- "Da me funziona."
- "Sono solo cinque minuti."
- "Non è un bug. È una feature."
- "Ma non ho cambiato nulla."
- "In produzione è esploso."
- "Ancora un deploy e poi è a posto."
- "Sicuramente è la cache."
- "Una correzione rapida prima del weekend."
- "Dovrebbe funzionare."
E probabilmente la più pericolosa: "Lo mettiamo in produzione venerdì dopo le 16:00."
Se lavori in IT...
...probabilmente ti sei appena sorriso.
Lo sviluppatore non lavora da solo
È un tema spesso trascurato. In realtà la maggior parte dei progetti è lavoro di squadra.
Lo sviluppatore collabora con:
- UX Designer,
- UI Designer,
- Project Manager,
- Tester,
- DevOps,
- Amministratori,
- Analisti,
- Clienti.
Perciò tanto quanto la conoscenza tecnologica sono importanti:
- comunicazione,
- capacità di ascolto,
- trasmissione della conoscenza,
- responsabilità,
- rispetto reciproco.
Il codice migliore non salverà un progetto se il team non sa collaborare.
Glossario
Code Review
Processo di revisione del codice da parte di altri sviluppatori prima del suo rilascio. Ha lo scopo di migliorare la qualità del codice, rilevare errori e condividere conoscenza.
Pull Request (PR)
Proposta di introdurre modifiche nel progetto. È proprio in questa fase che avviene spesso il Code Review.
Clean Code
Approccio alla scrittura del codice il cui obiettivo principale è la leggibilità, la semplicità e la facilità di manutenzione, non il numero di pattern applicati.
Debugging (Debuggare)
Processo di individuazione e rimozione delle cause dei bug in un'applicazione.
Cache
Meccanismo che conserva temporaneamente i dati per velocizzare l'applicazione. Spesso è anche fonte di molti problemi misteriosi durante il testing.
Riepilogo
Più a lungo lavoriamo come sviluppatori, più arriviamo a una conclusione: i migliori developer non sono quelli che commettono meno errori.
I migliori developer sanno:
- trovare più velocemente la causa di un problema,
- trarre conclusioni,
- imparare dagli altri,
- accettare critiche costruttive,
- sviluppare continuamente il proprio mestiere.
Il Code Review non è quindi un ostacolo. È una delle lezioni più preziose che si possano ricevere all'inizio della propria carriera.
Nell'ultimo episodio della nostra serie parleremo del percorso da Junior a Senior. Spiegheremo perché un Senior Developer non è semplicemente chi ha dieci anni di esperienza, ma chi sa prendersi responsabilità sul progetto, pensare in ottica di business e aiutare gli altri membri del team a crescere.
