Zilele trecute am intervievat un dezvoltator JavaScript care aplica pentru un post superior. Un coleg, care a fost și el prezent la interviu, i-a cerut candidatului să scrie o funcție care să facă o solicitare HTTP și, dacă nu va reuși, să reîncerce de mai multe ori.
A scris codul direct pe tablă, așa că ar fi suficient să desenezi ceva aproximativ. Dacă ar fi arătat pur și simplu că a înțeles bine care este treaba, am fi fost destul de mulțumiți. Dar, din păcate, nu a reușit să găsească o soluție de succes. Apoi, am decis să facem sarcina puțin mai ușoară și i-am cerut să transforme o funcție cu apeluri inverse într-o funcție construită pe promisiuni.
Dar vai! Da, era evident că mai întâlnise un astfel de cod. Știa în termeni generali cum funcționează totul acolo. Tot ce ne trebuie este o schiță a unei soluții care să demonstreze înțelegerea conceptului. Totuși, codul pe care candidatul l-a scris pe tablă a fost o prostie totală. Avea o idee foarte vagă despre promisiunile în JavaScript și nu putea explica cu adevărat de ce erau necesare. Pentru un junior acest lucru ar fi fost de scuzat, dar nu mai era potrivit pentru postul de senior. Cum ar putea acest dezvoltator să remedieze erorile dintr-un lanț complex de promisiuni și să explice altora ce a făcut exact?
Dezvoltatorii consideră că codul gata făcut este de la sine înțeles
În timpul procesului de dezvoltare, întâlnim în mod constant materiale reproductibile. Transferăm fragmente de cod, astfel încât să nu fie nevoie să le rescriem de fiecare dată. În consecință, concentrându-ne toată atenția asupra părților cheie, privim codul finit cu care lucrăm ca pe ceva evident - pur și simplu presupunem că totul va funcționa așa cum ar trebui.
Și, de obicei, funcționează, dar atunci când lucrurile devin dificile, înțelegerea mecanicii se plătește mai mult decât.
Astfel, candidatul nostru pentru postul de dezvoltator senior a considerat obiectele promisiunii ca fiind de la sine înțelese. Probabil că avea o idee despre cum să se ocupe de ei atunci când apar undeva în codul altcuiva, dar nu înțelegea principiul general și nu l-a putut repeta el însuși în timpul interviului. Poate că și-a amintit fragmentul pe de rost - nu este atât de dificil:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Am făcut-o și eu - și probabil că toți am făcut-o la un moment dat. Pur și simplu au memorat o bucată de cod pentru a o putea folosi ulterior în munca lor, având în același timp doar o idee generală despre cum a funcționat totul acolo. Dar dacă dezvoltatorul ar înțelege cu adevărat conceptul, nu ar trebui să-și amintească nimic - ar ști pur și simplu cum să o facă și ar reproduce cu ușurință tot ce avea nevoie în cod.
Întoarce-te la rădăcini
În 2012, când dominația framework-urilor front-end nu fusese încă stabilită, jQuery a condus lumea și am citit cartea , scris de John Resig, creatorul jQuery.
Cartea învață cititorul cum să-și creeze propriul jQuery de la zero și oferă o perspectivă unică asupra procesului de gândire care a condus la crearea bibliotecii. În ultimii ani, jQuery și-a pierdut popularitatea anterioară, dar încă recomand cu căldură cartea. Ceea ce m-a frapat cel mai mult la ea a fost sentimentul persistent că m-aș fi putut gândi la toate acestea. Pașii pe care i-a descris autorul mi s-au părut atât de logici, atât de clari, încât am început serios să mă gândesc că aș putea crea cu ușurință jQuery dacă aș ajunge doar la asta.
Desigur, în realitate nu aș fi putut face așa ceva - aș fi decis că a fost insuportabil de greu. Soluțiile mele ar părea prea simple și naive pentru a funcționa și aș renunța. Aș clasifica jQuery drept lucruri evidente, în funcționarea corectă a cărora trebuie doar să crezi orbește. Ulterior, cu greu aș pierde timpul să mă aprofundez în mecanica acestei biblioteci, ci aș folosi-o pur și simplu ca un fel de cutie neagră.
Dar citirea acestei cărți m-a făcut o persoană diferită. Am început să citesc codul sursă și am descoperit că implementarea multor soluții era de fapt foarte transparentă, chiar evidentă. Nu, desigur, să te gândești la așa ceva pe cont propriu este o altă poveste. Dar studiem codul altor oameni și reproducem soluțiile existente care ne ajută să găsim ceva propriu.
Inspirația pe care o câștigi și tiparele pe care începi să le observi te vor schimba ca dezvoltator. Vei constata că acea bibliotecă minunată pe care o folosești constant și la care te-ai obișnuit să o gândești ca pe un artefact magic nu funcționează deloc la magie, ci pur și simplu rezolvă o problemă laconic și cu resurse.
Uneori va trebui să studiezi codul, analizându-l pas cu pas, dar așa, mergând în pași mici, consecvenți, poți repeta calea autorului către soluție. Acest lucru vă va permite să vă scufundați mai adânc în procesul de codificare și vă va oferi mai multă încredere în găsirea propriilor soluții.
Când am început să lucrez cu promisiuni, mi s-a părut o magie pură. Apoi am aflat că se bazează pe aceleași apeluri inverse, iar lumea mea de programare s-a întors cu susul în jos. Deci modelul, al cărui scop este să ne salveze de apeluri inverse, este el însuși implementat folosind apeluri inverse?!
Acest lucru m-a ajutat să privesc problema cu alți ochi și să realizez că aceasta nu este o bucată de cod abstrus în fața mea, a cărei complexitate prohibitivă nu o voi înțelege niciodată în viața mea. Acestea sunt doar modele care pot fi înțelese fără probleme cu curiozitatea și imersiunea profundă. Acesta este modul în care oamenii învață să codifice și să crească ca dezvoltatori.
Reinventează această roată
Așa că mergeți mai departe și reinventați roțile: scrieți propriul cod de legare a datelor, creați o promisiune de acasă sau chiar creați-vă propria soluție de gestionare a statului.
Nu contează că nimeni nu va folosi vreodată toate acestea - dar acum știi cum să o faci. Și dacă aveți ocazia să utilizați ulterior astfel de dezvoltări în propriile proiecte, atunci este în general grozav. Veți putea să le dezvoltați și să învățați altceva.
Ideea aici nu este să trimiteți codul în producție, ci să învățați ceva nou. Scrierea propriei implementări a unei soluții existente este o modalitate excelentă de a învăța de la cei mai buni programatori și, astfel, de a vă perfecționa abilitățile.
Sursa: www.habr.com