Kultainen koodi

.NET-osaajan ajatuksia paremmasta koodailusta

Archive for the tag “VisualStudio”

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?

Attach To Anything

AttachToAnythingRajapintojen (Silverlight, SOAP ym) ja palvelujen (windows service) debuggaukseen löytyy kätevä lisäosa. Attach To Anything kiinnittää debuggerin parilla hiiren painalluksella haluttuun prosessiin. Toinen vaihtoehto on tietenkin heittää perinteinen näppäinsarja:
Alt + d, Alt + p ja sitten valita hiirellä listasta sopiva prosessi.

Attach To Anything myös odottaa prosessin nousemista. Voi pistää debuggerin odottamaan, että IIS nousee pystyyn ensimmäisen kutsun myötä. Debug-valikon kautta joutuu sen sijaan odottamaan, että palvelu tai muu moduli lähtee käyntiin.AttachToAnything2

Suosittelen kokeilemaan, jos pitää koodata verkkosivujen, rajapintojen, palvelujen ym. kanssa jotain. Mielestäni erinomainen lisä Visual Studioon.

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.

C#-kielen kehitys

Pidän rajapinnoista ja tehokkaasta ohjelmoinnista. Ensimmäinen pysäyttävä kokemukseni syntyi siirtymä C# 2.0 ja 3.0:n välillä, kun pääsi kirjoittamaan autoproperty-tyyppisiä get ja set metodeja. Näitä tuttuja:

public int Foo { get; set; }

C# 6 tarjoaa vihdoin pelkän getterin sisältämät propertyt.

public class Point
{
public int X { get; }
public int Y { get; }

public int ReadWrite { get; set; }
}

C# 5 tarjosi async ja await -toimintoja, jotka olivat Taskin kanssa tuttuja C# 4:n puolelta.

Evoluutio 5-versioon asti löytyy evoluutiomatriisista.

C# 6 näyttää olevan muutoinkin ohjelmoijan kannalta se kieliversio, joka vähentää koodin kirjoittamista. Olen aivan täpinöissäni, koska lyhyen parametrisoidun stringin voi luoda luettavammassa muodossa. Vanha toteutus

return String.Format("({0}, {1})", X, Y);

muuttuu muotoon

return "(\{X}, \{Y})";

Kuutosen mukana näyttää tulevan paljon muitakin herkkuja matkaan. Lambda-lauseella saa tehtyä uusia laajennuksia uudella =>-nuolioperaattorilla. Jalka väpättää innostuksesta uutta kieliversiota käyttäviä projekteja odotellessa.

Vielä C# 6 ei asennu automaattisesti vielä Visual Studio 2013 mukana, mutta ehkä tulevaisuudessa sen saa päivitettyä yhdeksi mahdolliseksi kieliversioksi. Tähän mennessä VS ja eri kieliversiot ovat pyörähtäneet aika mukavasti käyntiin. Varsinkin kun VS2012 mukana voi kehittää useammalla eri versiolla eli kieliversio ei ole naimisissa IDE-version kanssa.

Windows forms -komponenttien siirtely ja editointi

Windows Forms -maailmassa UI elementit sijoittuvat aina johonkin kohtaan elementtien hierarkiaa. Esimerkiksi peruslomakkeella on Grid, joka sisältää pari elementtiä. Toinen voi olla toisen tason grid, joka sisältää syöttökenttiä ja painikkeita.

Murheita tulee helposti silloin, kun elmenttejä pitää siirtää näytön sisällä. Pitää ottaa yläosan syöttökentät ja siirtää ne alaosaan tai jakaa pitkä lomake parille tabille. Perinteinen leikkaa ja liimaa ei toimi, hierarkiasta johtuen. Vai olisiko ongelma editorissa?

Microsoft on ratkaissut ongelman Document Outline -työkalulla, jossa näkyy elementtien hierarkia. Siellä sitten vain raahaillaan elementtejä hierarkiasta toiseen. Homman saa tehtyä, mutta ei se tunnu yhtä kätevältä kuin WPF:n xaml-tiedoston editointi.

Document outline avautuu komennolla Ctrl+W, U tai VS2010:ssa Ctrl+ALT+T.

Post Navigation