WordPress-kehityksen hyväksi todettuja käytäntöjä
Verkkosivustoja voi tehdä valtavan monella eri tavalla. Osa on toimiston ja tiimin valintoja, osaan on päädytty ihan opin ja erehdyksen kautta. Ja jotkut asiat, kuten yhteisesti sovittu koodistandardi, ovat puhtaasti makuasioita.
Tässä blogitekstissä esittelen MEOMilla sivustokehityksessä tällä hetkellä toimivia käytäntöjä, esimerkkinä WordPress-sivuston devaus. Osa tekemisen tavoista on toki julkaisualustasta riippumatonta ja käytössä muodossa tai toisessa monilla muillakin. Sisältö on varmasti silmiä avaavaa uraansa aloittelevalle kehittäjälle, mutta saattaa tarjota ajattelemisen aihetta myös kokeneemmalle frontti-devaajalle.
Palvelinhostauksen ja ylläpidon ulkoistaminen
WordPress-sivustojemme hostaus on ulkoistettu WP-palveluun. Näin meillä ei mene kehitysresursseja niiden ylläpitoon tai konfigurointiin, vaan voimme käyttää ne meille mielekkäämpiin asioihin. Tämä vapauttaa myös 24/7-päivystyksestä. Jos sivusto kaatuu, välittömät toimenpiteet palvelun palauttamiseksi hoitaa WP-palvelu.
Tämä toki rajoittaa palvelimista kiinnostuneiden kehittäjien mahdollisuuksia työn parissa, mutta meille ratkaisu on ollut toistaiseksi toimiva. On toimistoja, jotka ylläpitävät itse palvelimiaan ja tämä tuo toki lisää kehitysmahdollisuuksia, mutta samalla myös riskejä, että joku menee pieleen. Avaimien omissa käsissä pitäminen vaatii erikoistumista.
Lokaali kehitysympäristö
Meillä on käytössä WP-palvelun projektipohja, jolla pystymme Vagrantin/Dockerin avustuksella pyörittämään sivustoa lokaalisti. Näin muutoksia ei tarvitse puskea vanhan liiton tyyliin reaaliaikaisesti livesaitille tai testipalvelimelle, vaan ne voidaan testata rauhassa identtisellä sivustoversiolla. Näin vältymme turhien testisivujen luonnilta tai tiedostojen siirtelyltä.
Toki virtuaalikoneillakaan koodin testaaminen ei ole ongelmatonta. Meillä Vagrant/Docker on WP-palvelun ylläpitämä ja tämä tuo perinteiset yhteistyön mukanaan tuomat probleemat, mutta toisaalta taas omasta takaa virtuaaliboksien ylläpito vaatisi jälleen kehitysresursseja, jotka ovat aina kortilla.
Tähän ollaan ympätty lisäksi MEOMin oma räätälöity teema, johon kaikki toteuttamamme sivustot pohjaavat.
Pluginien hallinta Composerilla
Composer tarjoaa meille kehittäjille tiedoston, joiden kautta voimme hallita lähes kaikkia WordPress-sivustolla käytössä olevia plugareita, ja se kulkee projektin versionhallinnassa mukana. Plugineihin liittyviä tiedostoja ei siis tarvitse kuljettaa versionhallinnassa mukana.
Näin meille jää tieto siitä, mitä lisäosia olemme itse hyväksyneet ja asentaneet. Koska WordPress on avoimen lähdekoodin julkaisualusta, myös lisäosia voi tehdä käytännössä kuka vain. Kun olemme hyväksyneet lisäosan, voimme asiakkaan kanssa olla luottavaisia sen toiminnasta.
Palvelimista vastaava WP-palvelu huolehtii myös plugarien automaattisista päivityksistä. Jos uusia versioita on saatavilla, ne päivitetään erillisessä testiympäristössä ja jos testit menevät läpi, plugin päivitetään varsinaiselle sivustolle. Näin vältämme hyvällä prosentilla sen, että toisinaan bugittavat lisäosapäivitykset rikkoisivat asiakkaiden sivustoja.
On asiakaskohtaista mitä lisäosia sivustolla käytetään, esim tietyn ominaisuuden toteuttamiseen. Meillä on käytössä tiettyjä vakio-plugineja, kuten Yoast SEO, Advanced Custom Fields ja Gravity Forms, mutta kaikkiaan niitä käytetään harkiten. Kaikkia vastaan tulleita uusia villityksiä ei tutkimatta käyttöön oteta.
Versionhallinta ja koodikatselmointi
Versionhallinnassa meillä luonnollisesti käytössä Git. Tyypillisesti projektissa on useampi kuin yksi tekijä, ja silloin tekijät katselmoivat toistensa koodit kevyesti. Yksinään projektissa työskennellessä katselmointia saa aina pyytää muilta, jos on epävarma toteutuksesta. Uusien työntekijöiden koodeja katselmoidaan tiiviimmin, jotta työt lähtevät rullaamaan oikealla tavalla.
Suurin hyöty tässä on oppiminen. On hyvä saada systemaattiset virheet bongattua ja oppia tekemään paremmalla tavalla. Myös katselmoijan on hyvä nähdä erilaisia tapoja tehdä. Vastaan on tullut ihan uusiakin oivalluksia, joiden olemassaolosta ei edes tiennyt.
Samalla koodikatselmointi on myös laadunvarmistusta. Esimerkiksi juniorin toteuttama ominaisuus testataan toisella koneella ja katsotaan tuottaako se halutun lopputuloksen.
Koodistandardi herättää tunteita
JavaScriptin osalta meillä ei ole varsinaista koodistandardia käytössä, eli emme takerru siihen, että kuinka monta välilyöntiä on tai tuliko kommentin perään piste. Jos koodi ei läpäise validaattoria, on ohje tarkistaa koodi autoformatoinnilla.
Koodistandardi on niitä asioita, jotka herättävät kehittäjissä intohimoja myös irrationaalisella tasolla. Joillekin yhtäkuin-merkkien on vain oltava samassa linjassa, tai mistään ei tule mitään.
PHP:n suhteen olemme päätyneet yhtenäisiin käytäntöihin, koska siinä syntaxiin liittyvää päänsärkyä tuntui esiintyvän eniten. Olemme valinneet standardin, joihin on tehty pieniä omia muutoksia. Tavoite on, että kaikki käyttävät tätä standardia ja koodieditorimmekin ilmoittaa, jos esimerkiksi välilyönti puuttuu.
Nimeämiskäytännöstä
Tyylit tehdään SCSS:llä. CSS-muutoksissa työtä helpottaa Browsersync, jonka avulla tyylit tulevat suoraan selaimeen näkymiin, ilman että sivua tarvitsee päivittää erikseen.
Pohjateemassa on valmiina erilaisia mixinejä ja muuttujia, joilla luodaan esimerkiksi yhteneväiset responsiiviset typografiat ja marginaalit. Sillä ei ole niinkään väliä, että onko jollekin muuttujalle annettu nimeksi “post-item” vai “card”, mutta mitä tulee selektoreiden tyyppiin, pyrimme noudattamaan BEM-tyylistä ajattelua.
Tällä tavoittelemme koodin luettavuutta. Toisin sanoen sillä on enemmän merkitystä, että millä merkkauksella erittelemme eri kategorian selektorit ja muuttujat toisistaan. Kyse on erikoismerkkien johdonmukaisesta käytöstä.
JavaScript-kirjastot
Kehityksessä ovat tarvittaessa apuna erilaiset JS-kirjastot ja jQuery. Esimerkiksi slider-lohkon toteutuksessa on parikin erilaista kirjastoa, jota hyödynnetään, ettei tarvitse joka kerta etsiä tarpeeseen sopivaa lähtöruudusta liikahtaen.
Uutena tiimiin tulevat kyselevät usein etukäteen ennen tietyn ominaisuuden toteuttamista, että mikäköhän kirjasto tähän olisi hyvä.
Käännösautomaatiossa siirrymme webpackiin
Tällä hetkellä käytämme CSS:n ja JavaScriptin buildaamiseen Gulpia, mutta se on vaihtumassa webpackiin. webpack on jo meillä käytössä natiivi-Gutenberg-koodin pyöräyttämisessä, mutta teemaan olemme käyttäneet vielä Gulpia.
Nyt haluamme siirtyä yhteen työkaluun ja valitsimme webpackin, joka on modernimpi. Näin käännöksen voi ajaa yhdellä komennolla.
Bitbucket ominaisuuksien kehittämisen apuna
Projektipohjan ominaisuuksia testataan ja kehitetään paljon projektityön ohessa. Muutostarpeita pidetään yllä Bitbucketin issueissa. Jos jokin asia ärsyttää tai kokee että sen voi tehdä paremmin, Bitbucket on sille hyvä paikka.
Kehitystarpeita voi nousta esille myös koodikatselmoinnissa, mutta kehitystyö on tästä itsenäistä. Kehityksen listaa käydään aktiivisesti läpi ja kun aikaa on, korjauksia tehdään ja keskusteluita käydään.
Lähestymistapamme on demokraattinen, eli kaikilla on mahdollisuus sanoa mielipiteensä ja vaikuttaa päätökseen, eli muutoksista päättäminen ei ole yksinvaltaisesti esimerkiksi Lead Developerin oikeus. Joskus asioita pitää vähän sulatella, mutta yleensä pääsemme lopputulokseen aikuismaisesti. Toki jotkin asiat ovat makuasioita, ja jos päätös on pakko löytää, pitää löytää kompromissi.
Viimeisimpiä Bitbucketin kautta käytäntöön päätyneitä asioita on esimerkiksi Mixin-fonttikoot: haemme yhdellä komennolla tietyn tyylin nimellä, vaikka small. Vaikka tämä fonttityyli esiintyisi kymmenissä eri kohdissa sivustolla, on se tämän myötä aina samanlainen.
Design-tech-handover Figma-templaten avulla
Meillä on menneisyydessä ollut käytössä verkkosivuston designin suunnittelussa ja esittelyssä erilaisia ohjelmistoja, kuten Sketch ja Marvelapp. Nyt olemme yhdenmukaistaneet käytäntöjä suunnittelemalla sivuleiskat Figmassa vakiomuotoisella sapluunalla eli templatella.
Figma mahdollistaa samanlaisten tyylimuuttujien luomisen kuin koodissa jo design-vaiheessa. Kun nämä ovat yhdenmukaisia, saa kehittäjä Figma-tiedostosta suoraan kaikki tarvittavat muuttujat, eli esimerkiksi tietty fonttityyppi on small sekä Figmassa että WordPressissä, sen sijaan että joudut pohtimaan tyyliin: ”jos fontti on nyt 13 px niin mitenköhän se nyt sivulla sitten olisi…” Toimintatapa johdonmukaistaa myös designia.
Kehityksen pääpainona näyttävät markkinointisivustot
Vaikka meillä palvelinten ylläpito on ulkoistettu, aina aikaansa voisi käyttää NGINX-konfiguraatioihin ja muuhun backend-painotteiseen kikkailuun. Tiiminä keskitymme kuitenkin ensisijaisesti näyttävään frontendiin.
Tämä tarkoittaa sitä, että toteutuksissamme on harvemmin omia kirjautumisjärjestelmiä, raskaita integraatiota tai verkkokauppoja. Näin meillä ei synny ylläpidon pullonkauloja, jossa yhden backend-intensiivisen viritelmän tuntemus on yhden henkilön takana.
Lue lisää WordPressista
