Toissapäivänä haastattelin JavaScript-kehittäjää, joka haki johtoon. Myös haastattelussa ollut kollega pyysi hakijaa kirjoittamaan toiminnon, joka tekisi HTTP-pyynnön ja epäonnistuisi yrittämään uudelleen useita kertoja.
Hän kirjoitti koodin suoraan taululle, joten riittäisi piirtää jotain likimääräistä. Jos hän olisi vain osoittanut ymmärtävänsä hyvin mistä on kysymys, olisimme olleet varsin tyytyväisiä. Mutta valitettavasti hän ei löytänyt onnistunutta ratkaisua. Sitten innostuimme, päätimme tehdä tehtävästä hieman helpompaa ja pyysimme häntä muuttamaan takaisinkutsun sisältävän toiminnon lupauksiin rakennetuksi funktioksi.
Mutta valitettavasti. Kyllä, oli ilmeistä, että hän oli törmännyt tällaiseen koodiin aiemmin. Hän tiesi yleisesti, kuinka kaikki siellä toimi. Tarvitsemme vain luonnoksen ratkaisusta, joka osoittaa konseptin ymmärtämisen. Kuitenkin koodi, jonka ehdokas kirjoitti taululle, oli täyttä hölynpölyä. Hänellä oli hyvin epämääräinen käsitys JavaScriptin lupauksista, eikä hän pystynyt oikein selittämään, miksi niitä tarvitaan. Juniorille tämä olisi ollut anteeksiannettavaa, mutta hän ei enää sopinut seniorin tehtävään. Kuinka tämä kehittäjä pystyisi korjaamaan vikoja monimutkaisessa lupausketjussa ja selittämään muille, mitä hän tarkalleen teki?
Kehittäjät pitävät valmista koodia itsestäänselvyytenä
Kehitysprosessin aikana kohtaamme jatkuvasti toistettavia materiaaleja. Siirrämme koodinpätkät, jotta meidän ei tarvitse kirjoittaa niitä joka kerta uudelleen. Vastaavasti keskittämällä kaiken huomiomme tärkeimpiin osiin, katsomme valmiin koodin, jonka kanssa työskentelemme, itsestäänselvyytenä - oletamme yksinkertaisesti, että kaikki toimii niin kuin pitää.
Ja yleensä se toimii, mutta kun asiat muuttuvat hankalaksi, mekaniikan ymmärtäminen kannattaa.
Siten vanhemman kehittäjän tehtäväehdokkaamme piti lupauskohteita itsestäänselvyytenä. Hänellä oli luultavasti käsitys siitä, kuinka käsitellä niitä, kun ne esiintyvät jossain jonkun muun koodissa, mutta hän ei ymmärtänyt yleisperiaatetta eikä voinut toistaa sitä itse haastattelun aikana. Ehkä hän muisti katkelman ulkoa - se ei ole niin vaikeaa:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Minäkin tein sen – ja luultavasti olemme kaikki tehneet sen jossain vaiheessa. He vain opettelivat ulkoa koodinpätkän, jotta he voisivat käyttää sitä myöhemmin työssään, vaikka heillä oli vain yleinen käsitys siitä, kuinka kaikki siellä toimi. Mutta jos kehittäjä todella ymmärtäisi konseptin, hänen ei tarvitsisi muistaa mitään - hän vain osaisi tehdä sen ja toistaa helposti kaiken tarvitsemansa koodina.
Palaa juurille
Vuonna 2012, kun etupään kehyksiä ei ollut vielä vakiinnutettu, jQuery hallitsi maailmaa, ja luin kirjan. , kirjoittaja John Resig, jQueryn luoja.
Kirja opettaa lukijalle oman jQueryn luomisen tyhjästä ja tarjoaa ainutlaatuisen käsityksen ajatusprosessista, joka johti kirjaston luomiseen. Viime vuosina jQuery on menettänyt entisen suosionsa, mutta suosittelen silti kirjaa lämpimästi. Eniten hänessä kosketin minua jatkuva tunne, että olisin voinut ajatella tätä kaikkea itse. Kirjoittajan kuvaamat vaiheet vaikuttivat niin loogisilta, niin selkeiltä, että aloin vakavasti ajatella, että voisin helposti luoda jQueryn, jos vain pääsisin siihen.
Tietenkin todellisuudessa en olisi voinut tehdä mitään tällaista - olisin päättänyt, että se oli sietämättömän vaikeaa. Omat ratkaisuni tuntuisivat liian yksinkertaisilta ja naiiviilta toimimaan, ja antaisin periksi. Luokittelisin jQueryn itsestäänselvyyksiksi, joiden oikeaan toimintaan pitää vain uskoa sokeasti. Tämän jälkeen tuskin tuhlaisin aikaa tämän kirjaston mekaniikkaan syventymiseen, vaan käyttäisin sitä yksinkertaisesti eräänlaisena mustana laatikkona.
Mutta tämän kirjan lukeminen teki minusta toisenlaisen ihmisen. Aloin lukea lähdekoodia ja huomasin, että monien ratkaisujen toteutus oli itse asiassa hyvin läpinäkyvää, jopa ilmeistä. Ei tietenkään, jos ajattelee jotain tällaista yksin, on eri tarina. Mutta se on muiden ihmisten koodin tutkiminen ja olemassa olevien ratkaisujen toistaminen, mikä auttaa meitä keksimään jotain omaa.
Saamasi inspiraatio ja kuviot, joita alat huomata, muuttavat sinua kehittäjänä. Tulet huomaamaan, että se upea kirjasto, jota käytät jatkuvasti ja jota olet tottunut pitämään maagisena esineenä, ei toimi taikuudessa ollenkaan, vaan ratkaisee ongelman lakonisesti ja kekseliäästi.
Joskus joudut kurkistamaan koodin läpi ja analysoimaan sitä askel askeleelta, mutta näin pienin johdonmukaisin askelin voit toistaa kirjoittajan polun ratkaisuun. Näin voit sukeltaa syvemmälle koodausprosessiin ja antaa sinulle enemmän luottamusta omien ratkaisujesi keksimiseen.
Kun aloin työskennellä lupausten kanssa, se tuntui minusta puhtaalta taikalta. Sitten huomasin, että ne perustuivat samoihin takaisinsoittoihin, ja ohjelmointimaailmani kääntyi ylösalaisin. Eli kuvio, jonka tarkoituksena on pelastaa meidät takaisinsoittoilta, on itse toteutettu takaisinsoittojen avulla?!
Tämä auttoi minua tarkastelemaan asiaa eri silmin ja ymmärtämään, että tämä ei ole mikään käsittämätön koodinpätkä edessäni, jonka kohtuutonta monimutkaisuutta en koskaan elämässäni ymmärrä. Nämä ovat vain malleja, jotka voidaan ymmärtää ilman ongelmia asianmukaisella uteliaisuudella ja syvällä uppoutumisella. Näin ihmiset oppivat koodaamaan ja kasvamaan kehittäjinä.
Keksi tämä pyörä uudelleen
Joten mene eteenpäin ja keksi pyörät uudelleen: kirjoita oma tiedonsidontakoodisi, luo kotimainen lupaus tai jopa tee oma valtionhallintaratkaisusi.
Ei ole väliä, ettei kukaan koskaan käytä tätä kaikkea - mutta nyt tiedät kuinka tehdä se. Ja jos sinulla on mahdollisuus myöhemmin käyttää tällaista kehitystä omissa projekteissasi, se on yleensä hienoa. Voit kehittää niitä ja oppia jotain muuta.
Tarkoituksena ei ole lähettää koodiasi tuotantoon, vaan oppia jotain uutta. Oman toteutuksen kirjoittaminen olemassa olevaan ratkaisuun on loistava tapa oppia parhailta ohjelmoijoilta ja siten hioa taitojasi.
Lähde: will.com