Pre neki dan sam intervjuisao JavaScript programera koji se prijavljuje za višu poziciju. Kolega, koji je također bio prisutan na intervjuu, zamolio je kandidata da napiše funkciju koja će napraviti HTTP zahtjev i, ako ne uspije, ponoviti nekoliko puta.
Šifru je napisao direktno na tabli, tako da bi bilo dovoljno nacrtati nešto približno. Da je jednostavno pokazao da dobro razumije o čemu se radi, bili bismo sasvim zadovoljni. Ali, nažalost, nije uspio pronaći uspješno rješenje. Tada smo, pripisujući to uzbuđenju, odlučili malo olakšati zadatak i zamolili ga da pretvori funkciju s povratnim pozivima u funkciju izgrađenu na obećanjima.
Ali avaj. Da, bilo je očito da se s takvim kodom već susreo. Općenito je znao kako sve tamo funkcionira. Sve što nam treba je skica rješenja koja pokazuje razumijevanje koncepta. Međutim, šifra koju je kandidat napisao na tabli je potpuna glupost. Imao je vrlo nejasnu ideju o tome šta su obećanja u JavaScriptu i nije mogao da objasni zašto su ona potrebna. Za juniora bi to bilo oprostivo, ali on više nije odgovarao poziciji seniora. Kako bi ovaj programer mogao da popravi greške u složenom lancu obećanja i objasni drugima šta je tačno uradio?
Programeri smatraju da je gotov kod očigledan
Tokom procesa razvoja, stalno se susrećemo sa ponovljivim materijalima. Prenosimo fragmente koda kako ih ne bismo morali svaki put ponovo pisati. Shodno tome, usmjeravajući svu pažnju na ključne dijelove, na gotov kod s kojim radimo gledamo kao na nešto što je samo po sebi razumljivo – jednostavno pretpostavljamo da će sve funkcionirati kako treba.
I obično radi, ali kada stvari postanu nezgodne, razumijevanje mehanike se više nego isplati.
Stoga je naš kandidat za poziciju starijeg programera smatrao da su obećani objekti očigledni. Vjerovatno je imao ideju kako se nositi s njima kada se pojave negdje u tuđem kodeksu, ali nije razumio opći princip i nije mogao sam to ponoviti tokom intervjua. Možda je zapamtio fragment napamet - nije tako teško:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});I ja sam to uradio - i verovatno smo svi to uradili u nekom trenutku. Jednostavno su zapamtili dio koda kako bi ga kasnije mogli koristiti u svom radu, dok su imali samo opću predstavu o tome kako sve tamo funkcionira. Ali da je programer zaista shvatio koncept, ne bi morao ništa da pamti – on bi jednostavno znao kako to da uradi i lako bi reprodukovao sve što mu je potrebno u kodu.
Vrati se korenima
Godine 2012, kada dominacija front-end okvira još nije bila uspostavljena, jQuery je vladao svijetom, a ja sam pročitao knjigu , čiji je autor John Resig, tvorac jQueryja.
Knjiga uči čitaoca kako da kreira sopstveni jQuery od nule i pruža jedinstven uvid u misaoni proces koji je doveo do stvaranja biblioteke. Poslednjih godina jQuery je izgubio svoju nekadašnju popularnost, ali još uvek toplo preporučujem knjigu. Ono što me je najviše pogodilo kod nje je uporan osjećaj da sam sve ovo mogao i sam smisliti. Koraci koje je autor opisao činili su se tako logičnim, toliko jasnim da sam ozbiljno počeo da razmišljam da bih lako mogao da kreiram jQuery ako se samo uhvatim toga.
Naravno, u stvarnosti ovako nešto ne bih mogao – zaključio bih da je to nepodnošljivo teško. Moja vlastita rješenja bi se činila previše jednostavna i naivna da bi uspjela, pa bih odustao. Ja bih jQuery svrstao u samorazumljive stvari u čije ispravno funkcionisanje samo treba slijepo vjerovati. Nakon toga, teško da bih gubio vrijeme upuštajući se u mehaniku ove biblioteke, već bih je jednostavno koristio kao neku vrstu crne kutije.
Ali čitanje ove knjige učinilo me drugom osobom. Počeo sam čitati izvorni kod i otkrio da je implementacija mnogih rješenja zapravo vrlo transparentna, čak očigledna. Ne, naravno, razmišljati o nečemu ovako na svoju ruku je druga priča. Ali proučavanje koda drugih ljudi i reproduciranje postojećih rješenja pomaže nam da smislimo nešto svoje.
Inspiracija koju steknete i obrasci koje počnete primjećivati promijenit će vas kao programera. Uvidjet ćete da ta divna biblioteka koju stalno koristite i koju ste navikli smatrati magičnim artefaktom uopće ne djeluje na magiju, već jednostavno rješava problem lakonski i snalažljivo.
Ponekad ćete morati proučiti kod, analizirajući ga korak po korak, ali ovako, krećući se malim, dosljednim koracima, možete ponoviti autorov put do rješenja. To će vam omogućiti da dublje zaronite u proces kodiranja i dati vam više samopouzdanja u pronalaženju vlastitih rješenja.
Kada sam tek počeo da radim sa obećanjima, to mi se činilo kao čista magija. Tada sam saznao da su zasnovani na istim povratnim pozivima i moj svijet programiranja se okrenuo naglavačke. Dakle, obrazac, čija je svrha da nas spasi od povratnih poziva, sam implementiran pomoću povratnih poziva?!
To mi je pomoglo da sagledam stvar drugim očima i shvatim da ovo nije neki zamućeni komad koda preda mnom, čiju previsoku složenost nikada u životu neću shvatiti. Ovo su samo obrasci koji se mogu razumjeti bez problema uz dužnu radoznalost i duboko udubljenje. Ovo je način na koji ljudi uče da kodiraju i rastu kao programeri.
Izmislite ovaj točak
Dakle, samo naprijed i izmislite kotače: napišite svoj vlastiti kod za obvezivanje podataka, kreirajte domaće obećanje ili čak napravite vlastito rješenje za upravljanje stanjem.
Nije važno što sve ovo niko nikada neće koristiti - ali sada znate kako to učiniti. A ako imate priliku naknadno koristiti takav razvoj u vlastitim projektima, onda je to općenito sjajno. Moći ćete ih razviti i naučiti nešto drugo.
Poenta ovdje nije da pošaljete svoj kod u proizvodnju, već da naučite nešto novo. Pisanje vlastite implementacije postojećeg rješenja odličan je način da učite od najboljih programera i tako usavršite svoje vještine.
izvor: www.habr.com