Free Press

Tervetuloa ohjelmistokehityksen ihmeelliseen maailmaan. Valmistaudu jännittävään ja jännittävään matkaan, joka on täynnä koodia, sääntöjä ja lisää koodia. Ja mainitsinko jo, että sääntöjä on? Jos olet koodaamiseen perehtynyt henkilö, koodausstandardien käsite ei ole sinulle uusi. Saatat olla näiden ohjeiden vahva kannattaja tai vapaustaistelija, jonka mielestä koodi on ilmaisun muoto. Oli miten oli, ei ole pahitteeksi tarkastella joitakin parhaita käytäntöjä, kun on kyse hyvän koodin kirjoittamisesta.
On syytä mainita, että vaikka koodausstandardeja on olemassa – niitä on olemassa monin eri variaatioin, ja usein ne ovat pelkkiä ohjeita, joita ei ole pakko noudattaa. Ellet halua kirjoittaa hyvää koodia, sinun pitäisi luultavasti noudattaa jonkinlaisia standardeja.

Kirjoita kommentteja ja dokumentaatiota

Ensimmäisiä asioita, joita opit kehittäjänä, on ehkä koodin kommentointi. Aluksi se saattaa tuntua ajanhukalta, kun noudatetaan mentaliteettia ’Jos hekin ovat kehittäjiä – he voivat ymmärtää sen’. Vaikka se pitääkin joskus paikkansa, koodin kommentointi ja asianmukainen dokumentointi opastavat muita kehittäjiä toteuttamassasi algoritmissa ja logiikassa. Älä kuitenkaan innostu kommentoimaan jokaista koodiriviä! Ilmeinen koodi tulisi jättää sellaisenaan.

Kirjoita luettavaa mutta tehokasta koodia

Luettavaa koodia on helppo seurata, mutta se käyttää optimaalisesti tilaa ja aikaa. Kun kirjoitat koodia, saatat usein haluta kirjoittaa sen mahdollisimman pienillä riveillä. Ehkä voit kirjoittaa kokonaisen metodin tai funktion yhdellä rivillä, mutta se vain vaikeuttaa sen lukemista ja ymmärtämistä.

Käytä apumetodeja

Koodi kannattaa pitää tiiviinä ja ytimekkäänä. Metodin tulisi toteuttaa vain se, mitä sen on tehtävä. Jos jokin osa toteutuksestasi tekee jotain muuta, laita se erilliseen metodiin ja kutsu sitä metodisi sisällä.

Jos se on vältettävissä, ÄLÄ tee kovakoodausta!

Ainoat asiat, jotka pitäisi koodata kovakoodilla, ovat vakiot. That’s it.

Kirjoita testitapauksia. Älä unohda ääritapauksia:

Siten tiedät, mitä metodisi tekee, mitä se ottaa ja mitä sen pitäisi palauttaa. Tiedät, milloin sen pitäisi toimia tai milloin sen pitäisi epäonnistua. Funktion tulisi aina perustua testitapauksiin; ei funktioiden testeihin.

Kirjoita helppolukuista mutta tehokasta koodia.Noudata nykyisen projektisi koodausstandardeja

”HENKILÖKOHTAISET HENKILÖKOHTAISET KÄYTÄNNÖT VOIVAT VÄHENTÄÄ VIRHEIDEN ESIINTYMISEN MÄÄRÄÄ JOPA 75 PROSENTILLA.”

Jokaiseen projektiin/yritykseen sovelletaan omia koodausstandardeja. Jotkut saattavat pitää yhtä tyyliä parempana kuin toista, kun kyse on esimerkiksi nimeämiskäytännöistä, tiedostorakenteesta ja välilyönneistä.
On olemassa IDE-ohjelmia, joissa voit asettaa haluamasi tyylin, joka korjaa sen automaattisesti, kun tallennat. On helpompi lukea ja siten myös ymmärtää, kun kaikissa projektien tiedostoissa käytetään samaa tyyliä, nimeämiskäytäntöä, välilyöntejä jne.

Käytä IDE:n pudotusvalikkoa

Ei niinkään standardi, mutta hyvä käytäntö, näistä on paljon apua ja ne auttavat sinua tekemään vähemmän koodausvirheitä.

Esimerkiksi:
Jos haluat nimetä muuttujan tai metodin uudelleen, käytä vain IDE:si ”refactor”-valintaa ja se muuttaa kaikki kutsut kyseiseen metodin/muuttujan nimeen. Sinun ei tarvitse muuttaa niitä yksi kerrallaan, mikä tekee koodistasi virhealtista/epäonnistuvaa.
Jos haluat luoda getter/setter-metodit kaikille yksityisille muuttujillesi, käytä vain ”create getter/setter” ja IDE luo metodit automaattisesti puolestasi.

API:t ovat käteviä

”CURRENT SOFTWARE PROJECTS SPEND ABOUT 40 TO 50 PERCENT OF THEIR EFFORT ON AVOIDABLE REWORK”

Ennen kuin toteutat metodin, varmista, että ne eivät ole käytettävissäsi. Sinun ei tarvitse koodata, jos voit vain tuoda toiminnallisuuden. Se tekee kehittäjän elämästä superhelppoa.
Kuuluisa sanonta on ”Älä keksi pyörää uudelleen” ja se pitää paikkansa monissa tapauksissa. Kannattaa kuitenkin aina harkita kirjaston tuonnin vaikutuksia, varsinkin jos se on kolmannen osapuolen kirjasto. Mahdollisten lisenssikysymysten lisäksi saatat vain paisuttaa koodipohjaasi. Jos tarvitset vain metodin, joka muuntaa lämpötiloja, sinun ei tarvitse tuoda kirjastoa, joka tekee sen ja sata muuta asiaa.

Pariohjelmointi/koodin tarkastelu

”PEER REVIEWS CATCH 60 PERCENT OF THE DEFECTS”

Näistä on paljon apua, kun on kyse koodin refaktoroinnista. Muut saattavat nähdä paremman toteutuksen koodisi optimoimiseksi tai vain tehdä koodistasi tyylikkäämmän. Se varmistaa myös, että kehittäjät noudattavat standardeja ja työ on tuplatarkastettu. Kaiken tämän lisäksi se on loistava tapa kehittäjille oppia toisiltaan.

TUE VARMUUSKOPIOINTI JA TALLENNA TYÖTÄSI PALJON

Olen sanonut jo tarpeeksi. Kuollut akku, sähkökatkos, ohjelmistohäiriö, tulipalo, ydinkatastrofi – kaikki nämä voivat johtaa tietojen menetykseen. Varmista, että tallennat usein ja varmuuskopioit koodisi jonkinlaiseen versionhallintajärjestelmään, on yksinkertainen tapa varmistaa, että koodisi pysyy turvassa.

Koodausstandardit ja parhaat käytännöt on valtava aihe – sellainen, jota voisi jatkaa monta sivua. Itse asiassa, jos haluat joskus lukea Java-koodausstandardeista, Oracle tarjoaa juuri sitä. Näiden standardien ja käytäntöjen soveltaminen vaihtelee myös sovelluskohteittain – työskenteletpä sitten valtavan yritysprojektin parissa tai autat pikkuveljeäsi kotitehtävissä. Monien tekijöiden perusteella on viime kädessä sinusta itsestäsi kiinni, että kehittämäsi koodi on hyvää koodia.

Disclaimer: Kaikki tässä blogikirjoituksessa esitetyt näkemykset tai mielipiteet ovat yksinomaan kirjoittajan omia eivätkä välttämättä edusta Aversan Inc:n näkemyksiä tai mielipiteitä.