Kultainen koodi

.NET-osaajan ajatuksia paremmasta koodailusta

Archive for the category “kehitysympäristön virittäminen”

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!

Emacs työvälineenä

Kirjoitin clojurea syksyn emacsilla ja se sujui hyvin. Suurin osa ajastani menee siis koodin rakenteen ja toiminnan pohtimiseen. Saan näppärästi avattua haluamani tiedostot suoraan editoriin ja se tukee kohtuullisesti kirjoittamista.

Emacsin lisäksi pidän melko usein avoinna clojuren cheat sheet -sivua tai clojurescriptin vastaavaa.

Käyttö

Tavallisesti jaan ruudun kahteen tai kolmeen osaan. Yhdellä puolella näkyy koodi ja toisella yksikkötestit. Mikäli teen rajapintaan koodia, niin yhdellä puolella on tietenkin esim. palvelimen rajapinnat näkyvissä ja toisella puolella asiakas/web-sovelluksen puoli, joka kutsuu rajapintoja. Usein testaan koodin toimintaa myös REPL-ikkunassa.

Ikkunoiden ja tiedostojen välillä liikkuminen tapahtuu todella sujuvasti. Näppäinoikopolut purevat erittäin hyvin. Koodia saa siistittyä, leikattua ja liimattua vaivattomasti. Siihen emacs on tehty, kirjoittamiseen. Sen lisäksi yksikkötestit saa pyörimään jatkuvasti tai niitä voi pyöritellä komennoilla. Sekin toimii fantastisesti. Yksikkötestien ajaminen on paljon nopeampaa ja kätevämpää kuin Visual Studiolla, jota olen käyttänyt noin 10 vuotta.

Clojurea kirjoittaessani testaan usein koodia REPL-ikkunassa. Koodin namespacen saa ladattua näppärästi käyttöön ja voin ajaa haluamiani funktioita ”livenä”. Se helpottaa debuggausta, yksikkötestien suunnittelua ja funktion toiminnan testaamista.

Nähdäkseni emacsin valtteja ovat nopeus, koko ruudun tehokas käyttäminen ja laajennettavuus.

IDEn edut

IDE voittaa emacsin helposti koodin laadun tarkkailussa. Sekä Visual Studiosta, Eclipsestä ja InteeliJ:stä löytyy paljon lisäominaisuuksia, jotka helpottavat koodaamista.

Käyttömätön koodi nostetaan esiin paljon helpommin. IDEt yleensä ehdottavat (tai ainakin niihin lisätyt plugarit) kuinka koodia voisi parantaa. Koodausta helpottavat täydennystoiminnot ovat älykkäitä, toisin kuin emacsissa. Emacs tunnistaa aiemmin käytetyt funktiot, muttei osaa ehdottaa kirjastosta löytyviä vaihtoehtoja.

Sekä emacs että IDEt osaavat yhtä hyvin etsiä ja korvata tekstiä. Funktioiden tai metodien uudelleen nimeäminen sen sijaan onnistuu kunnolla vain IDEn kautta. Nimien tai nimiavaruuksien refaktorointi on ehdottomasti IDE-juttu.

Ohjelmakoodin rakenteen näkee IDEn olio tai sovellusrakenteesta, jos rakenne on yksinkertainen. Esimerkiksi MVVM tai simppeli Reactin dispatcher, subscriber -rakenne näkyy paremmin IDEstä kuin emacsista. Tosin kumpikaan ei pelasta jos kyseeseen tulee kompleksinen rakenne, kuten Prism tai laajalle levinnyt legacy-järjestelmä.

Kipeimmin emacsissa minua pistivät puuttuvat uudelleennimeämisominaisuudet, hyvän bookmark-järjestelmän puute ja heikko tuki koodin laadun tarkkailuun. Olisin kaivannut vihjeitä miten asiat koodataan. Projektissani asia korjaantui mob-koodauksessa ja pull request -arvioinneissa.

IDEssä käytettävien useiden näppäinten oikopolkujen sijaan emacsissa kirjoitetaan usea näppäinoikopolku peräkkäin. Esimerkiksi yksikkötestit voi ajaa komennolla (ctrl+c, ctrl+t, ctrl+n) IDEssä suositaan usean näppäimen samanaikaista painamista. IDEssä komennon voi siis käynnistää ”heti”.

Huomasin myös joidenkin emacsin lisäosien käytön vaativan järjettömiä näppäinoikopolkuja eli komennot menivät neljän tai useamman komennon syvyyteen. Se ei tuntunut käytettävältä. Niin pitkiä komentosarjoja ei edes pysty helposti muistamaan.

Lopuksi

Tuntui mukavalta kokeilla emacsia, mutta projektin laajentuessa jäin kaipaamaan useamman tiedoston refaktorointiin liittyviä ominaisuuksia. Halusin myös käyttää lyhyempiä näppäinoikopolkuja, mutta olenko valmis uhraamaan nopeuden käyttömukavuuden alttarille?

Clojuren opiskeluun vaihtoehtoja

Clojuren ja ClojureScriptin opiskeluun löytyy useita työkaluja, jotka toimivat hyvin. Alkuun voi ottaa maistiaiset kokeilemalla jotain selaimessa pyörivää REPLiä. Sen avulla voi suorittaa suoraan clojurekoodia.

Koodaajan iloksi clojurelle löytyy useita eri kehitysympäristöjä:

Counterclockwise on ilmainen Eclipsen päälle tehty ympäristö.

JetBrains kehitti IntelliJ:n päälle kokonaan oman tuotteen clojurelle. Sen nimi on Cursive. Se näkyi ClojuTRE:n demoissa suosituimpana työkaluna.

Emacsiin saa clojuren pyörimään mainiosti. Käytän sitä itse töissä, koska kokeneemmat kehittäjät osaavat näyttää sillä miten hommat tehdään.

Visual Studioon löytyy vsClojure-lisäosa, jolla pääsee vauhtiin.

Jos haluat opiskella clojurea, voit joko lukea siitä kirjasta, suosittelen Clojure for the brave and true -opusta. Se on kirjoitettu kieli poskessa ja se sisältää hyviä linkkejä lisäopiskelua varten. Aloitin itse sitä kautta.2016-07-19-11-57-22

Ehkä matalin kynnys tulee kuitenkin pyöräyttämällä läpi yksinkertainen hands-on harjoite. Sellainen löytyy try clojuresta. Sen päristely kestää vain 5 minuuttia. Suosittelen lämpimästi. Siinä kerrotaan suoraan mitä pitää kirjoittaa, joten se onnistuu helposti. Toisaalta siinä ei sukelleta kovinkaan syvälle clojuren mahdollisuuksiin.

Omaa osaamista voi vahvistaa ratkomalla koodisokeriongelmia 4Clojuren sivuilla. Kannattaa luoda käyttäjätunnus, niin edistyminen tallentuu. Ratkaisujen löytäminen vaatii rajapintojen tuntemista, tuskastuttavaa ja lopulta palkitsevaa. Apuna voi tietenkin käyttää Cheatsheet-sivua tai vaikka lueskella aiemmin mainittua kirjaa. Hyviä esimerkkejä löytyy myös clojuredocsista, siellä on rajapinnan lisäksi näppäriä esimerkkejä. Stackoverflowsta ei vielä löydy vastauksia, joten kannattaa panetua muuhun materiaaliin.

Exercism.io & clojure on suosikkini itseopiskelua varten. Se tosin vaatii oman koneen ja ympäristön, jossa ratkaista tehtäviä. Exercism antaa kuitenkin vapaat kädet ongelmien ratkaisuun. Ongelman voi ratkaista kauniilla koodilla tai kirjoittamalla apufunktioita ja karmean pitkän hässäkän, kuten itse teen ensimmäisellä iteraatiolla. Löydettyäni ratkaisun yritän jalostaa mörkömöhkäleestäni kaunista koodia.

Valitse oma polkusi clojureen! Opiskele niin paljon kuin on tarpeen tai syöksy kielen syvyyksiin oivaltamaan. Nauti.

Visual Studion nopeuttaminen

Törmäsin fantastiseen lastuun, jossa tiivistettiin kuinka Visual Studion käännösaikaa voi nopeuttaa.

  1. Käynnistä Visual Studio safe mode -tilassa. Tiedät hidastavatko lisäosat.
    C:\WINDOWS\system32>devenv /SafeMode
  2. Käytä SSD-levyä! Perinteinen kiintolevy syö aikaasi.
  3. Säädä virussuojaustasi. Poista virustarkistus Visual Studion exe-tiedostoilta ja käännöskansioilta.
  4. Käytä RAM-levyä. Mikäli käytät perinteistä kovalevyä, voit osioida käyttömuistista palan projektin kääntämistä varten.
  5. Selvitä mistä hitaus johtuu eli käytä prosessinvalvontaa sysinternals:n kautta.
  6. Sammuta Visual Studion IDE:n ominaisuuksia.

nousuMinua arveluttaa virustorjunnan sammuttaminen, mutta vain hetken. Kymmenen vuoden aikana koneelleni on pyrkinyt ehkä kolme virusta. Nämä yrittivät tulla selaimen kautta, kun napsautin vahingossa jotain mainosbanneria jollain blogisivulla.

Hitauden selvittäminen onnistuu kohtuullisesti myös perinteisellä järjestelmävalvonta-sovelluksella. Jos on CPU aikaa, muistia ja levytilaa vapaana, mutta silti Visual Studio jumittaa, niin hitaus tulee Visual Studion sisältä. Jotkut ovat poistaneet ReSharperin käytöstä, koska se hidastaa koodausta. Ainakin vanhemmat versiot ovat tahmanneet IDE:ä joskus pahastikin.

Olen joskus sammuttanut tiedoston seurannan Solution Explorerista, säästääkseni joitain kymmeniä millisekunteja. Edelleen riippuu kehitysympäristöstä mitä ominaisuuksia kannattaa ja voi pitää päällä.

BuildVision lisäosa

Helppous, selkeys ja käytettävyys. Näiden takia pidän BuildVisionista. Lyhyt esimerkki alkuun.

12>Build succeeded.
12>
12>Time Elapsed 00:00:01.41
========== Build: 12 succeeded, 0 failed, 122 up-to-date, 0 skipped ==========

Verratessani BuildVisionin näkymää vilisevään output-ikkunaan, näen helpommin missä mennään ja pystyn peruuttamaan käännöksen napin painalluksella. No joo (Ctrl + Pause/Break) pysäyttää normaalin buildin, mutta output-ikkunasta ei näe yhtä selvästi milloin yhden solutionin projektin kääntäminen epäonnistuu. BuildVision näyttää myös solutionin käännösajan ja statusbarissa juoksevan ajan, kun build on käynnissä.

BuildVision_build_time

BuildVision selkeyttää solutionin kääntämistä, kun solution sisältää useita projekteja. Sen kautta näkee selvästi mitä projekteja ei tarvitse kääntää, ”UpToDate”, mitkä projektit käännetään ”Building / BuildDone” ja mitkä projektit eivät käänny. Viimeisimmät merkataan punaisella ruksilla.

Selkeä käännösaika sai sukat pyörimään jaloissani. Sen näkee ensimmäisen onnistuneen käännöksen jälkeen, isolla. Kun build kestää pitkään ehdin hakea vaikka kupillisen kuumaa. Pienen solutionin kanssa askarrellessa ymmärtää pitää puolen minuutin tauon.

Suosittelen kokeilemaan, ei maksa mitään.

Koodailukoneen SSD-levy kuntoon

Työkaverini Pate kertoi hyvän ohjeen kuinka SSD-levyltä saa pois windowsin sivutustiedoston. SSD-levyn kestävyyteen vaikuttaa levylle tehtyjen kirjoitusten määrä, joten kannattaa siirtää levyltä pois hiberfil.sys ja pagefile.sys. Näihin tiedostoihin windows raapustelee jatkuvasti kaikenlaista, kun tietokoneen muisti alkaa täyttyä.

Pöytäkone. Käyttöjärjestelmä C-asemalla, SSD-levyllä. Harvemmin käytetty data perinteisellä kovalevyllä, D-asemalla. Käyttöjärjestelmäksi asennettu Windows 7.

Koodailukonetta ei tarvitse laittaa nukkumaan. Sen voi rehellisesti sammuttaa, kun työpäivä on ohitse. Koneelta kannattaa siis poistaa koko toiminto. Hiberfil.sys poistuu vain Hibernate-ominaisuuden poistamalla. Tämä tapahtuu Command Promptissa (aja ”Run as administrator” varmuuden vuoksi) antamalla komento ”powercfg –h off”.

Pagefilen voi siirtää D-asemalle seuraavasti:
Valitse linkit Control Panel > System > System > Advanced System Settings. System Properties -ikkuna avautuu. Advanced –välilehden ylin Settings… –kohta avaa Performance Options -ikkunan. Vaihda Advanced –välilehti ja napsauta keskellä olevaa Change… -nappulaa.

Olet vihdoin Virtual Memory -ikkunassa. Poista ruksi kohdasta ”Automatically manage paging file size for all drives”. Lopuksi valitse oman maun mukaan joko pagefilen siirto D-asemalle tai täppä kohtaan ”No paging file”.

pagefilen siirtäminen

pagefilen siirtäminen

Jos poistaa sivutustiedoston, niin kone ei hidastu muistin loppuessa vaan käyttäminen tökkää tyystin. 64-bittisellä windowsilla 8 tai 16 gigan keskusmuistilla ei muisti pääse helposti loppumaan. Ei ainakaan perinteisessä koodailukäytössä. 32-bittisen ympäristön, kymmenen sovelluksen tai muistia syövien sovelluksen käyttäjien kannattaa säilyttää pagefile.

Post Navigation