La alian tagon mi intervjuis JavaScript-programiston, kiu kandidatiĝis por altranga posteno. Kolego, kiu ankaŭ ĉeestis ĉe la intervjuo, petis la kandidaton verki funkcion, kiu farus HTTP-peton kaj, se malsukcese, reprovi plurfoje.
Li skribis la kodon rekte sur la tabulo, do sufiĉus desegni ion proksimuman. Se li simple montrus, ke li bone komprenas, kio estas la afero, ni estus tute kontentaj. Sed, bedaŭrinde, li ne povis trovi sukcesan solvon. Tiam ni, kredante ĝin al ekscito, decidis iom plifaciligi la taskon kaj petis lin turni funkcion kun revokoj en funkcion konstruitan sur promesoj.
Sed ve. Jes, estis evidente, ke li antaŭe renkontis tian kodon. Li sciis ĝenerale, kiel ĉio funkcias tie. Ni bezonas nur skizon de solvo, kiu pruvas komprenon de la koncepto. Tamen, la kodo, kiun la kandidato skribis sur la tabulo, estis tute sensencaĵo. Li havis tre malklaran ideon pri kio promesoj estas en JavaScript kaj ne povis vere klarigi kial ili estas bezonataj. Por junulo tio estus pardonebla, sed li ne plu konvenis al la posteno de maljunulo. Kiel ĉi tiu programisto povus ripari erarojn en kompleksa ĉeno de promesoj kaj klarigi al aliaj, kion li precize faris?
Programistoj konsideras pretan kodon memkomprenebla
Dum la evoluprocezo, ni konstante renkontas reprodukteblajn materialojn. Ni transdonas kodfragmentojn por ke ni ne devas reskribi ilin ĉiufoje. Sekve, enfokusigante nian tutan atenton al la ŝlosilaj partoj, ni rigardas la finitan kodon, kun kiu ni laboras, kiel ion memkompreneblan - ni simple supozas, ke ĉio funkcios kiel ĝi devus.
Kaj kutime ĝi funkcias, sed kiam aferoj fariĝas malfacilaj, kompreni la mekanikon pli ol pagas.
Tiel, nia kandidato por la posteno de altranga programisto konsideris promesobjektojn memkompreneblaj. Li verŝajne havis ideon pri kiel trakti ilin kiam ili okazas ie en la kodo de aliulo, sed li ne komprenis la ĝeneralan principon kaj ne povis ripeti ĝin mem dum la intervjuo. Eble li memoris la fragmenton parkere - ĝi ne estas tiel malfacila:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Mi faris ĝin ankaŭ - kaj ni verŝajne ĉiuj faris ĝin iam. Ili simple enmemorigis kodon, por ke ili poste povu uzi ĝin en sia laboro, havante nur ĝeneralan ideon pri kiel ĉio funkciis tie. Sed se la programisto vere komprenus la koncepton, li ne devus memori ion ajn - li simple scius kiel fari ĝin, kaj facile reproduktus ĉion, kion li bezonis en kodo.
Reiru al la radikoj
En 2012, kiam la regado de antaŭfinaj kadroj ankoraŭ ne estis establita, jQuery regis la mondon, kaj mi legis la libron. , verkita de John Resig, kreinto de jQuery.
La libro instruas al la leganto kiel krei sian propran jQuery de nulo kaj provizas unikan komprenon pri la pensprocezo kiu kondukis al la kreado de la biblioteko. En la lastaj jaroj, jQuery perdis sian iaman popularecon, sed mi ankoraŭ forte rekomendas la libron. Kio plej frapis min pri ŝi estis la persista sento, ke mi mem povus pensi pri ĉio ĉi. La paŝoj, kiujn la aŭtoro priskribis, ŝajnis tiel logikaj, tiel klaraj, ke mi serioze ekpensis, ke mi povus facile krei jQuery se mi nur ekkomprenus ĝin.
Kompreneble, en la realo mi ne povintus fari ion tian – mi estus decidinta, ke ĝi estas neelteneble malfacila. Miaj propraj solvoj ŝajnus tro simplaj kaj naivaj por funkcii, kaj mi rezignus. Mi klasifikus jQuery kiel memkompreneblajn aferojn, en kies ĝusta funkciado vi nur bezonas blinde kredi. Poste, mi apenaŭ perdus tempon enprofundiĝante en la mekanikon de ĉi tiu biblioteko, sed simple uzus ĝin kiel specon de nigra skatolo.
Sed legado de ĉi tiu libro igis min malsama homo. Mi komencis legi la fontkodon kaj malkovris ke la efektivigo de multaj solvoj estas fakte tre travidebla, eĉ evidenta. Ne, kompreneble, pensi pri io tia memstare estas malsama historio. Sed ĝi studas la kodon de aliaj homoj kaj reproduktas ekzistantajn solvojn, kiuj helpas nin elpensi ion propran.
La inspiro, kiun vi akiras kaj la ŝablonoj, kiujn vi komencas rimarki, ŝanĝos vin kiel programisto. Vi trovos, ke tiu mirinda biblioteko, kiun vi konstante uzas kaj kiun vi kutimas pensi kiel magian artefakton, tute ne funkcias pri magio, sed simple solvas problemon lakone kaj eltrove.
Kelkfoje vi devos esplori la kodon, analizante ĝin paŝon post paŝo, sed jen kiel, moviĝante en malgrandaj, konsekvencaj paŝoj, vi povas ripeti la vojon de la aŭtoro al la solvo. Ĉi tio permesos al vi plonĝi pli profunde en la kodigan procezon kaj donos al vi pli da konfido pri elpensi viajn proprajn solvojn.
Kiam mi unue eklaboris kun promesoj, ĝi ŝajnis al mi pura magio. Tiam mi eksciis, ke ili baziĝas sur la samaj alvokoj, kaj mia programa mondo renversiĝis. Do la ŝablono, kies celo estas savi nin de revokoj, estas mem efektivigita uzante revokojn?!
Tio helpis min rigardi la aferon per malsamaj okuloj kaj konscii, ke ĉi tio ne estas ia abstrusa kodo antaŭ mi, kies malpermesan kompleksecon mi neniam komprenos en mia vivo. Ĉi tiuj estas nur ŝablonoj, kiuj povas esti komprenataj sen problemoj kun konvena scivolemo kaj profunda mergo. Jen kiel homoj lernas kodi kaj kreski kiel programistoj.
Reinventu ĉi tiun radon
Do antaŭeniru kaj reinventu la radojn: skribu vian propran datuman biligan kodon, kreu hejman promeson aŭ eĉ faru vian propran ŝtatadministran solvon.
Ne gravas, ke neniu iam uzos ĉion ĉi - sed nun vi scias kiel fari ĝin. Kaj se vi havas la ŝancon poste uzi tiajn evoluojn en viaj propraj projektoj, tiam tio ĝenerale estas bonega. Vi povos disvolvi ilin kaj lerni ion alian.
La punkto ĉi tie ne estas sendi vian kodon al produktado, sed lerni ion novan. Skribi vian propran efektivigon de ekzistanta solvo estas bonega maniero lerni de la plej bonaj programistoj kaj tiel plibonigi viajn kapablojn.
fonto: www.habr.com