Nemrégiben interjút tartottam egy JavaScript fejlesztővel, aki a szenior pozícióra pályázott. Egy kollégám, aki szintén részt vett az interjún, megkérte a jelöltet, hogy írjon egy olyan funkciót, amely HTTP kéréseket végez, és ha ez nem sikerül, többször próbálkozik.
A jelölt a táblán írta a kódot, így elegendő lett volna, ha körülbelül valami használhatót ábrázolt. Ha csak annyit mutatott volna, hogy jól érti, miről van szó, elégedettek lettünk volna. De sajnos nem tudott jó megoldást találni. Ezért, a feszültségét figyelembe véve, könnyítettük a feladatot, és megkértük, hogy a callback funkciót alakítsa át egy ígéretek (promise) alapú funkcióvá.
De sajnos. Igen, nyilvánvaló volt, hogy hasonló kódot már látott korábban. Nagyjából tudta, hogy működik az egész. Egy vázlat elegendő lett volna, ami bemutatja a koncepció megértését. Ám a táblán írt kód teljesen értelmetlen volt. Borzasztóan zavaros elképzelése volt arról, hogy mik azok az ígéretek a JavaScript-ben, és nem tudta konkrétan elmagyarázni, mire valók. Ez egy junior fejlesztő számára még elnézhető lett volna, de szenior pozícióra már nem volt alkalmas. Hogyan tudna ez a fejlesztő hibákat javítani egy bonyolult ígéretha-lmazáson, és elmagyarázni másoknak, mit is csinált?
A fejlesztők a kész kódot evidensnek tartják
A fejlesztési folyamat során folyamatosan találkozunk reprodukálható anyagokkal. Tördeljük a kód darabjait, hogy ne kelljen minden alkalommal újra leírni őket. Ennek megfelelően, minden figyelmünket a kulcsfontosságú részekre összpontosítva, a meglevő kódra úgy tekintünk, mint valami evidens dologra - egyszerűen feltételezzük, hogy minden rendben fog működni benne.
És általában tényleg működik, de amikor nehézségek merülnek fel, a mechanika megértése többet ér.
Így a szenior fejlesztő pozícióra pályázó jelölt evidensnek tartotta a promise objektumokat. Valószínűleg tudta, hogyan kell velük bánni, amikor mások kódjában találkozott velük, de az általános elvet nem értette meg, és nem tudta a saját szavaival megismételni az interjún. Lehetséges, hogy egy részletet kívülről megtanult - ez nem olyan nehéz:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Én is így tettem – valószínűleg mindannyian így tettünk valamikor. Csak bemagoltunk egy kódot, hogy később felhasználhassuk a munkánk során, anélkül hogy valójában tudtuk volna, hogyan is működik az egész. De ha a fejlesztő valóban megértené a koncepciót, akkor nem kellett volna semmit sem bemagolnia – egyszerűen tudta volna, hogyan kell csinálni, és könnyedén reprodukálta volna a szükségeset a kódban.
Térjünk vissza a gyökerekhez
2012-ben, amikor még nem bontakozott ki a front-end keretrendszerek uralma, a világot a jQuery uralta, és olvastam egy könyvet , amelyet John Resig, a jQuery alkotója írt.
A könyv megtanítja az olvasót, hogyan készíthet saját jQuery-t a nulláról, és egyedülálló lehetőséget ad arra, hogy betekinthessünk abba a gondolkodásmódba, amely a könyvtár létrehozásához vezetett. Az utóbbi években a jQuery elvesztette korábbi népszerűségét, de a könyvet mindenképpen ajánlom. Ami leginkább meglepett benne – az a kitartó érzés volt, hogy én is kitalálhattam volna mindezt. Az író által leírt lépések annyira logikusnak, annyira érthetőnek tűntek, hogy komolyan olyan érzésem volt, mintha én is könnyedén létrehozhattam volna a jQuery-t, ha csak nekiláttam volna.
Természetesen valójában semmi ilyesmit nem tudtam volna elérni – azt gondoltam volna, hogy ez túlságosan nehéz. A saját megoldásaim túlságosan egyszerűnek és naivnak tűntek ahhoz, hogy működjenek, és feladtam volna. A jQuery-t evidens dolognak tekintettem, ami helyes működéséhez csak vakon hinni kellett. Később valószínűleg nem pazaroltam volna időt arra, hogy belemerüljek ennek a könyvtárnak a mechanikájába, hanem egyszerűen úgy használtam volna, mint egy fekete dobozt.
De ennek a könyvnek a megismerése más emberré változtatott. Elkezdtem belemerülni a forráskódba, és felfedeztem, hogy sok megoldás megvalósítása valójában nagyon átlátható, sőt nyilvánvaló. Nem, természetesen az, hogy valaki saját maga kitalálja mindezt – egy másik történet. De éppen a mások kódjának tanulmányozása és a már meglévő megoldások reprodukálása segít nekünk abban, hogy valami újat találjunk ki.
Az inspiráció, amit merítesz, és a minták, amelyeket kezdesz észrevenni, megváltoztatnak téged fejlesztőként. Rájössz, hogy az a csodálatos könyvtár, amelyet folyamatosan használsz és mágikus erejű artefaktumnak gondolsz, valójában nem varázslat, hanem egyszerűen ügyesen megold egy problémát.
Néha a kóddal szorgoskodni kell, lépésről lépésre elemezve azt, de éppen így, apró lépésekkel haladva tudod megismételni a szerző útját a megoldás felé. Ez lehetővé teszi, hogy mélyebben belemerülj a kódírás folyamatába, és több magabiztosságot nyújt a saját megoldásaid keresésében.
Amikor először kezdtem dolgozni a promise-okat, úgy tűnt, hogy ez tiszta varázslat. Aztán megtudtam, hogy a hátterükben ugyanazok a visszahívások állnak, és a programozói világom megfordult. Tehát a minta, amelynek célja, hogy megszabadítson minket a visszahívásoktól, valójában visszahívásokkal valósul meg?!
Ez segített más szemszögből nézni a dolgokat, és rájönni, hogy előttem nem valami bonyolult kódok állnak, amelyeket soha az életben nem fogok megérteni. Ezek csupán minták, amelyeket megfelelő kíváncsisággal és mélyebb belemerüléssel könnyedén meg lehet érteni. Pontosan így tanulnak meg az emberek programozni, és így fejlődnek fejlesztőkké.
Találd fel újra a kereket.
Tehát bátran találj fel újra kerekeket: írd meg maga a kódot az adatok összekapcsolására, készíts egy házi írású promissal, vagy építs magad egy állapotkezelő megoldást.
Nem számít, hogy ezekkel soha senki nem fog élni – most már tudod. Ha pedig lehetőséged van később használni ezeket a fejlesztéseket saját projektjeidben, az igazán nagyszerű. Fejlesztheted őket, és új dolgokat tanulhatsz.
A lényeg itt nem az, hogy eljuttasd a kódodat a termelésbe, hanem hogy megtanulj valami újat. A már létező megoldás implementálásának önálló megírása nagyszerű módja, hogy a legjobb programozóktól tanulj, és így csiszoljad a szakmai tudásodat.
Forrás: habr.com
