Pred dnevi sem intervjuval razvijalca JavaScripta, ki se je potegoval za višji položaj. Kolega, ki je bil tudi prisoten na razgovoru, je od kandidata zahteval, da napiše funkcijo, ki bo naredila HTTP zahtevo in v primeru neuspeha večkrat poskusila.
Šifro je napisal neposredno na tablo, tako da bi bilo dovolj, če bi narisal nekaj približnega. Če bi preprosto pokazal, da dobro razume, za kaj gre, bi bili kar zadovoljni. Toda na žalost mu ni uspelo najti uspešne rešitve. Nato smo se z navdušenjem odločili, da bomo nalogo nekoliko olajšali, in ga prosili, naj spremeni funkcijo s povratnimi klici v funkcijo, zgrajeno na obljubah.
Ampak žal. Ja, očitno je bilo, da se je že srečal s takšno kodo. Na splošno je vedel, kako tam vse deluje. Vse, kar potrebujemo, je skica rešitve, ki prikazuje razumevanje koncepta. Šifra, ki jo je kandidat napisal na tablo, pa je bila popolna neumnost. Imel je zelo nejasno predstavo o tem, kaj so obljube v JavaScriptu, in ni znal razložiti, zakaj so bile potrebne. Za mladinca bi bilo to odpustljivo, a ni bil več primeren za položaj seniorja. Kako bi lahko ta razvijalec popravil napake v kompleksni verigi obljub in drugim razložil, kaj točno je naredil?
Razvijalci menijo, da je pripravljena koda samoumevna
Med razvojnim procesom se nenehno srečujemo s ponovljivimi materiali. Delčke kode prenesemo, da nam jih ni treba vsakič znova pisati. Skladno s tem, ko vso pozornost usmerimo na ključne dele, na končano kodo, s katero delamo, gledamo kot na nekaj samoumevnega – preprosto predvidevamo, da bo vse delovalo, kot mora.
In običajno deluje, a ko se stvari zapletejo, se razumevanje mehanike več kot izplača.
Tako je naš kandidat za položaj senior developer menil, da so obljubljeni objekti samoumevni. Verjetno je imel idejo, kako ravnati z njimi, ko se pojavijo nekje v kodi nekoga drugega, vendar splošnega principa ni razumel in ga sam med intervjujem ni mogel ponoviti. Morda si je fragment zapomnil na pamet - ni tako težko:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Tudi jaz sem to storil - in verjetno smo vsi to storili kdaj. Enostavno so si zapomnili delček kode, da so ga kasneje lahko uporabili pri svojem delu, medtem ko so imeli le splošno predstavo o tem, kako vse tam deluje. Toda če bi razvijalec resnično razumel koncept, mu ne bi bilo treba ničesar zapomniti - preprosto bi vedel, kako to storiti, in bi zlahka reproduciral vse, kar potrebuje v kodi.
Vrni se h koreninam
Leta 2012, ko še ni bila vzpostavljena prevlada front-end ogrodij, je jQuery vladal svetu in prebral sem knjigo , avtor John Resig, ustvarjalec jQuery.
Knjiga bralca uči, kako iz nič ustvariti lasten jQuery, in ponuja edinstven vpogled v miselni proces, ki je pripeljal do nastanka knjižnice. V zadnjih letih je jQuery izgubil nekdanjo priljubljenost, vendar knjigo še vedno toplo priporočam. Kar me je pri njej najbolj presenetilo, je bil vztrajen občutek, da bi se lahko vsega tega domislil sam. Koraki, ki jih je opisal avtor, so se zdeli tako logični, tako jasni, da sem resno začel razmišljati, da bi zlahka ustvaril jQuery, če bi se ga le lotil.
Seveda v resnici ne bi mogel storiti ničesar takega - odločil bi se, da je neznosno težko. Moje lastne rešitve bi se zdele preveč preproste in naivne, da bi delovale, in bi obupal. jQuery bi uvrstil med samoumevne stvari, v pravilno delovanje katerih je treba le slepo verjeti. Kasneje ne bi izgubljal časa s poglabljanjem v mehaniko te knjižnice, ampak bi jo preprosto uporabil kot nekakšno črno skrinjico.
Toda branje te knjige me je spremenilo v drugo osebo. Začel sem brati izvorno kodo in ugotovil, da je implementacija mnogih rešitev v resnici zelo pregledna, celo očitna. Ne, kaj takega si omisliti sam, seveda je druga zgodba. Toda preučevanje kode drugih ljudi in reproduciranje obstoječih rešitev nam pomaga priti do nečesa našega.
Navdih, ki ga pridobite, in vzorci, ki jih začnete opažati, vas bodo spremenili kot razvijalca. Ugotovili boste, da ta čudovita knjižnica, ki jo nenehno uporabljate in o kateri ste navajeni razmišljati kot o čarobnem artefaktu, sploh ne deluje na magijo, ampak preprosto rešuje problem lakonično in iznajdljivo.
Včasih se boste morali poglobiti v kodo in jo analizirati korak za korakom, a tako lahko z majhnimi doslednimi koraki ponovite avtorjevo pot do rešitve. To vam bo omogočilo, da se poglobite v proces kodiranja in vam bo dalo več samozavesti pri iskanju lastnih rešitev.
Ko sem prvič začel delati z obljubami, se mi je zdelo kot čista čarovnija. Potem sem ugotovil, da temeljijo na istih povratnih klicih, in moj programski svet se je obrnil na glavo. Torej je vzorec, katerega namen je, da nas reši povratnih klicev, sam implementiran s pomočjo povratnih klicev?!
To mi je pomagalo pogledati na zadevo z drugimi očmi in ugotoviti, da pred mano ni nek neumna koda, katere previsoke kompleksnosti ne bom dojel nikoli v življenju. To so le vzorci, ki jih je mogoče brez težav razumeti z ustrezno radovednostjo in globoko poglobljenostjo. Tako se ljudje naučijo kodirati in rastejo kot razvijalci.
Ponovno izumite to kolo
Zato pojdite naprej in znova izumite kolesa: napišite lastno kodo za vezavo podatkov, ustvarite domačo obljubo ali celo naredite svojo lastno rešitev za upravljanje stanja.
Ni pomembno, da nihče ne bo nikoli uporabil vsega tega - toda zdaj veste, kako to storiti. In če imate možnost pozneje uporabiti tak razvoj v svojih projektih, potem je to na splošno super. Lahko jih boste razvijali in se še česa naučili.
Tukaj ni bistvo, da pošljete kodo v produkcijo, ampak da se naučite nekaj novega. Pisanje lastne implementacije obstoječe rešitve je odličen način, da se učite od najboljših programerjev in tako izpopolnite svoje veščine.
Vir: www.habr.com