Suorituskyky mitataan, kehittäjäkokemus koetaan
Full-stack projektissa työkalu- ja arkkitehtuurivalinnat vaikuttavat sekä kehittäjän arkeen että sovelluksen nopeuteen. Suorituskykyä voi mitata luvuilla, mutta kehittäjäkokemuksen hyödyt näkyvät usein vasta työn sujuvuudessa.
Javascript-pohjaisen full-stack kehityksen etu on se, että sama ohjelmointikieli kattaa koko sovelluksen. Projektin kasvaessa kuitenkin myös haasteet lisääntyvät. Tyypit on pidettävä yhtenäisinä frontendin ja backendin välillä, tietokannasta on löydettävä oikeat tietueet kasvavasta aineistosta eikä selaimen ladattavaksi saisi jäädä enempää koodia kuin sivun avaaminen vaatisi.
Opinnäytetyössäni Kehittäjäkokemuksen ja suorituskyvyn parantaminen MERN-pohjaisessa websovelluskehityksessä tavoitteena oli selvittää, miten kehittäjäkokemusta ja suorituskykyä voidaan parantaa työkalu- sekä arkkitehtuurivalinnoilla MERN-pohjaisessa projektissa.
Kehittäjäkokemusta tarkasteltiin SPACE- ja DevEx-viitekehysten avulla, keskittyen erityisesti palautesykleihin ja kognitiiviseen kuormaan. TypeScript kattoi koko sovelluspinon, jaettu tyyppihakemisto piti tyypit synkronoituina ja Zod vastasi ajonaikaisesta validoinnista.
Kehittäjäkokemus koetaan
Mitä kehittäjäkokemus sitten on? Yksinkertaisesti se, miten kehittäjä itse kokee työkalunsa ja päivittäisen työnkulkunsa. DevEx-viitekehys jakaa sen kolmeen ulottuvuuteen, palautesyklit, kognitiivinen kuorma sekä flow-tila (Noda ym., 2023). Palautesyklit kuvaavat sitä, kuinka nopeasti ja luotettavasti kehittäjä saa tiedon työnsä tuloksista. Se voi olla editorin välitön reaktio, testiajon tulos tai koodikatselmoinnin kaltainen pidempi kierros. Kognitiivinen kuorma taas kuvaa sitä, kuinka paljon tehtävän ratkaiseminen vaatii muistamista, etsimistä ja työkalusta toiseen siirtymistä. Mitä paremmin kehittäjä tuntee työkalunsa, sitä vähemmän kuormaa niiden käyttö aiheuttaa.
Staattinen tyypitys vaikuttaa molempiin ulottuvuuksiin kerralla. Palautesykli lyhenee, koska virhe ilmenee kirjoitushetkellä eikä vasta ajossa. Kognitiivinen kuorma kevenee, koska tieto siitä mitä missäkin kohdassa odotetaan näkyy suoraan editorissa, jolloin sitä ei tarvitse käydä etsimässä toisaalta. Kun tyypit määritellään yhdessä paikassa koko sovellukselle, muutos näkyy välittömästi kaikkialla missä sillä on merkitystä. Tyypit eivät kuitenkaan tarkista ajon aikana saapuvaa dataa, joten rajapinnalle tarvitaan erillinen validointi.
Tärkein hyöty ei ollut kiinni saatujen virheiden määrä vaan luottamus.
Käytännössä tyyppijärjestelmä ei paljastanut paljon virheitä, vaan esti tietynlaiset virheet kokonaan, jolloin vaikutus näkyi ennen kaikkea työn sujuvuudessa. Tärkein hyöty ei siis ollut kiinni saatujen virheiden määrä, vaan luottamus siihen, että muutos yhdessä kohdassa ei huomaamatta riko sovellusta. Sama koski automaattista tarkistusta ja muotoilua, ne eivät juuri nopeuttaneet työtä, mutta vähensivät keskeytyksiä, jotka vievät ajatuksen pois itse ongelmasta.
Suorituskyky mitataan
Suorituskyvyssä vaikutus on helpompi mitata. Ilman indeksiä tietokanta joutuu käymään läpi jokaisen tietueen löytääkseen etsimänsä, ja työmäärä kasvaa suoraan aineiston koon mukaan. Opinnäytetyössä indeksit suunniteltiin Equality-Sort-Range periaatteen mukaisesti: tarkkaa vastaavuutta hakevat kentät ensin, järjestävät kentät seuraavaksi ja väliehdot viimeiseksi. Ajanseurantasovelluksen seitsemästä kyselystä kuudessa läpikäytyjen tietueiden määrä putosi näin 90–100 prosenttia ja kaksi lukumääräkyselyä vastattiin suoraan indeksistä ilman yhtään tietuetta. Seitsemäs kysely ei hyötynyt lainkaan, koska tunnistekenttä oli jo valmiiksi indeksoitu.
Indekseillä on kuitenkin hintansa. Aina kun tietokantaan lisätään tietoja tai siinä muutetaan indeksoituja kenttiä, myös indeksit on päivitettävä ja lisäksi ne vievät muistia ja levytilaa. Siksi indeksejä kannattaa luoda vain niille kyselyille, joita sovellus todella käyttää.
Käyttöliittymän puolella suurin yksittäinen hyöty tulee koodin jakamisesta osiin – kaikkea koodia ei tarvita heti. Esimerkiksi raporttien lataamiseen käytettävät kirjastot ovat kookkaita, mutta niitä tarvitaan vasta kun käyttäjä lataa raportin tiedostoksi. Kun ne pidetään erillään, selain hakee ne vasta tarvittaessa eivätkä ne hidasta sivun avautumista. Mittaamisessa luotettavin luku saatiin tietokannan omasta raportista, sillä asiakaspään mittauksiin vaikuttavat myös verkon viive ja palvelimen kuorma.
Lopulta kehittäjäkokemus ja suorituskyky näkyvät eri tavoin. Suorituskyvyn parannukset voi osoittaa luvuin ja siksi niihin on helppo panostaa. Kehittäjäkokemuksen hyödyt jäävät usein lukujen ulkopuolelle, vaikka ne vaikuttavat jokaiseen työpäivään. Siksi ne ansaitsevat yhtä paljon huomiota.
Lähteet:
Noda, A., Storey, M.-A., Forsgren, N., & Greiler, M. (2023). DevEx: What actually drives productivity. ACM Queue, 21(2). https://doi.org/10.1145/3595878