Kultainen koodi

.NET-osaajan ajatuksia paremmasta koodailusta

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.

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.

Miksi kirjoittaa yksikkötestejä?

Olen kirjoittanut yksikkötestejä n. 7 vuotta. Vasta viime aikoina olen oppinut uusia tapoja yksikkötestien kirjoittamiseen. Mutta miksi ihmeessä yksikkötestejä kirjoitetaan?

Miksi

  1. Luotettavuus. Yksikkötesti on ainoa tapa varmistaa, että koodi tekee nyt ja tulevaisuudessa haluamani asiat. Jos minä tai joku muu muokkaa koodia, niin yksikkötestillä voi varmistaa, ettei vanha toiminnallisuus mene rikki.
  2. Yksikkötestillä testaaminen käy nopeammin, jos testiä varten pitää sovellus saada tiettyyn tilaan. Testaajan sisäänkirjautuminen ja erilaisten testitapausten luominen vie hyvän tovin.
  3. Parempilaatuinen koodi. Yksikkötestattava koodi on yksinkertaista. Yksikkötestejä kirjoittaessa jättimetodit ja monimutkaiset kokonaisuudet pikkoutuvat pienempiin osiin kuin itsestään. Muut kehittäjät lukevat tällaista koodia meilummin kuin 2000 rivin hirviömetodia, jossa on runsaasti if-lohkoja.
     
    Lisäksi muilta kuultua:

  4. Vähentää koodista löytyviä virheitä (bugit).
  5. Voi tehdä suuria muutoksia koodiin nopeasti.
  6. Välitön palaute koodatessa. Tiedät heti koodisi toimivan, kun syttyy vihreä valo.
  7. Testien avulla näkee miten metodin on tarkoitus toimia.
  8. Testien avulla ymmärtää koodin rakenteen paremmin.
  9. Yksikkötestin avulla pääsee helposti liikkeelle koodaamisessa, jos pitää luoda suurempi kokonaisuus.
  10. Testien kirjoittaminen on hauskaa.

Se maksaa

Pieniä erilaisia asioitaNiin maksaa. Yksikkötestien kirjoittaminen vie hieman enemmän aikaa, mutta menetetty aika ja raha saadaan takaisin virheiden vähentyessä (luotettavuus), tuoteen laadun parantuessa (asiakastyytyväisyys), ylläpiettävyydessä (koodia voi muokata ja refaktoroida tai optimoida nopeammaksi) ja virheiden metsästyksen helpottuessa.

Yksikkötestattu koodi sisältää vielä virheitä. Kehittäjä joskus ymmärtää väärin ja kirjoittaa siksi viallista koodia tai unohtaa jonkin erikoistapauksen. Tällöin kirjataan vika. Kirjoitetaan yksikkötesti, jolla todetaan virheen toistuvan. Korjataan koodi. Vanhoista yksikkötesteistä näkee heti, ettei aiempi toiminnallisuus hajonnut. Käsin testattaessa prosessi olisi hitaampi, koska uudelleentestaus kestää.

Mitä ei kannata testata

Käyttöliittymän ulkoasun tai toimintojen yksikkötestaaminen on harvoin kannattavaa. Elementtien sijainti ja ulkoasu korjataan tyypillisesti kerran.

Jos sovellus käyttää omaa tietokantaa, datan oikeellisuutta ei tarvitse testata. Tallennan kantaan aina hyvälaatuista dataa. Mikäli data tulee ulkoisesta järjestelmästä, jonkun rajapinnan kautta, niin testaaminen voi olla perusteltua.

Tiedon oikeellisuus testataan korkeintaan kerran. Tyypillinen tilanne on testata käyttäjän antama syöte esimerkiksi sotu. Kun sosiaaliturvatunnus todetaan olevan oikeassa muodossa, sitä ei tarvitse myöhemmin tarkistaa. Vapaan tekstikentän sisällön tarkistaminen on järjetöntä. Käyttöliittymäkomponenteille voi antaa kentän maksimipituuden, jolloin vältytään turhilta tekstin pituustarkastuksilta.

Kaikkia tapauksia EI testata. Yksikkötesteihin kirjoitetaan joitain mahdollisia virhetapauksia, joilla voidaan varmiistaa metodin hyvä käytös virheellisellä syötteellä esim. null. Jos koodi laskee jotain, riittää todeta induktiivisesti, että se toimii. Siis tapauksessa 0, perusarvot. Tapauksessa yksi ja n+1. Yksikkötestin sisällä ei pitäisi koskaan olla for-silmukkaa.

Mitä seuraavaksi

Ota kehitysympäristö esille ja aloita yksikkötestien kirjoittaminen!

Katso myös

Windows Forms lokalisointi, Satellite Assemblies

Windows Forms -lokalisointi eli kieliversioiden tarjoaminen teksteille ei käy käden käänteessä. Teknisesti asia hoidetaan yksinkertaisesti. Luodaan yksi resurssitiedosto jokaiselle tarvittavalle kielelle ja merkkijonojen käännökset sijoitetaan näihin tiedostoihin. Uudemmilla tekniikoilla, kuten WPF, tämän voi automatisoida hyvin pitkälle esimerkiksi ReSharperilla.

Demoissa käytetty Microsoftin ”automaattinen” kieliversiointi luo jokaiselle lomakkeelle ja UserControllille omat resurssitiedostot. Esimerkiksi kymmenen formin ja viiden UserControllin projektissa tällöin kahdelle kieliversiolle tulisi kolmekymmentä resurssitiedostoa, joissa sama teksti toistuisi useaan kertaan. Ok- tai Peruuta-tekstit pitäisi kääntää jokaisen komponentin kohdalla erikseen ja muistaa tehdä muutokset jokaiseen resurssitiedostoon.

Windows forms -lokalisointi toimii näin:
1. Luodaan resurssitiedostot käytetyille kielille
2. Luodaan sovelluskohtainen ResourceManager
3. Asetetaan lomake tai UserControl lokalisoitavaksi
4. Tehdään lokalisointi koodin puolella
5. Luodaan lokalisoitavat tekstit resurssitiedostoihin
ja
6. Luodaan paikka, jossa voi vaihtaa kieliasetusta

Vaiheet 1 ja 2 tehtään kerran. Vaiheita 3-5 toistetaan jokaisen lokalisoitavan lomakkeen ja UserControllin kohdalla. Sovelluksesta riippuen, kieliversion vaihtaminen sijoitetaan sovelluksen mukaisesti joko aina nähtäville tai kertavalinnaksi.

Kieliversioitu testilomake

Yksinkertainen lomake Satellite Assembly -lokalisointia varten.

1. Luodaan resurssitiedostot käytetyille kielille

Luo projektiin Resources-kansio. Lisää sinne resurssitiedostot. Geneerinen en-valinta sopii hyvin Suomalaiseen makuun, koska meillä ei yleensä tehdä suurta eroa Amerikan- ja Britannianenglannin välille.

Luo resurssitiedostot

Luo resurssitiedostot

2. Luodaan sovelluskohtainen ResourceManager

Luo päälomakkeelle tai sovelluksen avaavaan program-kohtaan globaali ResourceManager.

private ResourceManager _resourceManager = null;

Initialinnin yhteydessä aseta nykyinen kulttuuri, tässä tapauksessa Suomi ja sen lisäksi viittaus resurssitiedostojen sijaintiin.

Thread.CurrentThread.CurrentCulture = new CultureInfo("fi-FI");
Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture;
_resourceManager = new ResourceManager("WFSatelliteAssembly.Resources.WFSatelliteAssembly", 
                                       Assembly.GetExecutingAssembly());

Globaalin resurssienhallitsijan sijaan voit luoda myös aina uuden, jos siltä tuntuu. Tällöin pitää huolehtia resurssitiedostojen löytymisestä, varsinkin jos yritetään viitata niihin toisesta projektista käsin. Useampaa projektia käytettäessä globaali olio tuntui kätevämmältä.

3. Asetetaan lomake tai UserControl lokalisoitavaksi

Valitse haluttu luokka ja muuta se lokalisoitavaksi.

Laita lokalisointi päälle

Laita lokalisointi päälle

4. Tehdään lokalisointi koodin puolella

Konstruktoriin, heti komponenttien initialisoinnin jälkeen aseta kieliversioidut tekstit.

InitializeComponent(); // Visual Studion luoma metodi
UpdateUiControls();

Itse päivitysmetodi

private void UpdateUiControls()
{
    try
    {
        if (_resourceManager != null)
        {
            Text = _resourceManager.GetString("Lomakkeen otsikko");
            uiLabelFirst.Text = _resourceManager.GetString("Eka teksti");
            uiLabel1.Text = _resourceManager.GetString("Toka teksti");
            uiLabel3.Text = _resourceManager.GetString("Kolmas teksti");
            uiLabel4.Text = _resourceManager.GetString("Valitse kieli");
            uiButton1.Text = _resourceManager.GetString("Peruuta");
            uiButtonTemput.Text = _resourceManager.GetString("Tee temput");
        }
    }
    catch (System.Exception e)
    {
        MessageBox.Show(e.Message);
    }
}

5. Luodaan lokalisoitavat tekstit resurssitiedostoihin

UpdateUiControls-metodissa annetaan avain, jonka perusteella haetaan lokalisoitu teksti. Esimerkiksi lomakkeen otsikko haetaan avaimella ”Lomakkeen otsikko” ja sen arvo suomeksi on ”Monikielisyys”. Jos kielen vaihtaa englanniksi, otsikon teksti muuttuu arvoon ”Satellite assembly test”.

Suomenkielinen lokalisointi

Suomenkieliset tekstit

Englanninkielinen lokalisointi

Englanninkieliset tekstit

6. Luodaan paikka, jossa voi vaihtaa kieliasetusta

Kielen valinta voidaan tehdä RadioButtonilla seuraavasti:

private void uiRadioButton_Click(object sender, Resco.UIElements.UIMouseEventArgs e)
{
    UIRadioButton radioButton = sender as UIRadioButton;
    string culture = string.Empty;
    if (radioButton == null) return;

    switch (radioButton.Text)
    {
        case "Suomi":
            culture = "fi-FI";
            break;
        case "English":
            culture = "en-GB";
            break;
    }

    // This is used for the language of the user interface
    Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo(culture);
    // This is used with formatting and sort options (e.g. number and date formats)
    // e.g. a float value 2.352 will be 2,3.52 if CurrentCulture is set to de-DE
    Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo(culture);
}

Näillä ohjeilla voi luoda kieliversioinnin Windows Forms -sovellukselle.

Katso myös

Bittivektorin tallentaminen integerinä

Bittivektori tallentaa kätevästi useamman muuttujan arvot yhteen muuttujaan. Aivan fantastinen keksintö. Se perustuu bitteihin. Luvut voidaan ilmaista nollina ja ykkösinä. Saman tiedon voi tallentaa merkkijonona ”00100101” tai lukuna. Luku mahtuu pienempään tilaan, jos data siirretään jonkinlaisen xml-wrapperin kautta. Tällöin yksi muuttuja vie huomattavasti vähemmän tilaa kuin usea boolean arvo.

Bittioperaatiot C#-kielellä

.NET-kielen bittioperaatiot ovat:

operaatio operattori
JA &
TAI |
XOR ^
EI ~

Pari käytännön esimerkkiä

Klassinen esimerkki löytyy yhteyden muodostuksesta. Päätelaitetta kätellessä voidaan kertoa muutama yhteyteen liittyvä tieto. Aikanaan myös datan koodaustyyli.

Bit Bit Value Meaning (1) Meaning (0)
7 128 Ready Off-Line
6 64 Connected Not Connected
5 32 Carrier Present Carrier Absent
4 16 Log Data Do Not Log Data
3 8 Auto Answer Mode Manual Answer Mode
2 4 Echo Commands Do Not Echo Commands
1 2 Use 8 Data Bits Use 7 Data Bits
0 1 Use Odd Parity Use Even Parity

Toinen tapaus voi olla käyttäjätiedot ja asetukset. Esimerkiksi sukupuoli, onko admin, jne. Mikäli asetuksissa käyttöliittymälle on valittavana erilaisia tyylejä, niin tyylivalinnat voi tallentaa bittivektoriin.

Bittivektoria voi käyttää valittujen viikonpäivien tallentamiseen. Mitkä tahansa päivät voidaan valita ja tallentaa tieto yhteen int-muuttujaan. Viikonpäiviä voi käyttää esimerkiksi herätyskello-toiminnossa. Sen voi laittaa soimaan tiettyinä viikonpäivinä. Sähköpostimuistutuksen tekemättömistä töistä voi lähettää tiettyinä viikonpäivinä (ma, ke, pe). Toistuvalle kalenteritapahtumalle voi määrätä halutut viikonpäivät.

päivä arvo
Maanantai 1
Tiistai 2
Keskiviikko 4
Torstai 8
Perjantai 16
Lauantai 32
Sunnuntai 64

Tyypillisesti käyttäjä valitsee käyttöliittymästä muutaman valinnan (CheckBox).

Valitut päivät

Valitut päivät

Valitut viikonpäivät saadaan tallennettua yhteen muuttujaan tai-operaattorin avulla.

int valitutPäivät = 0;

if (Maanantai.IsChecked != null && Maanantai.IsChecked.Value) 
    valitutPäivät = (int)Viikonpäivä.Maanantai;
if (Tiistai.IsChecked != null && Tiistai.IsChecked.Value) 
    valitutPäivät = (int)Viikonpäivä.Tiistai | valitutPäivät;
if (Keskiviikko.IsChecked != null && Keskiviikko.IsChecked.Value)
    valitutPäivät = (int)Viikonpäivä.Keskiviikko | valitutPäivät;
if (Torstai.IsChecked != null && Torstai.IsChecked.Value)
    valitutPäivät = (int)Viikonpäivä.Torstai | valitutPäivät;
if (Perjantai.IsChecked != null && Perjantai.IsChecked.Value)
    valitutPäivät = (int)Viikonpäivä.Perjantai | valitutPäivät;
if (Lauantai.IsChecked != null && Lauantai.IsChecked.Value)
    valitutPäivät = (int)Viikonpäivä.Lauantai | valitutPäivät;
if (Sunnuntai.IsChecked != null && Sunnuntai.IsChecked.Value)
    valitutPäivät = (int)Viikonpäivä.Sunnuntai | valitutPäivät;

Tässä esimerkissä käytetään viikonpäiville seuraavaa enumia

public enum Viikonpäivä
{
    Maanantai = 1,
    Tiistai = 2,
    Keskiviikko = 4,
    Torstai = 8,
    Perjantai = 16,
    Lauantai = 32,
    Sunnuntai = 64
}

Päivämäärän valinta tarkistetaan haetaan muuttujasta ja-operaattorin avulla ja asetetaan CheckBoxeihin

int valitutPäivät = 45; // ma, ke, to ja la

if ((valitutPäivät & (int)Viikonpäivä.Maanantai) != 0)
    Maanantai.IsChecked = true;
if ((valitutPäivät & (int)Viikonpäivä.Tiistai) != 0)
    Tiistai.IsChecked = true;
if ((valitutPäivät & (int)Viikonpäivä.Keskiviikko) != 0)
    Keskiviikko.IsChecked = true;
if ((valitutPäivät & (int)Viikonpäivä.Torstai) != 0)
    Torstai.IsChecked = true;
if ((valitutPäivät & (int)Viikonpäivä.Perjantai) != 0)
    Perjantai.IsChecked = true;
if ((valitutPäivät & (int)Viikonpäivä.Lauantai) != 0)
    Lauantai.IsChecked = true;
if ((valitutPäivät & (int)Viikonpäivä.Sunnuntai) != 0)
    Sunnuntai.IsChecked = true;

Mielestäni yhden muuttujan käyttäminen usean boolean muuttujan sijaan säästää tilaa, nopeuttaa tiedonsiirtoa ja joissain tapauksissa selkiyttää koodia. Tosin kielen toimintaa ja rakennetta pitää tuntea hieman enemmän. Toinen vaihtoehto tässä tapauksessa olisi käyttää seitsemään boolean muuttujaa ja sijoittaa tieto niiden kautta.

Mikäli kaikki tämä tapahtuu sovelluksen sisäisesti, niin toteutustavalla ei ole suurta merkitystä. Jos kuitenkin joudutaan siirtämään tietoa netin ylitse, niin asialla on merkitystä. Sovelluksen toiminnan kannalta hitain operaatio on tiedon siirtäminen netin ylitse. Seuraavaksi tulee levyoperaatiot ja nopeimpia toimintoja ovat sovelluksen sisäiset tapahtumat.

Bittioperaatioden käyttäminen tiedon tiivistämiseen vähentää siirretyn datan määrää ja toimii siinä hyvin.

Katso myös

Oheessa muutamia linkkejä, joiden takaa löytyy eri tavoin selitettynä miten bittioperaatiot toimivat. Toisissa käydään hyvin perusteellisesti asioita läpi ja toisissa painotetaan enemmän koodin toimintaa. Avaa muutama ja omaksu tiedot niistä, joista opit asian helpoimmin.

Suojattu: Vuoden sisäinen retro

Tämä sisältö on suojattu salasanalla. Syötä salasanasi näyttääksesi sisällön:

Ohjelmistojen hankinta

Kirjoitukseni menee ohi ohjelmoinnin, hankinnan puolelle. Minua ottaa päähän, kun kunta tai julkinen instanssi hankkii itselleen ohjelmiston väärin perustein. Ostetaan halvin, eikä se mitä tarvitaan.

Otso Kivekäs listasi hyvin erilaiset ohjelmistojen ostotavat. Näiden lisäksi kannattaa kysyä eri kunnista ja toimijoilta onnistuneista projekteista. Mikä johti onnistuneeseen hankintaan? Miten määritellään hyvä tarjouspyyntö? Menen asian edelle.

Kivekäs esittää kolme hyvää tapaa hankkia tarvittava ohjelmisto:

  1. Ostamalla palveluna (pilvestä)
  2. Ostamalla valmiin standardituotteen
  3. Teettämällä järjestelmän avoimena

Ensimmäinen on halvin ja yleensä vaivattomin ylläpitää. Toinen on kalliimpi, mutta senkin saa heti käyttöönsä. Viimeinen vaihtoehto työllistää kaltaisiani tekijöitä.

Hankkijan kannattaa välttyä toimittajaloukulta. Tarjousta muodostaessa pitää arvioida hinnan lisäksi tekijöiden kokemusta, alakohtaista kokemusta ja toimittajan taustoja. Jotta hinta ei määräisi koko projektin tekijää, se voi muodostaa 40 % hyväksyntään johtavasta pisteytyksestä. Tällöin päättäjät voivat valita haluamiensä kriteerien perusteella parhaat tekijät. Ohjelmistopuolellakaan ei voi ostaa hyvää halvalla.

Kuten Kivekäs mainitsee, pitää tehdystä ohjelmistosta löytyä:

  • Julkiset rajapinnat, joiden avulla tiedon saa muihin järjestelmiin (ilmaiseksi). Jos järjestelmä on kehitetty veronmaksajien rajoilla, kerätyn tiedon voi antaa myös julkisesti käytettäväksi. Vrt. Helsingin bussien seuranta kännykkäsovelluksella.
  • Standardien käyttö. Standardin mukaista koodia voi kuka tahansa lukea ja toimittajan vaihtaminen on mahdollista.
  • Vaiheittainen julkaisu, jonka avulla voidaan alusta asti seurata ohjelmistokehityksen kulkevaan oikeaan suuntaan.
  • Modulaarinen arkkitehtuuri skaalauksen ja ylläpidettävyyden takia.

Nostaisin nämä tärkeimmiksi, vaikka muutkin esitetyt kohdat ovat pakollisia hyvän ohjelmiston toimituksessa.

Ohjelmistojen kehittäjänä ja veronmaksajana haluan tehdä ja ohjata ostajat teettämään hyviä projekteja. Jos projektin ”onnistumisen” ainoa kriteeri on hinta, niin saa sekundaa. Pyydän päättäjiltä viisastumista.

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