Kultainen koodi

.NET-osaajan ajatuksia paremmasta koodailusta

Archive for the category “koodin laatu”

Code Wars, mahdollisuus oppia

Tutustuin codewarsiin työkaverini suosituksesta yhtenä syksyisenä päivänä. Hän löysi koodiharjoitussivuston, jossa editoria ja testejä voi ajaa selaimen kautta. Toisin kuin exersim.io tai vastaavissa palveluissa, codewarsilla harjoitteleminen onnistuu ilman kehitysympäristöä.

Harjoitusten tekeminen codewarsissa käy helposti. Harjoitusta kutsutaan nimellä kata.

codewars_kata

Kata eli harjoitus codewars.com:ssa.

 

Harjoituksen tehtävänanto selviää ruudun vasemmalta puolelta. Koodi kirjoitetaan oikeassa yläkulmassa näkyvään koodinäkymään. Kirjoitettu koodi ajetaan ”paikallisia” testejä vastaan Run Examples -painikkeella. Ne löytyvät Example Tests -otsikon alta. Näitä testejä voi myös muokata omien mieltymysten mukaan.

Lopullinen testi ratkaisulle tehdään ajamalla koodi Attempt-painikkeella. Ratkaisun toimivuus testataan yksikkötesteillä, joita ei näytetä käyttäjälle. Vain testien tulos näytetään. Toisinaan testien nimestä voi päätellä mikä testi epäonnistui. Järjestelmä sallii myös satunnaistettujen testien ajamisen, jolloin tehtävän luojan ei tarvitse kirjoittaa kaikkia testitapauksia käsin.

Ratkaistuasi tehtävän, saat vaikeusasteen mukaan tietyn määrän pisteitä. Helpoimmat testit saa ratkaistua muutamassa minuutissa, vaikeampien ratkaiseminen kestää tunteja.

Ratkaistuasi tehtävän, näet muiden vastaukset ja näistä oppii. Vastauksista voi merkata omasta mielestä parhaan ja nokkelan vastauksen. Vastauksista näkee kuinka paljon ohjelmoijien ongelmanratkaisukyky ja API-tuntemus vaihtelee.

codewars_stats

Stats-sivu kertoo mistä olet saanut pisteitä.

 

Olen kerännyt suurimman osan pisteistäni tekemällä harjoituksia. Pisteiden hankkimiseen käytetyt kielet näkyvät oikeasta laidasta ja prosenttiosuus kertoo kuinka paljon pisteitä on kerätty ennen seuraavaa tasoa.

Pisteet päivittyvät muutaman tunnin välein, kun palvelin ajaa ajastetusti pisteiden päivistyskriptit. Itsekin ihmettelin aluksi miksi pisteet päivittyvät viiveellä.

Jos teet vain harjoituksia, pisteillä ei ole merkitystä. Halutessasi voit kirjoittaa harjoituksia muiden ratkaistavaksi tai kääntää niitä kieleltä toiselle. Tällöin korkeampi pistemäärä sallii kevyemmän validointiprosessin ennen kuin kirjoittamasi harjoitus julkaistaan.

Yhteisöllisyyttä yritetään lisätä klaanien avulla. Käyttäjän tiedoissa voi antaa itselleen klaanin. Se on vain merkkijono. Kaikki jotka kirjoittavat saman merkkijonon, tulevat samaan klaaniin.

codewars_klaanit

Klaanit

 

Klaanijärjestelmä ei ehkä ole täydellinen, koska vaihdettuani klaanin, näen edelleen kaikki vanhan klaanini jäsenet.

Codewars on ehdottomasti paras palvelu ohjelmointiharjoitusten tekemiseen. Sen avulla voi ylläpitää kielen osaamista tai opetella uutta kieltä. Toki harjoitusten avulla oppii erityisesti kielen käyttöä, ei niihin liittyvien frameworkkien käyttöä.

Suosittelen kokeilemaan codewarsia, sen avulla voit löytää palon vanhaan rakkaaseen kieleen tai kehittää osaamistasi nykyisen kielen kanssa.

 

 

 

Mainokset

Visual Studio Live Unit Testing

Visual Studio 2017 RC julkisti seuraavan askeleen yksikkötestauksessa, live-tilan. Käytännössä VS ajaa jatkuvasti yksikkötestejä kirjoitettua koodia vastaan ja merkkaa onko koodiriviin osuva testi läpäisty, ei mene läpi tai puuttuuko se.

Silmäilin asiasta kertovan blogin läpi ja katsoin siihen liittyvän videon. Oli mielenkiintoista seurata intialaista kerrontaa. Se selvensi kuinka nopeasti testi heijastui koodiin. Pohdiskelin hetken, vaatiiko tekniikka paljon tehoa tietokoneelta?

Ominaisuus vaatii Enterprise-lisenssin, mikä on sääli. Se maksaa huiman summan, verrattuna tavallisesti käyttämääni pro-versioon.

Mieleeni juolahti vanha kuvio. Microsoft kopioi JetBrainsin ideoita. Tapahtuiko tämä kehitysaskel samoin?

Kyllä!

JetBrainsin dotCover tarjosi continuous testing -konseptin vuonna 2015. Se poikkeaa hieman VS:n natiivista. Se vain ajaa testejä jatkuvasti ja näyttää, menevätkö ne läpi. Tosin dotCoverin muut ominaisuudet näyttävät onko koodille yksikkötestejä.

Vanhaa kauraa siis. Kehittäjälle siis löytyy vaihtoehtoja reaaliaikaiseen testaukseen.

Pari vuotta sitten testasin dotCoveria ja tuolloin kaikilla mausteilla valittuna se hieman hidasti Visual Studiota. Olisi jännä testata onko dotCover ydintä optimoitu tuon jälkeen?

Pitää kokeilla!

Koodaajan erilaiset hatut, refaktorointi

Martin Fowler piti hienon puheen ohjelmoijan erilaisista hatuista. Se upposi ajatusmaailmaani saman tien.

Hänen mukaansa koodia tehtäessä ohjelmoija laittaa päähänsä tietynlaisen hatun käydessään työtehtävään. Tyypilliset hatut ovat

  • koodaus, uusien toimintojen lisäämiseen ja
  • refaktorointi, laadun parantamiseen.

Toki näiden lisäksi löytyy optimoijan hattu, protoilu tai POC-hattu.

iPhone 166Hyvä koodaaja siistii koodinsa aina ominaisuuden luomisen jälkeen, joten miksi refaktoroinnille pitää käyttää omaa hattua? Koska koodi haisee.

Haiseva koodi on (jonkun toisen tekemä) vanha tuotos. Se ei toimi niin tehokkaasti kuin voisi toimia ja se kaipaa pientä tuunausta. Tästä karmeudesta pääsee eroon vain refaktoroimalla. Ohjelmoimista oppiessa huomaa myös oman vanhan koodinsa kaipaavan päivitystä. Koodin hajun lisääntymisen yksi keskeinen syy on sovelluksen kasvaminen ja toimintojen lisääntyminen.

Alkuperäiseen tarkoitukseen käytetty yksinkertainen arkkitehtuuri ei enää toimi, vaan uusien ominaisuuksien lisääminen pakottaa purkkakoodin lisäämiseen, ellei refaktoroi rakennetta uudelleen. Yksinkertaisimmillaan metodikutsu sisältää liian monta parametria ja tarvitaan parametriolio.

Jos koodin hajuun ei kiinnitä huomiota, koodin laatu rapistuu ja koodin rakenne katoaa. Se hukkuu kaikkiin pieniin muutoksiin ja jippoihin. Kompleksisesta koodista seuraa koodaamisen tuska, koska sitä on vaikeampi ymmärtää ja uusien ominaisuuksien liittäminen käy hankalaksi. Aikaa menee hukkaan. Sen sijaan hyvin suunnitellussa ja siistinä pidetyssä koodissa työskentely on vaivatonta ja nopeaa.

Johtoportaalle refaktorointia on turha perustella laadulla, kauniilla koodilla, asinatuntijuudella tai oikealla tavalla tehdä. Perustele rahalla. Sotkuiseen koodiin koodaaminen vie enemmän aikaa kuin pitäisi.

Huomaa, että refaktoroinnin voi joskus jättää tekemättä. Jos haiseva koodi sijaitsee jossain harvoin käytetyssä syrjäisessä osassa, siihen ei tarvitse koskea. Jos haisevaan koodiin törmää päivittäin, se pitää siivota pois. Muutoin joudut tekemään ylimääräistä työtä ja laskutat ylimääräistä asiakkailta. Se on varastamista.

Refaktorointitalkoot ja issuet projektin backlogilla kannattaa unohtaa. Ne putoavat priorisoinnissa aina alaspäin. Sen sijaan korjaa ihan vähän koodia tänään. Paranna laatua taas huomenna, kun törmään heikkolaatuiseen koodiin. Viikkojen ja kuukausien kuluessa koodin laatu paranee. Pian pääset koodaamaan mukavan koodipohjan päälle.

Post Navigation