L'altre dia vaig entrevistar un desenvolupador de JavaScript que sol·licitava una posició sènior. Un company, que també va estar present a l'entrevista, va demanar al candidat que escrivís una funció que fes una sol·licitud HTTP i, si no té èxit, ho torni a intentar diverses vegades.
Va escriure el codi directament a la pissarra, així que n'hi hauria prou amb dibuixar alguna cosa aproximada. Si simplement hagués demostrat que entenia bé de què es tractava, hauríem estat bastant satisfets. Però, malauradament, no va poder trobar una solució satisfactòria. Llavors, vam decidir fer la tasca una mica més fàcil i li vam demanar que convertís una funció amb devolucions de trucada en una funció basada en promeses.
Però ai. Sí, era obvi que havia trobat aquest codi abans. Sabia en termes generals com funcionava tot allà. Tot el que necessitem és un esbós d'una solució que demostri la comprensió del concepte. No obstant això, el codi que el candidat va escriure a la pissarra era un disbarat total. Tenia una idea molt vaga de quines promeses eren a JavaScript i realment no podia explicar per què eren necessàries. Per a un júnior això hauria estat perdonable, però ja no s'adaptava a la posició de sènior. Com podria aquest desenvolupador solucionar errors en una complexa cadena de promeses i explicar als altres què va fer exactament?
Els desenvolupadors consideren que el codi ja fet és evident
Durant el procés de desenvolupament, ens trobem constantment amb materials reproduïbles. Transferim fragments de codi per no haver de tornar-los a escriure cada vegada. En conseqüència, centrant tota la nostra atenció en les parts clau, mirem el codi acabat amb el qual treballem com una cosa evident: simplement assumim que tot funcionarà com hauria de ser.
I normalment funciona, però quan les coses es tornen complicades, entendre la mecànica paga més que recompensa.
Així, el nostre candidat a la posició de desenvolupador sènior considerava que els objectes de promeses eren evidents. Probablement tenia una idea de com tractar-los quan es produeixen en algun lloc del codi d'una altra persona, però no entenia el principi general i no podia repetir-ho ell mateix durant l'entrevista. Potser va recordar el fragment de memòria, no és tan difícil:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Jo també ho vaig fer, i probablement tots ho hem fet en algun moment. Simplement van memoritzar un tros de codi per poder-lo utilitzar més tard en el seu treball, mentre només tenien una idea general de com funcionava tot allà. Però si el desenvolupador entengués realment el concepte, no hauria de recordar res, simplement sabria com fer-ho i reproduiria fàcilment tot el que necessitava en codi.
Torna a les arrels
El 2012, quan encara no s'havia establert el domini dels frameworks front-end, jQuery va governar el món i vaig llegir el llibre , escrit per John Resig, creador de jQuery.
El llibre ensenya al lector a crear el seu propi jQuery des de zero i ofereix una visió única del procés de pensament que va portar a la creació de la biblioteca. En els últims anys, jQuery ha perdut la seva antiga popularitat, però encara recomano molt el llibre. El que més em va impactar d'ella va ser la persistent sensació que jo mateix podria haver pensat en tot això. Els passos que va descriure l'autor em van semblar tan lògics, tan clars que vaig començar a pensar seriosament que podria crear jQuery fàcilment si m'hi anés.
Per descomptat, en realitat no hauria estat capaç de fer res com això: hauria decidit que era insuportablement difícil. Les meves pròpies solucions semblarien massa senzilles i ingènues per funcionar, i em rendiria. Jo classificaria jQuery com a coses evidents, en el correcte funcionament de les quals només cal creure cegament. Posteriorment, gairebé no perdria el temps aprofundint en la mecànica d'aquesta biblioteca, sinó que simplement l'utilitzaria com una mena de caixa negra.
Però llegir aquest llibre em va convertir en una persona diferent. Vaig començar a llegir el codi font i vaig descobrir que la implementació de moltes solucions era de fet molt transparent, fins i tot òbvia. No, per descomptat, pensar en una cosa com això pel teu compte és una història diferent. Però és estudiar el codi d'altres persones i reproduir solucions existents que ens ajuda a crear alguna cosa pròpia.
La inspiració que obtingueu i els patrons que comenceu a notar us canviaran com a desenvolupador. Trobareu que aquella meravellosa biblioteca que feu servir constantment i que esteu acostumats a pensar com un artefacte màgic no funciona en absolut amb la màgia, sinó que simplement resol un problema de manera lacònica i amb recursos.
De vegades hauràs d'analitzar el codi, analitzant-lo pas a pas, però és així com, avançant a passos petits i coherents, pots repetir el camí de l'autor cap a la solució. Això us permetrà aprofundir en el procés de codificació i us donarà més confiança per trobar les vostres pròpies solucions.
Quan vaig començar a treballar amb promeses, em va semblar pura màgia. Llavors vaig descobrir que es basaven en les mateixes trucades i el meu món de programació es va capgirar. Així doncs, el patró, el propòsit del qual és estalviar-nos de les devolució de trucades, s'implementa amb les devolució de trucades?!
Això em va ajudar a mirar l'assumpte amb altres ulls i adonar-me que no es tracta d'un codi abstrus davant meu, la complexitat prohibitiva de la qual no comprendré mai en la meva vida. Aquests són només patrons que es poden entendre sense problemes amb la curiositat deguda i la immersió profunda. Així és com les persones aprenen a programar i creixen com a desenvolupadors.
Reinventa aquesta roda
Així que endavant i reinventeu les rodes: escriviu el vostre propi codi d'enllaç de dades, creeu una promesa pròpia o fins i tot feu la vostra pròpia solució de gestió estatal.
No importa que ningú no faci servir mai tot això, però ara ja saps com fer-ho. I si teniu l'oportunitat d'utilitzar posteriorment aquests desenvolupaments en els vostres propis projectes, en general és genial. Podràs desenvolupar-los i aprendre alguna cosa més.
El punt aquí no és enviar el vostre codi a producció, sinó aprendre alguna cosa nova. Escriure la vostra pròpia implementació d'una solució existent és una manera fantàstica d'aprendre dels millors programadors i així perfeccionar les vostres habilitats.
Font: www.habr.com