Neki dan sam intervjuirao JavaScript programera koji se prijavio za višu poziciju. Kolega, koji je također bio na razgovoru, zamolio je kandidata da napiše funkciju koja bi napravila HTTP zahtjev i, ako ne uspije, ponovi nekoliko puta.
Šifru je napisao direktno na ploču, pa bi bilo dovoljno nacrtati nešto približno. Da je samo pokazao da dobro razumije o čemu se radi, bili bismo sasvim zadovoljni. Ali, nažalost, nije uspio pronaći uspješno rješenje. Zatim smo, uz uzbuđenje, odlučili malo olakšati zadatak i zamolili ga da pretvori funkciju s povratnim pozivima u funkciju izgrađenu na obećanjima.
Ali jao. Da, bilo je očito da se s takvim kodom već susretao. Znao je općenito kako sve tamo funkcionira. Sve što trebamo je skica rješenja koja pokazuje razumijevanje koncepta. Međutim, šifra koju je kandidat ispisao na ploču bila je potpuna besmislica. Imao je vrlo nejasnu ideju o tome što obećanja postoje u JavaScriptu i nije mogao objasniti zašto su potrebna. Junioru bi to bilo oprostivo, ali on više nije dorastao poziciji seniora. Kako bi ovaj programer mogao ispraviti greške u složenom lancu obećanja i objasniti drugima što je točno napravio?
Programeri smatraju gotov kod samorazumljivim
Tijekom procesa razvoja stalno se susrećemo s ponovljivim materijalima. Prenosimo fragmente koda tako da ih ne moramo svaki put iznova pisati. Sukladno tome, usmjeravajući svu pažnju na ključne dijelove, na gotov kod s kojim radimo gledamo kao na nešto samorazumljivo – jednostavno pretpostavljamo da će sve raditi 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 obećane objekte smatrao samorazumljivima. Vjerojatno je imao ideju kako se nositi s njima kada se pojave negdje u tuđem kodu, ali nije razumio opći princip i nije ga mogao sam ponoviti tijekom 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 učinio - a vjerojatno smo svi to učinili u nekom trenutku. Jednostavno su zapamtili dio koda kako bi ga kasnije mogli koristiti u svom radu, a pritom su imali samo opću predodžbu o tome kako sve tamo funkcionira. Ali ako bi programer uistinu razumio koncept, ne bi morao ništa pamtiti - on bi jednostavno znao kako to učiniti, i lako bi reproducirao sve što mu je potrebno u kodu.
Vratite se korijenima
2012., kada još nije bila uspostavljena dominacija front-end frameworka, jQuery je vladao svijetom, a ja sam pročitao knjigu , čiji je autor John Resig, kreator jQueryja.
Knjiga uči čitatelja kako stvoriti vlastiti jQuery od nule i pruža jedinstveni uvid u misaoni proces koji je doveo do stvaranja knjižnice. Posljednjih godina jQuery je izgubio svoju bivšu popularnost, ali knjigu i dalje toplo preporučujem. Ono što me se kod nje najviše dojmilo bio je uporni osjećaj da sam se svega ovoga mogao i sam sjetiti. Koraci koje je autor opisao činili su se toliko logičnim, toliko jasnim da sam ozbiljno počeo razmišljati kako bih mogao lako stvoriti jQuery ako se samo bacim na to.
Naravno, u stvarnosti ne bih mogao učiniti ništa slično - zaključio bih da je to nepodnošljivo teško. Moja bi se vlastita rješenja činila prejednostavna i naivna za funkcioniranje, pa bih odustao. jQuery bih svrstao u samorazumljive stvari u čiji ispravan rad samo treba slijepo vjerovati. Naknadno, teško da bih gubio vrijeme na udubljivanje u mehaniku ove knjižnice, 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čita. Ne, naravno, druga je priča smisliti ovako nešto sam. Ali proučavanje koda drugih ljudi i reproduciranje postojećih rješenja nam pomaže da smislimo nešto svoje.
Inspiracija koju dobijete 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 lakonski i domišljato rješava problem.
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 iznalaženju vlastitih rješenja.
Kad sam tek počeo raditi s obećanjima, to mi se činilo kao čista magija. Onda sam saznao da se temelje na istim povratnim pozivima i moj programski svijet se okrenuo naglavačke. Dakle, obrazac, čija je svrha da nas spasi od povratnih poziva, sam je implementiran pomoću povratnih poziva?!
To mi je pomoglo da stvar sagledam drugim očima i shvatim da ovo nije neki zamršeni kodeks ispred mene, čiju pretjeranu složenost nikada u životu neću shvatiti. To su samo obrasci koji se mogu razumjeti bez problema uz dužnu znatiželju i duboko poniranje. Ovo je način na koji ljudi uče programirati i rastu kao programeri.
Ponovno izumite ovaj kotač
Stoga samo naprijed i ponovno izumite kotače: napišite vlastiti kod za vezanje podataka, stvorite domaće obećanje ili čak napravite vlastito rješenje za upravljanje stanjem.
Nije važno što sve ovo nitko 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.
Ovdje nije poanta poslati svoj kod u produkciju, već naučiti 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