zef_logo.png
Ë
Jarkko Tervonen Jarkko Tervonen • helmikuuta 2, 2015

ZEF Tech: 3 askelta kohti parempaa koodia


Innovaton& Growth

ZEF Warrioreilta löytyy mystisiä superkykyjä myynnistä koodaukseen ja markkinoinnista päälläseisontaan. Esittelemme blogissa parhaita käytäntöjämme ja jaamme vinkkejä, joista voit hakea inspiraatiota ja fiilistä omaan työhösi. Nappaa vinkit kaikin mokomin talteen ja kerro kommenttikentässä, mistä haluaisit kuulla lisää! Tässä tekstissä Tekninen johtajamme valottaa koodauksen saloja ja esittelee kolme askelta kohti laadukkaampaa koodia.

On enemmän sääntö kuin poikkeus, että ajanmittaan web-applikaatiota kehitettäessä koodin laatu laskee. Tämä johtaa lisääntyneisiin virheisiin ja kehitykseen kuluvan ajan lisääntymisenä. Web-aplikaatioiden kehittämisessä tämä korostuu, koska menetelmät ja käytettävät kirjastot kehittyvät huimaa vauhtia. Ohjelman uusiksi kirjoittaminen olisi monesti paras ratkaisu laadun parantamiseen, mutta tähän ei välttämättä ole irroitettavissa resursseja.

Matkan kohti laadukkaampaa koodia voi aloittaa tarkistamalla, että seuraavat asiat ovat kunnossa:

1. Versiohallinta

Ensimmäinen ja lähes tärkein asia on versiohallinta. Tämä on tärkeää vaikka kehittäisit ohjelmaa yksin. Versionhallinan käyttäminen ja commit-viestien sisältöön panostaminen luo automaattisesti muutoslokia. Tämä nopeuttaa valtavasti, kun bugien syitä etsitään myöhemmin. Meillä ZEFissä on ollut alusta asti käytössä versiohallinta. Ensin käytimme Subversion-versiohallintaa mutta nykyisin koodia hallitsee NPM ja Composer vastaavasti PHP-kirjastoille.

2. Coding Style Guidelines

Toinen tärkeä asia on noudattaa koodauksessa tiettyä standardia kaikissa koodeissa. Jos koodi on samalla tavalla kirjoitettua niin säännöt kannattaa määritellä käytetyn tyylin mukaan. Muutoin kannattaa valita paras olemassa olevista standardeista (esimerkiksi PHP:llä PSR-1 tai PSR-2). Olemassa olevien standardien käyttöä puoltaa kaksi asia: Ne on valmiiksi määriteltyjä ja niiden tarkistamiseen ja noudattamiseen löytyy valmiita apuohjelmia. Oman tyylin määrittelemiseen menee aikaa, jonka voisi käyttää hyödyllisemmin. Esimerkiksi itse koodin siivoamiseen.

Suureen osaan editoreista saa liitettyä apuohjelmia, jotka validoi annetun kooodin sitä kirjoittaessa. Esimerkiksi Atom-editorin Linter-paketista löytyy lähes jokaiselle kielelle apua koodin validointiin ja koodausstandardien noudattamiseen.

3. Kehitysympäristö

Kehitysympäristön tulisi vastata mahdollisimman paljon tuotantoa ja olla jokaisella kehittäjällä samanlainen vaikka työkalut olisi valittavissa omien mieltymysten mukaan. Aiemmin oli tapana pyörittää omalla koneella www-palvelinta ja kehittää ns. localhostissa. Tämän tavan myötä saattoi helposti käydä niin, ettei kirjoitettu koodi toiminutkaan odotetusti toisen kehittäjän kehitysympäristössä tai tuotantopalvelimilla. Nykyisin ei ole mitään syytä olla käyttämättä Vagrantin tapaisia kehitysympäristöjä, joilla jokaiselle kehittäjälle saadaan samanlainen tuotantoa vastaava kehitysympäristö pienellä vaivalla.

Jaa vinkki:




Ota yhteyttä

Palvelemme kaikissa kyselyihin liittyvissä asiakastarpeissa. Jätä yhteystietosi, niin otamme sinuun välittömästi yhteyttä.