Kā es iemācījos mīlēt TDD

07.07.2010

Vakar es uzstājos ikgadējā Latvijas testēšanas konferencē ar prezentāciju “How I Learned To Stop Worrying and Love Test Driven Development” jeb kā es iemācījos pārtraukt uztraukties un sākt mīlēt testu virzītu izstrādi. Tā kā auditorijai patika gan slaidi (kurus pašrocīgi zīmēju uz iPad), gan arī izraisījās diskusija par saturu, tad es šeit pārpublicēju prezentācijas kopsavilkumu.

Spējajā programmatūras izstrādē (Agile software development) testēšana nav tikai “testētāja” loma, kā tas ir bijis tradicionāli, bet gan funkcija, ko jāveic jebkuram projekta dalībniekam. Testu virzīta izstrāde (Test Driven Development, TDD) ir viena no galvenajām spējās programmatūras izstrādēs praksēm, kas tiek rekomendēta programmatūras izstrādātājiem ikdienas darbā.

TDD ideja ir ļoti vienkārša. Pirms sākt jaunas funkcionalitātes izstrādi (jauna procedūra, funkcija, metode) vispirms jūs izdomājiet, kā jūs vēlētos, lai šī jaunā programmatūras vienība strādātu – uz kādiem ievaddatiem jūs sagaidat kādus rezultātus. Un šī sagaidītā funkcionalitāte tiek aprakstīta ar automatizētu vienībtestu, kas to pārbauda. Un sākotnēji izpildot šo testu tam vajadzētu beigties neveiksmīgi, jo mums šī funkcionalitāte vēl nav izstrādāta. Tikai tad mēs sākam rakstīt programmatūras kodu, lai šo funkcionalitāti realizētu un tas tiek darīts vienkāršākajā veidā, līdz tiek panākts ka izveidotais vienībtests beidzas veiksmīgi. Un pēc tam tiek pārbaudīts, ka arī visi iepriekšējie testi izpildas veiksmīgi, lai varētu pārliecināties, ka neesam neko “salauzuši”. Veicot šādu inkrementālu izstrādi ik pa laikam tiek konstatēts, ka būtu nepieciešams uzlabot esošās programmatūras iekšējo struktūru jeb dizainu. Tad tiek veikta “refaktorēšana” – programmatūras koda struktūras jeb dizaina uzlabošana, bet netiek mainīta sagaidītā funkcionalitāte. Un to, ka netiek mainīta funkcionalitāte, var pārbaudīt izpildot visus automatizētos vienībtestus.

Šī pieeja izklausās vienkārša un loģiska un tā tiek popularizēta no Agile “guru” puses, bet realitātē šo pieeju diemžēl praktizē tikai ļoti maza programmētāju daļa. Kādēļ tas tā ir?

Tādēļ ka cilvēki pēc dabas ir slinki un vienmēr mēģina atrast iemeslus, kādēļ neko nemainīt. Šeit ir pāris tipiskie argumenti, kādēļ “tas mūsu gadījumā nestrādās”:

  • “Būs nepieciešams divreiz vairāk laika, lai uzrakstītu gan kodu, gan testus.”
  • “Mums nav laika rakstīt vienībtestus, jo termiņi jau bija vakardien.”
  • “Mums ir liels esošās programmatūras kods, ko mēs uzturam, mēs nevaram tagad uzrakstīt testus visam esošajam kodam.”
  • “Mūsu esošā programmatūra ir tā uzrakstīta, ka to nevar viegli notestēt ar automatizētiem vienībtestiem.”
  • “Mūsu klients / vadība / vēl kaut kas neļauj programmētājiem veikt refaktorēšanu, visu laiku tiek prasīta tikai jauna funkcionalitāte.”
  • “Es vienā blogā izlasīju, ka TDD īstenībā nekādus ieguvumus nedod.”

Ja jūs kaut ko nemākat, tad jums vispirms tas ir jāiemācas un tikai tad var sākt izteikt pamatotus spriedumus par to. Un jārēķinās ar to, ka mācīšanās paņem kādu laiku un jūs nebūsiet produktīvi uzreiz pirmajā dienā (arī ja jūs sevi agrāk uzskatījāt par augstas klases programmētāju, tad tik un tā pirmajā dienā jūs būsiet TDD iesācējs). Un lai kaut ko iemācītos, vispirms to vajag darīt burtiski “kā grāmatā” un tikai pēc tam var sākt eksperimentēt un pielāgot (nevis sākt ar attieksmi, ka “mums tas neder”). Un attiecībā par TDD ir pieejamas gan labas grāmatas, gan arī labi demo “screencasts” (piemēram, kā to darīt Java vai Ruby gadījumā), kas palīdz iemācīties un saprast labākās TDD prakses.

Tad, kad es šādā veidā iemācījos TDD, tad es arī sāku daudz labāk pamanīt TDD ieguvumus:

  • Lai piegādātu kvalitatīvu strādājošu programmatūru, tad līdz šim vienīgais izgudrotais veids, kā par to pārliecināties, ir testēšana. Tādēļ “netestēšana” nekad nedrīkstētu būt kā alternatīva.
  • TDD gadījumā mazāk tiek veikta atkļūdošana (debugging). Tispiski programmētāji pavada daudz laika uz atkļūdošanu, bet pēc tam kad ir panākts, ka programmatūra strādā, tad viss atkļūdošanas laikā uzrakstītais pagaidu kods tiek “izmests miskastē”. TDD gadījumā šīs atkļūdošanas kods tiek saglabāts kā vienībtesti, kas tiek automātiski izpildīti arī nākotnē, lai pārliecinātos, ka vēlāk netiek atkārtota tā pati kļūda.
  • Mazāk laika tiek patērēts uz to, lai identificētu, kurā vietā ir kļūda. TDD daudz efektīvāk palīdz atklāt tās kļūdas, kuras rodas mazu izmaiņu blakusefektu gadījumā, kuri ar manuālo testēšanu netiek identificēti (jo neviens neiedomājas, ka tur varētu būt problēma), bet automātiskie vienībtesti, kas vienmēr tiek izpildīti visi, to var atklāt.
  • TDD var un vajag izmantot arī kļūdu labošanā – atklājot kādu jaunu kļūdu vispirms tiek uzrakstīts vienībtests, kas atkārto šo kļūdu un tikai pēc tam tiek labots kods, lai atrisinātu problēmu. Šī pieeja arī noder, lai sāktu izmantot TDD esošas programmatūras uzturēšanā un jaunu izmaiņu izstrādē – sākt rakstīt testus tām vietām, kur rodas kļūdas, vai kur tiek veiktas izmaiņas.
  • Iemācoties TDD jūs saprotiet, ka tā ir projektēšanas / dizaina aktivitāte, kurai automātiskie testi ir kā papildus ieguvums. Jūs vienmēr vispirms padomājat, kāds ir funkcijas vai metodes vai moduļa nolūks un kā jūs to izmantosiet un kā jūs to testēsiet pirms jūs sākat kodēšanu, kā rezultātā TDD uzlabos jūs koda dizainu un uzturamību.
  • TDD rezultātā jūs iegūsiet arī mazāku koda apjomu, kas dara tikai to, kas patlaban nepieciešams. Un jo mazāks ir koda apjoms, jo mazāk tur būs kļūdas un jo vieglāk to būs mainīt un papildināt.
  • TDD ļauj veikt pastāvīgu refaktorēšanu un programmētājiem nevajag prasīt atļauju veikt refaktorēšanu. Ja programmas kods pastāvīgi tiks mainīts un uzlabots, tad tas visu laiku būs gatavs izmaiņām un jūs nenonāksiet līdz situācijai, kad mazu izmaiņu veikšanai būs nepieciešams ieguldīt ļoti lielu darbu dēļ tā, ka refaktorēšana tika visu laiku atlikta.
  • TDD mērķis ir visu laiku uzturēt programmatūru bez zināmām kļūdām – ja visi testi izpildās veiksmīgi, tad mums nav zināmu kļūdu. Ja tiek konstatēta jauna kļūda, tad tā ir jāatrisina vispirms, pirms tiek veikta jaunas funkcionalitātes izstrāde.

Un visu šo ieguvumu rezultātā es esmu konstatējis, ka īstenībā TDD izstrāde (ja to iemācās darīt pareizi) ir ātrāka nekā tradicionālā daļēji automatizētā, daļēji manuālā testēšana pēc tam, kad programmatūra ir izstrādāta. Kā arī kopējais patērētais laiks, lai sasniegtu kvalitatīvu rezultātu, ir mazāks.

Protams, TDD nav sudraba lode un neaizstāj visus testēšanas veidus. TDD ir efektīvs, lai notestētu, ka uz noteiktiem ievaddatiem un precīzi definēti rezultāti. Bet attiecībā uz lietotāju interfeisu ir svarīgi, vai lietotāja interfeiss labi izskatās, vai ir pareizās proporcijas un krāsu palete, vai tas ir pietiekoši vienkāršs un saprotams no lietojamības viedokļa. Uz šo aspektu testēšanu vajag izmantot cilvēkus ar atbilstošām lietojamības kritēriju testēšanas iemaņām. Bet nevajag izmantot cilvēkus kā testēšanas robotus, kas caur lietotāju interfeisu mēģina notestēt to, ko daudz efektīvāk var izdarīt ar vienībtestiem vai integrācijas testiem atbilstošā zemākā līmenī.

Programmētājiem nepatīk manuālā testēšana un “čeklistu” aizpildīšana, programmētājiem patīk kodēt. Tādēļ arī vajag palīdzēt programmētājiem iemācīt, ka testēšana ar kodēšanas palīdzību ir tikpat interesanta, kā cita veida kodēšana 🙂


Drīzumā Latvijas Oracle User Group otrā konference

11.04.2010

lvoug.jpg

15. aprīlī notiks jau otrā Latvian Oracle User Group konference. Pagājušogad pasākums bija labi apmeklēts un arī tēmas bija interesantas un arī šogad pasākums izskatās, ka būs interesants. Tāpat kā pagājušajā gadā notiks divas paralēlās sesijas, kur viena ir vairāk orientēta uz DBA, savukārt otra vairāk uz lietojumprogrammatūras izstrādi ar Oracle tehnoloģijām.

Arī šogad es uzstāšos šajā pasākumā un šoreiz prezentācijas tēma būs “PL/SQL vienībtestēšana ar Ruby”. Gaidu visus interesentus, kuri vēlas uzzināt vairāk par testu virzītu izstrādi un kā to darīt PL/SQL izstrādē ar nelielu Ruby maģijas palīdzību 🙂 Iepazīties vairāk par šo tēmu variet arī manā angliskajā blogā, kā arī noskatīties demonstrāciju (to “dzīvajā” rādīšu arī LVOUG konferencē). Un vēl “iekārdināšanai” varu pateikt, ka šī prezentācija tika akceptēta arī Somijas, Krievijas, Igaunijas un Latvijas EMEA Harmony Oracle User Groups konferencē, kas notiks 20. un 21. maijā Tallinā (no Latvijas tika akceptēta šī prezentācija, kā arī mana kolēģa Māra Elsiņa prezentācija).

LVOUG konference ir bezmaksas un reģistrēties variet šeit.

Papildinājums. Šie ir manas prezentācijas slaidi:


Tuvojas Latvijas Oracle User Group pirmā konference

01.03.2009

lvoug.jpg
27. martā notiks pirmā Latvian Oracle User Group konference. Atšķirībā no Oracle dienas, šis ir Oracle lietotāju un profesionāļu organizēts pasākums, kurā Oracle “spečuki” var atklāti apmainīties gan ar pozitīvu, gan negatīvu pieredzi un viedokļiem par Oracle tehnoloģijām un to praktisku pielietošanu.

Līdzīgi kā Oracle dienās, esmu pieteicies ar prezentāciju arī šajā konferencē un stāstīšu par to, kā man sokas ar Ruby on Rails Oracle adaptera veidošanu. Citas prezentācijas pamatā būs par Oracle datubāzes izmantošanu un tās “advancētajām fīčām”. Kā viesis piedalīsies arī Kuassi Mensah, ar kuru esmu iepriekš ticies Oracle OpenWorld konferencē – viņu starp citu arī interesēja manas aktivitātes Ruby on Rails un Oracle “sadraudzināšanas” jomā.

Tā ka visi Oracle tehnoloģiju interesenti ir gaidīti 27. martā uz šo pasākumu – pasākums ir bezmaksas un reģistrēties var šeit.


Kā sagatavot labu [BarCamp] prezentāciju

09.02.2009

Pagājušajā nedēļas nogalē piedalījos BarCamp Baltics 2009 ne-konferencē (tikai pirmajā dienā) un kopumā jāsaka, ka no organizācijas viedokļa viss bija ļoti labi – liels paldies organizatoru komandai par ieguldīto darbu!

barcamp_schedule.jpg

Toties no BarCamp apmeklētāju viedokļa gribētos, ka tie būtu sagatavojušies mazliet labāk. Viens no BarCamp noteikumiem ir, ka ja Tu nāc uz BarCamp, tad arī vajag tur aktīvi piedalīties – vislabāk ar savu prezentāciju, vai arī vismaz iesaistoties diskusijās. Uz pasākumu bija ieradušies vairāk nekā 500 dalībnieku, bet pieejamais prezentāciju grafiks tā arī netika pilnībā aizpildīts – uz prezentāciju sākumu bija pieteikušies ap 35 prezentētāji, kas līdz pasākuma beigām palielinājās par vēl kādiem 10.

Tā rezultātā dažos grafika intervālos ar tēmu piedāvājumu bija pašvaki. Kā arī dažas no apmeklētajām prezentācijām īpaši neaizkustināja. Tā kā pašam ikdienā nākas ļoti bieži nodarboties ar prezentēšanu, tad gribēju padalīties ar ieteikumiem, kā sagatavot labu un interesantu prezentāciju, lai nākamajā BarCamp prezentēt gribētāju būtu stipri vairāk 🙂

  • Izdomājiet, kas ir tas vēstījums (“message”), ko gribat citiem pavēstīt.
    Ja jūs kaut ko stāstīsiet, bet nebūs skaidrs, kādēļ jūs to citiem gribat pastāstīt, tad citiem tas nebūs interesanti.
  • Sagatavojieties prezentācijai un to iepriekš izmēģiniet
    Ja jūs kādu tēmu esat stāstījuši jau daudzas reizes, tad varbūt vēl vienu reizi jūs to varat pastāstīt bez gatavošanās. Bet ja tā ir pirmā reize un ikdienā nesanāk nodarboties ar prezentēšanu, tad noteikti vajag prezentāciju izmēģināt – kaut vai mājās spoguļa priekšā.
  • Runājiet par tēmu kaislīgi un nebaidities izteikt savu viedokli par to
    Diskusija izvērtīsies tad, ja būs skaidrs prezentētāja viedoklis par kādu tēmu. Ja tikai izklāstīs vispārzināmus faktus, tad diskusijai nebūs pamata.
  • Sagatavojiet vizuāli pievilcīgus slaidus
    Tas mani mazliet izbrīnija, redzot, ka jauno mēdiju entuziasti, lieto pagājušā gadsimta stilā veidotus “bullet-point” prezentācijas slaidus. Slaidi nav paredzēti lasīšanai – vārdi būs daudz iedarbīgāki, ja tos pateiks pareizajā intonācijā. Slaidi ir paredzēti, lai vizuālā veidā paspilgtinātu jūsu teikto. Tādēļ nepaslinkojiet un pameklējiet Googlē atbilstošas vizuālas bildes, lai ilustrētu jūsu stāstījumu, vai arī uzzīmējiet kādu vizuālu shēmu, kas palīdzēs uztvert stāstījumu.
    Un vēl – ja izmantojiet agrākas prezentācijas slaidus, tad pārskatiet, vai šajā reizē tiešām visi slaidi tiks izmantoti, vai nevajag kaut ko pamainīt šīs auditorijas specifikai.
  • Iemārketējiet savu prezentāciju pareizajai mērķauditorijai
    Sākot no tādas triviālas lietas, ka prezentācijas nosaukumu uzrakstiet tādā valodā, kādā to stāstīsiet (lai nepiečakarētu vāciešus, kas atnāk uz prezentāciju ar virsrakstu angliski, bet konstatē, ka prezentācija notiks krieviski). Ja rakstiet tēmas nosaukumu ar roku, tad rakstiet to ar lieliem, saprotamiem burtiem – ne visi var saprast jūsu mikroskopisko rokrakstu. Un centieties, lai virsrakstā būtu iekļauts jūsu prezentācijas esence.
  • Nepārtērējiet laiku un atstājiet vietu diskusijai
    Jo atgriezeniskā saite no auditorijas taču ir galvenais – ja neinteresē, kāds ir auditorijas viedoklis, tad var arī vienkārši palikt pie prezentēšanas spoguļa priekšā 🙂
  • Nepārcentieties ar sava ego slavināšanu
    Ja prezentācijas laikā tikai slavināsiet sevi, cik jūs kruti kaut ko esat izdarījuši, tad tas visticamāk radīs negatīvu vai labākajā gadījumā vienaldzīgu reakciju no auditorijas. Ja jūs taisat prezentāciju auditorijai, tad primāri domājat, ko jūs varat tai dot, nevis sagaidiet uzslavas no tās.

Pats centos pieturēties pie šiem principiem un spriežot pēc auditorijas jautājumiem un atsauksmēm mana prezentācija “Why I love Ruby on Rails” sanāca tīri laba 🙂 Ievietoju arī savus slaidus, ko lietoju:

Ja kādam ir vēl kādas rekomendācijas, ka veidot labas prezentācijas, tad labprāt uzklausīšu komentāros.


Open-source domāšana

13.12.2008

opensource.jpgPēdējā laikā daudzi ir sākuši runāt par open-source jeb atvērtā koda programmatūru, kur skaļākā diskusija bija par to, vai valsts iestādēs vajadzētu Microsoft Office vietā izmantot OpenOffice.org. Bieži šajās diskusijās open-source termins tiek reducēts uz to, ka tā ir programmatūra par brīvu, vai arī vismaz stipri lētāk nekā Microsoft (jo par atbalstu tāpat kādam būs jāmaksā).

Arī nesen notikušajā LATA konferencē daudzās diskusijās klausītāji uzdeva jautājumus par to, kad tā un tā programmatūra nodrošinās to un to “fīču” un kāpēc nav realizēta tā un tā funkcionalitāte, jo tas taču ir tik svarīgi. Un varbūt kādam var mazliet samaksāt, lai uztaisītu to “mums ļoti svarīgo funkcionalitāti”. Izskatījās, ka liela daļa dalībnieku bija atnākuši ar attieksmi “ko man tā atvērtā koda programmatūra tādu īpašu var dot?”.

Problēma ir tāda, ka viņi nav sapratuši open-source būtību – tas nav “lēts Microsoft”, tās vairs nav klasiskās piegādātāja un klienta attiecības, kur klients samaksā “piķi” piegādātājam un pēc tam par jebkuru problēmu var sūdzēties piegādātājam.

Open-source ir kolektīva programmatūras radīšana un savstarpējā sadarbība, kur katrs dod ieguldījumu atbilstoši savām spējām – vieni var programmēt, citi var testēt, citi var dokumentēt, citi pieredzējušie lietotāji var palīdzēt ar padomu jaunajiem lietotājiem.

Ja kāds liels uzņēmums vai valsts iestāde ir izvēlējusies atvērtā koda programmatūru, tad tā vietā lai meklētu, kurš uzņēmums tagad būs atbildīgs par visām problēmām ar šo programmatūru, vajag drīzāk ļaut saviem darbiniekiem iesaistīties šajā open-source projektā atbilstoši viņu spējām. Ja ir nepieciešama kāda jauna funkcionalitāte, kas pagaidām nav pieejama, tad vajag mēģināt pašiem to arī uztaisīt (un iespējams, ka citur pasaulē atradīsies arī citi, kas palīdzēs ar tās realizāciju). Ja ir atrasta kāda kļūda, tad pašiem arī jāmēģina arī uztaisīt šīs problēmas risinājumu, vai vismaz pietiekoši precīzi jāapraksta, kā šo problēmu var atkārtot. Ja programmatūra nav latviskota, tad pašiem arī vajag ķerties pie latviskošanas (kur parasti nav nepieciešamas īpašas programmēšanas zināšanas). Un protams, ja ir kāda lieka naudiņa, tad var arī finansiāli atbalstīt citus aktīvākos šī open-source projekta attīstītājus.

Šādā veidā arī var piesaistīt organizācijai spējīgākus IT darbiniekus, jo spējīgākajiem darbiniekiem būs stipri interesantāk pašiem iesaistīties open-source projekta attīstībā, nevis tikai būt par problēmziņojumu transportētājiem starp lietotājiem un aizjūras piegādātāju.

Un tā kā šībrīža situācijā ir moderni visos rakstos piesaukt ekonomisko krīzi, tad šajā sakarā var teikt, ka iesaistīšanās open-source projektos ir ļoti labs veids, kā samazināt importu un palielināt pievienotās vērtības radīšanu tepat uz vietas 🙂


e-latvenergo – viens no trīs labākajiem e-pakalpojumu projektiem

22.11.2008

Vakardien notika LIKTA (Latvijas informācijas un komunikāciju tehnoloģiju asociācija) 10. konference, kurā otro reizi tika pasniegtas “Platīna peles” balvas.

e-latvenergo.png

Bija patīkami, ka par vienu no trijiem labākajiem ePārvaldes un e-pakalpojumu projektiem tika atzīts Latvenergo klientu portāls e-latvenergo un man bija tas gods saņemt “atzinības rakstu” kā šīs sistēmas izstrādātāju pārstāvim. Platīna peli kā pats labākais projekts saņēma “Swedbankas ceturtās paaudzes internetbanka privātpersonām” – droši vien žūrija ņēma vērā ilggadējos hanza.net panākumus nevis tikai šogad veikto web dizaina maiņu. Trešais no labākajiem projektiem bija “Trešais tēva dēls”.

e-latvenergo patlabam ir arī lielākā web aplikācija Latvijā, kas izstrādāta ar Ruby on Rails, un man kā Ruby fanam un popularizētājam un prieks, ka izdevies ar to izveidot projektu, kas ieguvis šādu atzinību. Varētu teikt, ka arī e-latvenergo ir 4. paaudzes, jo pateicoties Ruby on Rails ātrajai izstrādes pieejai mēs šī gada laikā esam izstrādājuši vismaz četras jaunas sistēmas relīzes.

Vēl interesanti, ka e-latvenergo projekts aktīvi sadarbojas arī ar pārējiem laureātiem – e-latvenergo iespējams autentificēties un veikt maksājumus ar Swedbankas internetbanku, kā arī sadarbībā ar Trešā tēva dēla projektu tika apmācīti bibliotekāri, lai viņi savukārt varētu apmācīt publisko bibliotēku interneta piekļuves vietu apmeklētājus darbam ar e-latvenergo.

Platīna peli Izglītības, kultūras, veselības aprūpes un sporta projektu kategorijā ieguva “Pasaku portāls www.pasakas.net”. Līdz šim par tādu projektu nebiju dzirdējis, bet tagad radās interese to parādīt saviem bērniem – tas izskatās varētu būt noderīgāks datorlaika izmantošanas veids, nekā spēlēt spēlītes 🙂


Uzstājos BibCamp 2

07.11.2008

Tā kā mūsu kompānija bija viens no galvenajiem organizatoriem BibCamp 2 “nekonferencei bibliotekāriem”, tad organizētāji palūdza mani piedalīties un kaut ko noprezentēt. Tā kā runāt par man tuvām lietām man patīk :), tad es pieteicos uz veselām trīs prezentācijām.

Tālāk redzami slaidi no manām prezentācijām:

Web 2.0

Web lietojamība

Spējā jeb Agile pieeja

Galvenais “izaicinājums” bija noprezentēt šīs tehnoloģiskās tēmas pēc iespējas ne-tehnoloģiskākā veidā. Kopumā izdevās samērā veiksmīgi, jo auditorijai bija daudz jautājumu. Vislielākā interese bija par web lietojamību, jo šīs idejas var izmantot jebkuršs arī vienkāršu web lapu veidošanā.

Kopumā iespaids par BibCamp palika labs un noteikti rekomendēju arī citās jomās sākt organizēt šāda veida “nekonferences”. Par citiem BibCamp 2 iespaidiem var izlasīt Jāņa un Kristapa blogos.