Uuden oppimisen strategiat
Ongelmanratkaisukyky on tunnetusti tärkeä ohjelmistokehittäjän ominaisuus. Vähintään yhtä tärkeitä ovat tiedonhankintataidot ja edellytykset omaksua uusia asioita. Vieraita käsitteitä, teknologioita ja työkaluja tulee vastaan tuon tuosta. Aina ei ole mahdollista pysähtyä ottamaan asioista selvää perin pohjin, vaan joskus ongelmat pitää vain ratkaista. Ratkaisun laadun ja oman mielenrauhan takia on kuitenkin suotavaa, että olisi edes joku käsitys siitä, millaisen ongelman kanssa on tekemisissä. Jos ajalliset resurssit ovat niukat, on hyvä olla toimintasuunnitelma, jonka avulla ottaa haltuun tarvittava tietopaketti. Tässä tekstissä kerron, millaiset keinot olen itse kokenut hyödyllisiksi.
Yleiskuva, määritelmä, ratkaisu
Tein erääseen React-projektiin riippuvuuspäivityksiä. Homma eteni ongelmitta, kunnes vuoroon tuli react-scripts-kirjaston päivitys versiosta 4 versioon 5. Versiossa 4 oli korkean ja kriittisen tason haavoittuvuuksia, ja vaikka kyseessä ei olekaan niin kutsuttu tuotantoriippuvuus, ylläpitäjä ei halua tuntea oloaan turvattomaksi omassa koodissaan. React-scripts on Create React Appin mukana tuleva kirjasto, joka sisältää muun muassa kehitysympäristön ajamiseen ja koodin buildaamiseen tarvittavat skriptit. Kun sitten version noston jälkeen yritin käynnistää kehitysympäristöä, terminaaliin ilmestyi liuta seuraavanlaisia virheitä:
ERROR in ./node_modules/logform/dist/splat.js 63:11–26Module not found: Error: Can’t resolve ‘util’ in ’/…node_modules/logform/dist’BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.This is no longer the case. Verify if you need this module and configure a polyfill for it.If you want to include a polyfill, you need to:- add a fallback ‘resolve.fallback: { “util”: require.resolve(“util/”) }’- install ‘util’If you don’t want to include a polyfill, you can use an empty module like this:resolve.fallback: { “util”: false }
Virheviesti sinänsä on poikkeuksellisen selvä. Se kertoo, mikä on rikki, mistä ongelma johtuu ja mitä pitää tehdä. Module not found -virheet ovat monelle tuttuja. Niitä esiintyy, jos jotakin npm-pakettia ei löydy node_modules-kansiosta. Tällainen tilanne syntyy, jos ei vaikkapa muista päivittää lokaalia ympäristöä uusimpien muutosten jälkeen. BREAKING CHANGE -kohta virheviestissä kertoo, miksi kyseinen moduuli ei yhtäkkiä ole enää käytettävissämme: Webpackin aiemmat versiot sisälsivät moduulille polyfillin, kun taas Webpackin versiossa 5 — jota react-scriptsin uusin versio käyttää — polyfilliä ei enää ole tarjolla. Ratkaisuna voidaan sitten joko manuaalisesti lisätä kyseinen polyfill Webpackin konfiguraatioihin tai eksplisiittisesti ilmoittaa olla käyttämättä sitä.
Virheviestin tiedoilla ja parilla google-haulla saisin skriptin toimimaan, mutta jotta ymmärtäisin, mitä olen tekemässä, minun tulisi tietää, mitä ovat polyfillit. Tällaisen yksittäisen, suhteellisen pienen ongelman kohdalla, jolloin perehtymiseen voi käyttää aikaa tunnin tai kaksi, noudatan seuraavaa strategiaa: 1) yleiskuvan hankkiminen, 2) määritelmän muodostaminen ja 3) ongelman ratkaisu.
Ensimmäinen vaihe käsittää vapaata lueskelua ja harhailua internetissä, mikä voi kuulostaa tehottomalta mutta on kuitenkin tärkeää, sillä sen kautta luodaan tausta, johon yksityiskohtia on myöhemmin helppo sijoittaa. Eri lähteissä toistuvista käsitteistä saa kiinni aihepiirin keskeisistä avainsanoista ja ylipäätään ymmärryksen siitä, millaisen asian kanssa on tekemisissä. Etsiessäni tietoa polyfilleista sain ensinnäkin tietää, että ne ovat (useimmiten) JavaScriptillä kirjoitettua koodia, jonka käyttötarkoitus liittyy selainten toimintaan ja eroihin. Kaikilla selaimilla on omat JavaScript-moottorinsa, joiden kyvyt ja tavat lukea JavaScriptiä vaihtelevat. Jos jokin selain ei esimerkiksi tue jotain uutta JavaScriptin ominaisuutta, on olemassa koodi, jossa ominaisuutta imitoidaan tavalla, jonka selain ymmärtää. Tämä koodi on nimeltään polyfill. Polyfilleja varten on olemassa kirjastoja. Yksi tavallisimmista on core-js, joka sisältää polyfilleja keskeisille EcmaScriptin ominaisuuksille kuten Promiseille. Polyfilleja voi toki kirjoittaa myös itse.
Seuraava vaihe on oman määritelmän laatiminen. Tällöin on hyvä lukea tarkemmin lähteet, jotka ensimmäisessä vaiheessa vaikuttivat olennaisilta ja luotettavilta. Määritelmän kirjoittaminen on testi, onko ymmärtänyt lukemansa. Suorat lainaukset ja jargonin käyttö ovat helppoja ratkaisuja, jotka menisivät läpi tentissä tai — ikävä kyllä — tieteellisessä tekstissä, mutta tässä tapauksessa viestivät usein vain siitä, ettei luettu ole käynyt läpi minkäänlaista prosessointia mielessä. Määritelmän ei tarvitse olla kaiken kattava tai tietosanakirjakelpoinen. Ainoa testi, jonka sen pitää läpäistä, on se, että ymmärtääkö sen itse. Polyfillin määrittelisin seuraavasti:
Jos selain ei tue jotain JavaScriptin ominaisuutta, tarvitaan koodi, jossa ominaisuus tai sitä muistuttava toiminnallisuus on kirjoitettu selaimen ymmärtämällä tavalla. Tuota korvaavaa koodia kutsutaan polyfilliksi.
Entä miten tämä tieto muuttaa ymmärrystäni alkuperäisestä ongelmasta? Webpackin uusin versio ei enää sisällä polyfilleja Node.js:n keskeisiin moduuleihin, joiden olemassa oloon eräät projektin kirjastoista taas nojaavat. Voidaan tietysti kysyä, mitä nämä kirjastot tekevät projektissa. Kyseessähän on Reactilla tehty käyttöliittymäsovellus eikä backend-puolen Nodejs-sovellus, jolloin ongelmaa ei alunperinkään tulisi vastaan. Mahdollisia ratkaisuja on siis kahden sijaan kolme: sisällyttää polyfillit projektiin, olla käyttämättä polyfilleja tai vaihtaa kirjastot, joissa ongelma esiintyy. Keskimmäinen vaihtoehto on sekin varteenotettava: jos katsoo MDN Web Docs -sivustolta selaimen yhteensopivuustietoja, punaisia rakseja esiintyy pääasiassa Internet Explorerin kohdalla. IE on taas ainakin kehittäjien keskuudessa pitkälti unohdettu toivottomana tapauksena. Kaikki eivät kuitenkaan tätä tiedä, ja koska kyseisen projektin käyttäjäkuntaan voi potentiaalisesti kuulua ketä vain ja koska kirjastojen vaihtaminenkaan ei tullut kyseeseen, päädyin lopulta turvalliseen ratkaisuun eli lisäämään puuttuvat polyfillit projektiin.
Muita oppimisen muotoja
Joskus projektia varten pitää opetella kokonaan uusi ohjelmointikieli tai muu teknologia. Tällöin strategiani on vähän toisenlainen kuin edellä kuvattu, joskin vaiheet muistuttavat toisiaan. Vaiheet ovat seuraavat: 1) yleiskuvan hankkiminen, 2) teoria ja 3) käytäntö. Yleiskuvan muodostan tässäkin selaamalla eri lähteitä, mutta aikaa on käytettävissä enemmän. Artikkeleiden lisäksi etsin aiheeseen liittyviä podcast-jaksoja tai katson Youtube-videoita. Teoriaosuudessa käännyn virallisen dokumentaation sekä Udemy-kurssien puoleen. Jos teknologia on aivan uusi, videokurssit toimivat ainakin itselleni hyvänä keinona lähteä liikkeelle. Usein jo kurssin alussa saa tarvittavat tiedot, joiden turvin lähteä kokeilemaan siipiään käytännössä, jolloin todellinen oppiminen tapahtuu. Siitä eteenpäin vaiheet 2 ja 3 ovat limittäiset ja toisiaan tukevat.
Aina ei voi tietää, mitä pitäisi tai voisi tietää. Silloin tällöin on hyvä luopua strategioista ja päämääristä ja antaa yllätyksille tilaisuus. Seuraan itse eräitä podcasteja ja jokainen uusi jakso tuo uuden oppimisen mahdollisuuden. Toisinaan vain valitsen podcast-sovelluksesta kiinnostavan kuuloisen ohjelman tai jakson. Lehtien ja blogien lueskelu sekä asiasta toiseen johtava googlettelu kuuluvat ilman muuta kategoriaan. Oiva tiedon lähde ovat tietenkin myös omat kollegat. Ei tarvitse kuin avata Slack ja navigoida Programming-kanavalle, jonne työkaverit tasaiseen tahtiin päivittävät omia viimeaikaisia löydöksiään.
Haluatko liittyä joukkoomme? Etsimme uusia koodaajia, joille lisää oppiminen on intohimo.
