Recentemente ho condotto un colloquio con un sviluppatore JavaScript che si candidava per la posizione di senior. Un collega, anch'esso presente al colloquio, ha chiesto al candidato di scrivere una funzione che eseguisse una richiesta HTTP e, in caso di fallimento, riprovasse più volte.
Scriveva il codice direttamente sulla lavagna, quindi sarebbe bastato rappresentare qualcosa di approssimativo. Se avesse semplicemente mostrato di comprendere bene di cosa si trattava, saremmo stati abbastanza soddisfatti. Tuttavia, sfortunatamente, non riusciva a trovare una soluzione valida. Allora, attribuendo ciò all'emozione, abbiamo deciso di semplificare un po' il compito e gli abbiamo chiesto di trasformare la funzione con callback in una funzione basata sulle promise.
Ma purtroppo. Sì, era evidente che un tale codice gli era già capitato di incontrarlo. Aveva una conoscenza generale di come funziona. Ci sarebbe bastato un abbozzo di soluzione che dimostrasse comprensione del concetto. Tuttavia, il codice che il candidato scriveva sulla lavagna era un'assoluta insensatezza. Aveva una concezione estremamente confusa di cosa siano le promise in JavaScript e non riusciva a spiegare bene perché fossero necessarie. Per un junior sarebbe stato ancora scusabile, ma per un senior non era all'altezza. Come avrebbe potuto questo sviluppatore risolvere bug in una complessa catena di promise e spiegare agli altri cosa avesse fatto?
Gli sviluppatori considerano il codice pronto come una cosa ovvia
Durante lo sviluppo ci imbattiamo costantemente in materiali riproducibili. Copiamo frammenti di codice, in modo da non doverli scrivere tutto da capo ogni volta. Pertanto, concentrando tutta l'attenzione sulle parti chiave, guardiamo al codice pronto con cui lavoriamo come a qualcosa di ovvio: presumiamo semplicemente che funzionerà come previsto.
E di solito funziona davvero, ma quando sorgono difficoltà, comprendere la sua meccanica vale più che mai.
Così, il nostro candidato per la posizione di sviluppatore senior considerava ovvie le promise. Probabilmente sapeva come gestirle quando si presentavano in codice di altri, ma non capiva il principio generale e non riusciva a ripeterlo durante il colloquio. Forse aveva memorizzato un frammento a memoria – non è così difficile:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});L'ho fatto anche io, e probabilmente lo ha fatto anche ognuno di noi almeno una volta. Facevamo nostro un pezzo di codice per poi utilizzarlo nel lavoro, senza capire realmente come fosse strutturato. Ma se un sviluppatore avesse davvero compreso il concetto, non avrebbe dovuto imparare nulla a memoria: semplicemente saprebbe come fare e potrebbe riprodurre facilmente tutto ciò che serve nel codice.
Rivolgiti alle origini
Nel 2012, quando non c'era ancora il predominio dei framework front-end, il mondo era governato da jQuery, e leggevo il libro , scritto da John Resig, il creatore di jQuery.
Il libro insegna al lettore come costruire una propria jQuery da zero e offre un'opportunità unica di connettersi al modo di pensare che ha portato alla creazione della libreria. Negli ultimi anni, jQuery ha perso parte della sua popolarità, ma consiglio comunque vivamente il libro. Ciò che mi ha colpito di più è stato il persistente sentimento che avrei potuto arrivarci da solo. I passi descritti dall'autore sembravano così logici, così ovvi, che mi è davvero sembrato che anche io avrei potuto facilmente creare jQuery, se solo avessi iniziato.
Naturalmente, nella realtà non sarei riuscito a farlo: avrei concluso che fosse troppo complicato. Le mie soluzioni avrebbero sembrate troppo semplici e naive per funzionare, e avrei gettato la spugna. Avrei considerato jQuery una di quelle cose ovvie, in cui si deve semplicemente credere ciecamente nel loro corretto funzionamento. In seguito, non avrei dedicato tempo a comprendere la meccanica di questa libreria, e avrei semplicemente continuato a utilizzarla come se fosse una scatola nera.
Ma l'incontro con questo libro mi ha cambiato. Ho iniziato a studiare il codice sorgente e ho scoperto che l'implementazione di molte soluzioni è in realtà molto chiara, persino ovvia. Certo, arrivare a simili conclusioni da solo è tutta un'altra storia. Ma è proprio lo studio del codice altrui e la riproduzione di soluzioni esistenti che ci aiuta a inventare qualcosa di nostro.
L'ispirazione che raccoglierai e i modelli che inizierai a notare ti trasformeranno come sviluppatore. Scoprirai che quella meravigliosa libreria che usi costantemente e alla quale sei abituato a pensare come a un artefatto magico, non funziona per magia, ma semplicemente risolve il problema in modo conciso e ingegnoso.
A volte dovrai lavorare duramente sul codice, esaminandolo passo dopo passo, ma è proprio così, procedendo a piccoli passi sequenziali, che potrai ripetere il percorso dell'autore verso la soluzione. Questo ti permetterà di immergerti più a fondo nel processo di scrittura del codice e ti darà maggiore fiducia nella ricerca delle tue soluzioni.
Quando ho iniziato a lavorare con le promise, sembrava pura magia. Poi ho scoperto che alla base ci sono gli stessi callback, e il mio mondo da programmatore si è rovesciato. Quindi, il pattern che ha l'obiettivo di liberarci dai callback viene realizzato tramite callback?!
Questo mi ha aiutato a guardare le cose da una nuova prospettiva e a rendermi conto che di fronte non ho pezzi di codice incomprensibili, di una complessità che non comprenderò mai nella vita. Sono semplicemente modelli, che possono essere facilmente compresi con la dovuta curiosità e un profondo coinvolgimento. È così che le persone imparano a programmare e crescono come sviluppatori.
Reinventa quest'ruota.
Quindi, non esitare a reinventare le ruote: scrivi tu stesso il codice per l'associazione dei dati, crea una promise homemade o addirittura realizza una soluzione per la gestione degli stati con le tue mani.
Non importa se tutto ciò non sarà mai utilizzato da nessuno: ora tu sai farlo. E se in futuro avrai la possibilità di utilizzare tali sviluppi nei tuoi progetti, sarà fantastico. Potrai farli evolvere e imparare qualcosa di nuovo.
Il senso qui non è spedire il proprio codice in produzione, ma apprendere qualcosa di nuovo. Scrivere autonomamente l'implementazione di una soluzione già esistente è un ottimo modo per imparare dai migliori programmatori e affinare la propria maestria.
Fonte: habr.com
