Recentemente ho condotto un colloquio con uno sviluppatore JavaScript che si candidava per una posizione da senior. Un collega, presente anch'esso all'intervista, ha chiesto al candidato di scrivere una funzione che effettuasse una richiesta HTTP e, in caso di errore, riprovasse alcune volte.
Scriveva il codice direttamente sulla lavagna, quindi sarebbe bastato rappresentare qualcosa di approssimativo. Se avesse semplicemente dimostrato di avere una buona comprensione del concetto, saremmo stati abbastanza soddisfatti. Purtroppo, però, non riusciva a trovare una soluzione adeguata. Allora, attribuendo questo al nervosismo, abbiamo deciso di semplificare un po' il compito e gli abbiamo chiesto di trasformare la funzione con callback in una funzione basata su promesse.
Peccato. Sì, era ovvio che un codice del genere gli fosse già capitato. Aveva una conoscenza generale di come funzionasse il tutto. Ci saremmo accontentati di una bozza di soluzione che dimostrasse una comprensione del concetto. Tuttavia, il codice che il candidato scriveva sulla lavagna era completamente insensato. Aveva un'idea estremamente confusa di cosa siano le promesse in JavaScript e non riusciva a spiegare perché siano necessarie. Per un junior sarebbe stato ancora scusabile, ma per una posizione da senior non era all'altezza. Come sarebbe riuscito questo sviluppatore a correggere i bug in una catena complessa di promesse e a spiegare agli altri cosa avesse fatto?
Gli sviluppatori considerano il codice finito ovvio
Durante lo sviluppo, ci troviamo costantemente di fronte a materiali ripetibili. Copiamo frammenti di codice per non doverli riscrivere ogni volta. Di conseguenza, concentrandoci sulle parti chiave, guardiamo al codice finito con cui lavoriamo come se fosse ovvio: presupponiamo semplicemente che funzioni come dovrebbe.
E di solito funziona davvero, ma quando sorgono difficoltà, la comprensione della sua meccanica ripaga ampiamente.
Così, il nostro candidato per la posizione di sviluppatore senior considerava gli oggetti promise come ovvi. Probabilmente immaginava come gestirli quando si trovavano nel codice di qualcun altro, ma non capiva il principio generale e non riusciva a riprodurlo da solo 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);
});
});Anch'io lo facevo – anzi, probabilmente tutti noi abbiamo fatto così a un certo punto. Semplicemente memorizzavamo un pezzo di codice da utilizzare poi nel lavoro, avendo solo una visione generale di come funzionasse. Ma se uno sviluppatore capisse davvero il concetto, non dovrebbe memorizzare nulla – saprebbe semplicemente come farlo e riprodurrebbe tutto ciò che serve nel codice con facilità.
Rivolgersi alle origini
Nel 2012, quando non regnavano ancora i framework frontend, il mondo era dominato da jQuery, e leggevo un libro , scritto da John Resig, creatore di jQuery.
Il libro insegna al lettore come creare il proprio jQuery da zero e offre un'opportunità unica di immergersi nel modo di pensare che ha portato alla creazione della libreria. Negli ultimi anni, jQuery ha perso la sua popolarità, ma consiglio comunque vivamente il libro. Ciò che mi ha colpito di più è stata la persistente sensazione che avrei potuto arrivare a queste conclusioni da solo. I passaggi descritti dall'autore erano così logici e comprensibili che mi è sembrato seriamente che anche io avrei potuto creare jQuery, se solo mi fossi messo d'impegno.
Naturalmente, nella realtà, nulla di tutto ciò sarebbe stato alla mia portata: avrei pensato che fosse incredibilmente difficile. Le mie soluzioni sarebbero sembrate troppo semplici e naive per funzionare, e avrei gettato la spugna. Avrei considerato jQuery come una cosa ovvia, in cui è necessario semplicemente credere ciecamente in un corretto funzionamento. Successivamente, probabilmente non avrei sprecato tempo a capire la meccanica di questa libreria, ma avrei semplicemente continuato a usarla come se fosse un oggetto misterioso.
Ma conoscere questo libro mi ha cambiato. Ho iniziato a esaminare il codice sorgente e ho scoperto che l'implementazione di molte soluzioni è in realtà molto chiara, persino ovvia. Certamente, arrivare a tali conclusioni da soli è un'altra storia. Ma è proprio tramite lo studio del codice di altri e la riproduzione di soluzioni già esistenti che ci aiutiamo a creare qualcosa di originale.
L'ispirazione che trarrete e i modelli che inizierete a notare vi trasformeranno come sviluppatori. Scoprirete che quella straordinaria libreria che utilizzate costantemente e che vi siete abituati a considerare come un artefatto magico, funziona non grazie alla magia, ma risolve semplicemente il problema in modo conciso e ingegnoso.
A volte, dovrete lavorare a lungo sul codice, analizzandolo passo dopo passo, ma è proprio così, avanzando a piccoli passi consecutivi, che potrete ripetere il percorso dell'autore verso la soluzione. Questo vi permetterà di immergervi più a fondo nel processo di scrittura del codice e vi darà maggiore fiducia nella ricerca di soluzioni proprie.
Quando ho iniziato a lavorare con le promesse, mi sembrava che fosse pura magia. Poi ho capito che alla base ci sono gli stessi callback, e il mio mondo da programmatore è cambiato. Quindi, il pattern che ha come obiettivo liberarci dai callback si realizza attraverso i callback?!
Questo mi ha aiutato a guardare la questione con occhi diversi e a rendermi conto che di fronte a me non ci sono solo pezzi di codice astrusi, la cui complessità non avrei mai potuto comprendere. Sono solo pattern che possono essere affrontati senza problemi con la giusta curiosità e un profondo impegno. È così che le persone imparano a programmare e crescono come sviluppatori.
Reinventate la ruota
Quindi non esitate a reinventare le ruote: scrivete il codice per il binding dei dati, create una promessa personalizzata o anche sviluppate una soluzione di gestione degli stati da soli.
Non importa che nessuno utilizzi mai tutto questo – ciò che conta è che ora ne hai la competenza. E se in seguito avrai l'opportunità di usare queste acquisizioni nei tuoi progetti, sarà fantastico. Potrai svilupparle ulteriormente e imparare ancora di più.
Il punto non è inviare il tuo codice in produzione, ma acquisire nuove conoscenze. Scrivere da solo l'implementazione di una soluzione già esistente è un ottimo modo per imparare dai migliori programmatori e affinare le proprie abilità.
Fonte: habr.com
