Häromdagen intervjuade jag en JavaScript-utvecklare som sökte en ledande befattning. En kollega, som också var närvarande vid intervjun, bad kandidaten att skriva en funktion som skulle göra en HTTP-förfrågan och, om det misslyckas, försöka igen flera gånger.
Han skrev koden direkt på tavlan, så det skulle räcka med att rita något ungefärligt. Om han helt enkelt hade visat att han väl förstod vad det gällde hade vi varit ganska nöjda. Men tyvärr kunde han inte hitta en framgångsrik lösning. Sedan bestämde vi oss för att göra uppgiften lite lättare och bad honom att förvandla en funktion med återuppringningar till en funktion byggd på löften.
Men ändå. Ja, det var uppenbart att han hade stött på sådan kod tidigare. Han visste generellt hur allt fungerade där. Allt vi behöver är en skiss på en lösning som visar en förståelse för konceptet. Koden som kandidaten skrev på tavlan var dock fullständigt nonsens. Han hade en mycket vag uppfattning om vilka löften som fanns i JavaScript och kunde inte riktigt förklara varför de behövdes. För en junior skulle detta ha varit förlåtligt, men han var inte längre lämpad för positionen som senior. Hur skulle den här utvecklaren kunna fixa buggar i en komplex kedja av löften och förklara för andra vad han gjorde?
Utvecklare anser att färdig kod är självklar
Under utvecklingsprocessen möter vi ständigt reproducerbara material. Vi överför kodfragment så att vi inte behöver skriva om dem varje gång. Genom att fokusera all vår uppmärksamhet på nyckeldelarna ser vi följaktligen på den färdiga koden vi arbetar med som något självklart - vi antar helt enkelt att allt kommer att fungera som det ska.
Och vanligtvis fungerar det, men när saker och ting blir knepiga lönar det sig mer än att förstå mekaniken.
Vår kandidat till tjänsten som senior utvecklare ansåg således löftesobjekt som självklara. Han hade förmodligen en idé om hur han skulle hantera dem när de förekommer någonstans i någon annans kod, men han förstod inte den allmänna principen och kunde inte upprepa det själv under intervjun. Kanske kom han ihåg fragmentet utantill - det är inte så svårt:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Jag gjorde det också – och vi har nog alla gjort det någon gång. De memorerade helt enkelt en bit kod så att de senare kunde använda den i sitt arbete, samtidigt som de bara hade en allmän uppfattning om hur allt fungerade där. Men om utvecklaren verkligen förstod konceptet skulle han inte behöva komma ihåg någonting - han skulle helt enkelt veta hur man gör det och skulle lätt återskapa allt han behövde i kod.
Gå tillbaka till rötterna
2012, när dominansen av front-end-ramverk ännu inte hade etablerats, styrde jQuery världen, och jag läste boken , författad av John Resig, skapare av jQuery.
Boken lär läsaren hur man skapar sin egen jQuery från grunden och ger en unik inblick i tankeprocessen som ledde fram till bibliotekets tillkomst. De senaste åren har jQuery tappat sin tidigare popularitet, men jag rekommenderar fortfarande boken varmt. Det som slog mig mest med henne var den ihärdiga känslan av att jag kunde ha tänkt på allt detta själv. Stegen som författaren beskrev verkade så logiska, så tydliga att jag på allvar började tänka att jag lätt kunde skapa jQuery om jag bara kom till det.
Naturligtvis skulle jag i verkligheten inte ha kunnat göra något liknande – jag skulle ha bestämt mig för att det var outhärdligt svårt. Mina egna lösningar skulle verka för enkla och naiva för att fungera, och jag skulle ge upp. Jag skulle klassificera jQuery som självklara saker, i korrekt funktion som du bara måste blint tro på. Därefter skulle jag knappast slösa tid på att fördjupa mig i mekaniken i detta bibliotek, utan skulle helt enkelt använda det som en sorts svart låda.
Men att läsa den här boken gjorde mig till en annan person. Jag började läsa källkoden och upptäckte att implementeringen av många lösningar faktiskt var väldigt transparent, till och med uppenbar. Nej, självklart, att tänka på något sådant på egen hand är en annan historia. Men det är att studera andras kod och reproducera befintliga lösningar som hjälper oss att komma på något eget.
Inspirationen du får och mönstren du börjar lägga märke till kommer att förändra dig som utvecklare. Du kommer att upptäcka att det där underbara biblioteket som du ständigt använder och som du är van att tänka på som en magisk artefakt inte alls fungerar på magi, utan helt enkelt löser ett problem lakoniskt och fyndigt.
Ibland måste du gå igenom koden och analysera den steg för steg, men det är så här, i små, konsekventa steg, kan du upprepa författarens väg till lösningen. Detta gör att du kan dyka djupare in i kodningsprocessen och ge dig mer självförtroende när du kommer med dina egna lösningar.
När jag först började jobba med löften verkade det för mig som ren magi. Sedan fick jag reda på att de var baserade på samma callbacks, och min programmeringsvärld vände upp och ner. Så mönstret, vars syfte är att rädda oss från återuppringningar, implementeras i sig med hjälp av återuppringningar?!
Detta hjälpte mig att se på saken med andra ögon och inse att detta inte är någon abstruerad kod som jag har framför mig, vars oöverkomliga komplexitet jag aldrig kommer att förstå i mitt liv. Detta är bara mönster som kan förstås utan problem med tillbörlig nyfikenhet och djup fördjupning. Det är så människor lär sig att koda och växa som utvecklare.
Uppfinn detta hjul på nytt
Så fortsätt och uppfinn hjulen på nytt: skriv din egen databindande kod, skapa ett hembyggt löfte eller till och med skapa din egen statliga hanteringslösning.
Det spelar ingen roll att ingen någonsin kommer att använda allt detta - men nu vet du hur du gör det. Och om du har möjlighet att senare använda sådana utvecklingar i dina egna projekt, då är det generellt sett bra. Du kommer att kunna utveckla dem och lära dig något annat.
Poängen här är inte att skicka din kod till produktion, utan att lära dig något nytt. Att skriva din egen implementering av en befintlig lösning är ett utmärkt sätt att lära av de bästa programmerarna och på så sätt finslipa dina kunskaper.
Källa: will.com