L'altro giorno ho intervistato uno sviluppatore JavaScript che stava facendo domanda per una posizione senior. Un collega, presente anche lui al colloquio, ha chiesto al candidato di scrivere una funzione che facesse una richiesta HTTP e, in caso di insuccesso, riprovare più volte.
Ha scritto il codice direttamente sulla lavagna, quindi basterebbe disegnare qualcosa di approssimativo. Se avesse semplicemente dimostrato di capire bene qual era il problema, saremmo stati abbastanza soddisfatti. Ma sfortunatamente non è riuscito a trovare una soluzione efficace. Poi noi, considerandolo entusiasmante, abbiamo deciso di rendere il compito un po' più semplice e gli abbiamo chiesto di trasformare una funzione con callback in una funzione basata su promesse.
Ma ahimè. Sì, era ovvio che avesse già incontrato un codice del genere. Sapeva in termini generali come funzionava tutto lì. Tutto ciò di cui abbiamo bisogno è uno schizzo di una soluzione che dimostri la comprensione del concetto. Tuttavia, il codice che il candidato ha scritto sulla lavagna era completamente privo di senso. Aveva un’idea molto vaga di quali promesse ci fossero in JavaScript e non riusciva davvero a spiegare perché fossero necessarie. Per un junior questo sarebbe stato perdonabile, ma non era più adatto alla posizione di senior. Come potrebbe questo sviluppatore risolvere i bug in una complessa catena di promesse e spiegare agli altri cosa ha fatto esattamente?
Gli sviluppatori considerano ovvio il codice già pronto
Durante il processo di sviluppo, incontriamo costantemente materiali riproducibili. Trasferiamo frammenti di codice in modo da non doverli riscrivere ogni volta. Di conseguenza, concentrando tutta la nostra attenzione sulle parti chiave, consideriamo il codice finito con cui lavoriamo come qualcosa di ovvio: diamo semplicemente per scontato che tutto funzionerà come dovrebbe.
E di solito funziona, ma quando le cose si fanno complicate, comprendere i meccanismi è più che utile.
Pertanto, il nostro candidato per la posizione di sviluppatore senior considerava evidenti gli oggetti promessi. Probabilmente aveva un'idea di come gestirli quando si verificano da qualche parte nel codice di qualcun altro, ma non ha capito il principio generale e non è riuscito a ripeterlo lui stesso durante l'intervista. Forse ricordava il frammento a memoria - non è così difficile:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});L'ho fatto anch'io e probabilmente lo abbiamo fatto tutti prima o poi. Hanno semplicemente memorizzato un pezzo di codice in modo da poterlo utilizzare in seguito nel loro lavoro, avendo solo un'idea generale di come funzionava tutto lì. Ma se lo sviluppatore comprendesse veramente il concetto, non avrebbe bisogno di ricordare nulla: saprebbe semplicemente come farlo e riprodurrebbe facilmente tutto ciò di cui ha bisogno nel codice.
Torna alle radici
Nel 2012, quando il dominio dei framework front-end non era ancora stato stabilito, jQuery dominava il mondo, e lessi il libro , scritto da John Resig, creatore di jQuery.
Il libro insegna al lettore come creare il proprio jQuery da zero e fornisce una visione unica del processo di pensiero che ha portato alla creazione della libreria. Negli ultimi anni, jQuery ha perso la sua precedente popolarità, ma consiglio vivamente il libro. Ciò che più mi colpì di lei fu la persistente sensazione che avrei potuto pensare a tutto questo da sola. I passaggi descritti dall'autore sembravano così logici, così chiari che ho iniziato seriamente a pensare che avrei potuto facilmente creare jQuery se solo ci fossi riuscito.
Naturalmente, in realtà non avrei potuto fare nulla del genere: avrei deciso che era insopportabilmente difficile. Le mie soluzioni sembrerebbero troppo semplici e ingenue per funzionare e mi arrenderei. Classificherei jQuery come cose evidenti, nel corretto funzionamento delle quali devi solo credere ciecamente. Successivamente, difficilmente perderei tempo ad approfondire i meccanismi di questa libreria, ma la utilizzerei semplicemente come una sorta di scatola nera.
Ma leggere questo libro mi ha reso una persona diversa. Ho iniziato a leggere il codice sorgente e ho scoperto che l'implementazione di molte soluzioni era in realtà molto trasparente, addirittura ovvia. No, certo, pensare a una cosa del genere da soli è una storia diversa. Ma è studiare il codice di altre persone e riprodurre le soluzioni esistenti che ci aiuta a trovare qualcosa di nostro.
L'ispirazione che ottieni e gli schemi che inizi a notare ti cambieranno come sviluppatore. Scoprirai che quella meravigliosa libreria che usi costantemente e che sei abituato a considerare come un artefatto magico non funziona affatto con la magia, ma risolve semplicemente il problema in modo laconico e pieno di risorse.
A volte dovrai studiare attentamente il codice, analizzandolo passo dopo passo, ma è così che, muovendoti per piccoli passi coerenti, puoi ripetere il percorso dell'autore verso la soluzione. Ciò ti consentirà di approfondire il processo di codifica e ti darà più sicurezza nel trovare le tue soluzioni.
Quando ho iniziato a lavorare con le promesse, mi è sembrata pura magia. Poi ho scoperto che erano basati sugli stessi callback e il mio mondo di programmazione si è capovolto. Quindi il pattern, il cui scopo è salvarci dai callback, è esso stesso implementato utilizzando i callback?!
Questo mi ha aiutato a guardare la questione con occhi diversi e a rendermi conto che questo non è un astruso pezzo di codice davanti a me, la cui complessità proibitiva non capirò mai in vita mia. Questi sono solo schemi che possono essere compresi senza problemi con la dovuta curiosità e profonda immersione. È così che le persone imparano a programmare e crescono come sviluppatori.
Reinventare questa ruota
Quindi vai avanti e reinventa le ruote: scrivi il tuo codice di associazione dati, crea una promessa fatta in casa o addirittura crea la tua soluzione di gestione dello stato.
Non importa che nessuno utilizzerà mai tutto questo, ma ora sai come farlo. E se hai l’opportunità di utilizzare successivamente tali sviluppi nei tuoi progetti, in genere è fantastico. Sarai in grado di svilupparli e imparare qualcos'altro.
Il punto qui non è inviare il codice in produzione, ma imparare qualcosa di nuovo. Scrivere la propria implementazione di una soluzione esistente è un ottimo modo per imparare dai migliori programmatori e quindi affinare le proprie capacità.
Fonte: habr.com