Kuidas hinnata koodi ilu?

Proekspert annab igal aastal Robotexil välja ilusa koodi auhinna. Miks see ilus kood üldse oluline on? Kas pole nii, et kui robot mängib jalgpalli nagu Lionel Messi, siis võib ta kood olla kole kui öö? Ja mis on üldse kriteeriumid, mille järgi robotite koodi ilu hinnata saab?

Istusime Proeksperdis kogenud koodihindajate ja Robotexil osalejatega maha (Vambola Kotkas! Roland Tepp! Indrek Mägi! Indrek Tamm! Eric Johann Istal!) ja nende mõtted väärivad jagamist.

Kui Barbara Schwarz 9 aastat tagasi ootamatult kiirendama hakanud Toyotas hukkus, ei osatud ka esialgu arvata, et selle põhjustas lihtsalt üks eriti kole kood. Eksperdid tõestasid hiljem, et ameeriklase surma põhjuseks oli aja jooksul spagetihunniku sarnaseks arenenud autotarkvara, mis loojate kontrolli alt oli ammu väljunud.

Enamasti kole kood inimesi ei tapa, kuid ta võib muuta meie elu keeruliseks. Ta on nagu küberrünnak iseenda vastu, mis trollib inimesi ja äriprotsesse. Musta auku kaduv tööaeg, suured kulud, krussis närvid, rikutud kasutajakogemus. Ilus kood võib seevastu teha inimeste elu paremaks, olla majanduslikult kasulikum ja kindlasti ka turvalisem kui kole kood.

Kui nüüd konkreetselt Robotexist rääkida, siis seal ilusat koodi hinnates on meil välja kujunenud juba üsna selged kriteeriumid.

Me otsime koodi, mis oleks loetav nagu hea lühijutt, kus poleks liigseid sõnu ega ridu ning kus iga funktsioon näeb vaeva suurepärase terviku nimel. Otsime koodi, mis ei ole arusaadav ainult masinale, vaid ka teisele inimesele, kes seda tulevikus edasi peab arendama.

Mõned näited:

  • inimkeskse koodi eraldi tükid võiksid mahtuda ühele leheküljele
  • read ei tohiks olla hoomamatult pikad,
  • iga koodijupp võiks teha ühte selget asja,
  • muutujad võiksid olla nimetatud nii, et nende funktsioon oleks koheselt arusaadav
  • kirjavahemärgid võiksid olla lahendatud läbivalt ühtses stiilis.

Ilus kood ei sisalda ajalookihte, milles sumbates keegi ühel päeval võib avastada muistse viikingilaeva jäänused. Avastamisrõõm on muidugi tore, kuid kui me ei tea, mis minevikuloori taga peidus on, siis me ei tea lõpuni ka seda, mida kood teeb ja kuidas seda vajadusel parandada.

Ilus kood sisaldab kommentaare, kuid mitte liiga palju, sest see, kui sa pead juba oma tööd kommenteerima, tähendab tõenäoliselt seda, et kood on liiga keeruline. Ilusat koodi on raske ehitada copy+paste’iga, sest selline buldooserimeetod ei arvesta nüanssidega, millest võib sõltuda väga palju. Lisaks toob kopeerimine endaga kaasa ka vigade paljundamise ohu.

Kindlasti on Sinul oma kogemustele tuginedes veel palju rohkem häid mõtteid, milline peaks olema üks ilus kood. Kõik täiendused ja kommentaarid on oodatud!

 

Milton tahab eesti keelt õppida

Arendame Proeksperdis teadusliku hobi korras eesti keelt rääkivat tehisintellekti (AI). Tema nimi on Milton-Tormi Kana. Milton oli veel kuu aega tagasi täiesti kõnevõimetu, kuid tänaseks on ta märkimisväärselt arenenud ja üsna jutukas. Kahjuks kisuvad vestlused temaga kiirelt rööpast välja, sest tema sõnavara on piiratud ja ta on veel liiga vähe lugenud, et pikemalt sisukatel vestlustel vastu pidada. Continue reading “Milton tahab eesti keelt õppida”

Modular Electronics Factories

Interview with Terry London (Product Owner, Proekspert) at “Industry 4.0 in Practice” conference. To participate Modular Electronics Factories platform sign up proekspert.ee/mef

There are millions of software developers in the world. But the world does not require software, the world requires user-friendly functionality that both looks good and serves real business purposes. This is where Proekspert comes in.

How do you bring factories in to the Industry 4.0 era?

In our vision, tomorrow’s factories should resemble today’s mobile platforms. Five years ago we were still buying feature phones – your selection was based on features. Now you’re in charge of the building – you select a platform and the applications to go with it. The same should apply to Industrial factories. When upgrading and assembling a factory you are mostly dependent on expensive solutions from proprietary factory line providers. The majority of Estonian factories creating custom products are operating according to the high mix/low volume model. These factories thus need to change their product directions often. A single factory line can consist of tens of machines, meaning that they have at least 3 different machine providers. The machines have limited connectivity, in order to create a complicated manufacturing execution solution every single machine needs to be integrated with the IT system, one-by-one. Replacing a device means creating all those interactions again, it’s expensive and time consuming.

We on the other hand want to offer a plug-in based solution which could be shared across different factories. With this, platform factories will enter the Industry 4.0 era with a flexibility and automation in production that keeps them competitive. Continue reading “Modular Electronics Factories”

Elu välikontoris Keri saarel

Meie veel värske ja põnev sopiline kontor on hirmus äge, aga veel ägedam on, kui saad vahelduseks totaalselt äraspidises keskkonnas enda tööd teha. Selline võimalus avanes seiklushimulisematele Proeksperdi töötajatele eelmisel nädalal – meil oli ajutine harukontor tillukesel Keri saarel.

Emotsioone, kuidas sinna “kontorisse” tööle sõita oli ning mida tähendab elu 12-voldiste akude peal, kirjeldab elavalt enda blogis kvaliteediinsener Kunnar.

 

Noorteakadeemia vol. 1 ehk kuidas seadmetele hing sisse puhuda

Noorteakadeemia on kutsutud ellu ideega ärgitada leiutamishuvi meie kõige nooremates. Esiotsa otsustasime kokku kutsuda Proeksperdi töötajate lapsed. Kohtumine sai korraldatud innovatsiooni- ja ettevõtluskeskuses Mektory, mille üheks eesmärgiks on tegeleda järelkasvuga ja näidata kooliõpilastele, et inseneri roll on huvitav, jõukohane ja elulähedane! Mektory majas on loodud palju võimalusi ka lastele.

Enne leiutama hakkamist tegime kiire ringkäigu Mektory põnevates ruumides. Kõigepealt ajas lapsed elevile rääkiv puu, mida sai ägedalt sakutada ja mis selle peale siiski inimkeeles (ehkki välismaises) palus end mitte nii tugevalt raputada. Kõigele lisaks teatas ta, et pole slot machine. Muuhulgas piilusime ka robotooriumisse, kus ka meie kõige suuremal lapsel Lauril silmad põlema läksid.

Continue reading “Noorteakadeemia vol. 1 ehk kuidas seadmetele hing sisse puhuda”

Juhtideta organisatsiooni võimalikkusest Proeksperdis

Enam kui viis aastat tagasi riigisüsteemist Proeksperti tööle tulles võttis mind vastu eriline, selgelt tunnetatav kultuur. Oli meeldiv avastada, et projektijuhid ja programmeerijad olid võrdsed partnerid ja et juhil on pigem töö ära tegemiseks vajalike tingimuste loomise roll – mitte ülemuseks olemine. Selgelt paistis välja, et tarkade ja teadlike inseneride juhtimine toimub eelkõige läbi usalduse, ühiste eesmärkide ja nende saavutamise. Märksõnaks oli horisontaalne ehk lame struktuur.

Tänaseks on Proeksperdi töötajate arv enam kui kahekordistunud. Lame struktuur on asendunud mitmekihilise hierarhiaga – äriüksustega, mis koosnevad meeskonnajuhtide veetud arendustiimidest. Toimub juhtide juhtimine.

Selle algselt loogilisena tundunud mitmekihilise organisatsioonistruktuuri puudused ei lasknud ennast pikalt oodata. Kolmeks äriüksuseks jaotatud Proeksperdis hakkasid arenema erinevad inforuumid, mis sõltusid sellest, kuidas vastav juht enda üksuses juhtkonna infot edasi kommunikeerib. Ettevõttes olevad üksused omandasid justkui eraldiseisvate firmade mõttelaadi. Continue reading “Juhtideta organisatsiooni võimalikkusest Proeksperdis”

Kuidas testide automatiseerimisel õnnestuda

Testide automatiseerimine on alati kahe otsaga asi, võimaldades küll testijate igapäevatööd kergendada, kuid sama kergesti võib sellega hoopis probleeme juurde luua. Kuidas toimida, et õnnestuda? Automaattestide juurutamisel võib ette tulla mitmeid probleeme, mõned tüüpilisemad komistuskivid:

 

  • Automatiseerimine vabal hetkel. Automaattestide loomisega tegeletakse siis, kui selleks on aega – projekti töös tekkivate “aukude” täiteks, omast ajast jne. Puudub vajalik pühendumus.
  • Puudulikud eesmärgid. Milleks me üldse automaattestidega vaeva näeme? Aja säästmiseks, testimise lihtsustamiseks, testide katvuse parandamiseks? Testijate motiveerimiseks? Kõike korraga tõenäoliselt ei ole võimalik saavutada, inimeste eesmärgid on erinevad ja kui neid selgelt välja pole öeldud, on lihtne feilida.
  • Kogemus. Õigemini selle vähesus või puudumine. Automaattestid võivad kergelt muutuda haldamatuks džungliks, kui neid arendavate inimeste teadmised tarkvaraarenduse põhitõdedest on puudulikud.
  • Inimesed vahetuvad. Automatiseerimise õppimine võtab aega ja kui meeskonnaliikmed tihti vahetuvad, kaob ka omandatud kogemus.
  • Tahtmatus testida. Paljude inimeste jaoks on automatiseerimise protsess huvitavam, kui tarkvara testimine. Automatiseerimine võib muutuda mugavaks vabanduseks, miks testimisele vähem pühenduda. Sellisel juhul ei ole ka automatiseerimise väljund testimise seisukohalt tihti suurem asi.
  • Tehnilised üksikasjad. Kuidas tarkvara automatiseerida, on tehniliselt huvitav ülesanne, kuid liigne keskendumine tehnilistele probleemidele võib tähendada vajadustele üldse mitte vastavat tulemust.

 

Continue reading “Kuidas testide automatiseerimisel õnnestuda”

Automatiseerimisest tarkvaraarenduses

Tarkvara arendamisel ettetulevate korduvate protsesside automatiseerimise väärtuses kahtlevad vist üsna vähesed kogenud arendajad ja projektijuhid. Tegelikus elus aga paraku ei ole automatiseerimine kõige prioriteetsem. Sellest võibolla räägitakse projekti alguses, aga töö käigus jääb see tihti unarusse.

Iga arendaja või testija, kes nüri järjekindlusega ühe ja sama toimingu sooritamise asemel eelistab midagi kasulikku oma projekti jaoks teha, peaks tundma automatiseerimise põhimõtteid. Projektijuht, kes teab meeskonna oskuste ja aja efektiivse kasutamise eeliseid ja ei soovi riskida projekti ebaõnnestumisega, peaks oma meeskonda julgustama leidmaks aega ja võimalusi automatiseerimise rakendamiseks.

Continue reading “Automatiseerimisest tarkvaraarenduses”

Specification by Example by Gojko Adzic

Specification by Example seminar Proeksperdis

1. novembril toimus Proeksperdis inspireeriva Gojko Adzic-i poolt läbi viidud seminar Winning big with Specification by Example (SBE). SBE on oma olemuselt kollaboratiivne lähenemine nõuete defineerimisele – fookus on kommunikatsioonil ja reaalsetel näidetel, et kõigil osapooltel tekiks ühine arusaam loodava süsteemi funktsionaalsusest. Positiivse lisana muutuvad SBE “õigel” rakendamisel nõuded ka automaatselt valideeritavateks – teatud tööriistade abil saab kõigile loetavas formaadis kirja pandud nõuded automaat-testideks muuta.

  Continue reading “Specification by Example by Gojko Adzic”

“Kas me läheme sinna progema?” ehk kuidas Proeksperdi kvaliteediinsenerid BDD’d tegemas käisid

Kuna Proeksperdi kvaliteedimeeskonna eelmisest treeningpäevast oli möödunud juba hea mitu kuud, kõik olid karmidest kogemustest taastunud ning meeskonda oli lisandunud ka uusi liikmeid, oligi augustikuu eelviimane päev paras hetk järgmise väliõppuse korraldamiseks. Püüaks sellest siis ka natuke lähemalt rääkida.

Seekordse treeningpäeva teemaks sai valitud Behavior-Driven Development ehk BDD metoodika, millest olen ka varem lühidalt kirjutanud. Kuna päris tühja koha pealt on sant alustada, tuli riiulist alla tõsta ja tolmust puhtaks puhuda üks Proeksperdi sisemine projekt – Raamatukogu 2.0, mis on meie füüsilist raamatukogu toetav veebipõhine rakendus. Kuna see rakendus oli juba algusest peale loodud just BDD metoodikat kasutades, oli tegu pea ideaalse õppevahendiga.

 

Kuidas BDD töötab

BDD üks definitsioone kõlab järgnevalt:

Behaviour-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes.

Piltlikult esitades töötab see metoodika umbes nii:

  1. Iga stsenaariumi jaoks, mis kirjeldab mingit funktsionaalsust
  2. käivita stsenaarium – tulemuseks on FAIL
  3. defineeri esimene samm – ka selle tulemus on FAIL
  4. kirjuta rakenduse koodi täpselt niipalju, et sammu tulemus oleks PASS
  5. refaktoori kirjutatud kood ja korda samme 4 & 5 iga stsenaariumi sammuga kuni…
  6. …kogu stsenaariumi tulemus on PASS
  7. refaktoori rakenduse kood ja alusta uuesti sammust number 2

Continue reading ““Kas me läheme sinna progema?” ehk kuidas Proeksperdi kvaliteediinsenerid BDD’d tegemas käisid”