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 🙂

Advertisements

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:


Oracle Magazine’s Developer of the Year

19.10.2009

Pēdējos gadus esmu veltījis diezgan daudz laika Ruby on Rails un Oracle integrācijā – tā kā no Oracle puses Ruby netiek īpaši atbalstīts, tad nākas to darīt pašam. Un tā kā Ruby programmētāju kopienā ir izteikta open-source kultūra, tad, protams, arī savu Ruby on Rails Oracle adapteri publicēju kā open-source projektu, kā arī palīdzēju citiem Oracle un Ruby lietotājiem ar padomiem un problēmu risinājumiem.

Biju patīkami pārsteigts, ka mani Oracle paziņas ir novērtējuši šīs aktivitātes un nominēja mani ikgadējajai Oracle Magazine balvai, kas tiek piešķirta dažādās kategorijās. Un tā rezultātā šogad esmu kļuvis par Oracle Magazine’s Developer of the Year 🙂

Zemāk var redzēt arī manu bildi un īstu aprakstu no Oracle Magazine pēdējā numura:

DOTY_450.png

Rekomendācijas programmētāju kvalifikācijas darbiem

14.06.2009

Šajā nedēļā piedalījos Latvijas Universitātes Datorikas fakultātes programmētāju kvalifikācijas darbu vērtēšanas komisijā – gan recenzēju daudzus darbus, gan arī klausījos un vērtēju klātienē vēl vairāk darbus. Kā jau katru gadu man nepatika vairākas tendences, kas bija sastopamas daudzos darbos, tādēļ gribēju šeit izkratīt sirdi un padalīties ar rekomendācijām, kā vajadzētu labāk rakstīt šos darbus, lai saņemtu labu vērtējumu no manis kā potenciālā vērtētāja 🙂

Strādājošs, kvalitatīvs un uzturams programmatūras kods ir primārais mērķis

Kā vienu no pirmajām lietām gribēju uzsvērt šo Agile principu, jo programmēšanas kvalifikācijas darbos galvenais mērķis ir parādīt, ka autors spēj radīt kvalitatīvu programmatūru. Tādēļ:

  • Strukturējiet programmatūru saprotamos funkcionālajos moduļos.
  • Sadaliet katru moduli nelielās funkcijās vai metodēs – nekādā ziņā viena funkcija vai metode nedrīkst būt pa daudzām lappusēm. Jo tās būs īsākas un saprotamākas, jo labāk.
  • Komentāros rakstiet, kāpēc jūs kaut ko dariet, nevis vēlreiz atkārtojiet to, kas redzams kodā.
  • Sadaliet biznesa loģiku un attēlošanas loģiku dažādos moduļos (sliktākie piemēri bija, kad vienā failā ir gan PHP, gan SQL, gan HTML, gan Javascript kods sajaukts vienā lielā putrā).
  • DRY (Don’t Repeat Yourself) princips – ja kāds kods bieži tiek ar copy-paste dublēts, tad tas nozīmēt, ka šo loģiku vajag izdalīt kādā kopējā funkcijā vai metodē, lai izvairītos no koda dublēšanas.

Vienkārša, saprotama un vajadzīga dokumentācija

Daudzos darbos sliktu kodu centās kompensēt ar lieliem dokumentācijas blāķiem, kas manā vērtējumā darbu var tikai pasliktināt.

  • Labāk dokumentāciju rakstiet īsāku un saprotamāku, nevis garu un nesaprotamu.
  • Izvairieties no triviālu lietu skaidrošanas un liekvārdības, bet neaizmirstiet paskaidrot lietas, kas ir specifiskas jūsu darbam.
  • Arī dokumentācijai ir jābūt DRY – nekopējiet vienus un tos pašus aprakstus uz dažādām dokumentācijas vietām.
  • Nemāniet lasītāju, ka vispirms uzrakstījāt visu prasību specifikāciju dokumentu, pēc tam projektējuma aprakstu un tikai tad kodējāt. Ūdenskrituma metode nav vienīgā pieeja – tā ir novecojusi un mūsdienās parasti nepiemērota pieeja. Droši izmantojiet un aprakstiet iteratīvās / inkrementālās / spējās izstrādes pieejas, ja tas ir patiesais veids, kā esat veidojuši savu darbu.

Testējiet ar kodu nevis ar dokumentāciju

Daudziem liekas, ka labākais veids, kā pārliecināt lasītāju, ka viņi ir dikti labi testējuši, ir saproducēt lielu testēšanas dokumentāciju. Bet, manuprāt, liela un sarežģīta testēšanas dokumentācija apliecina tikai to, ka šie testi netika bieži izpildīti.

  • Ļoti rekomendēju apgūt jūsu izvēlētās programmēšanas valodas atbilstošo automatīzēto vienībtestēšanas ietvaru. Automatizēti un regulāri izpildīti vienībtesti vienmēr būs labāki nekā gari un manuāli izpildāmi testi.
  • Primāri testējiet jūsu darba svarīgāko un potenciāli riskantāko funkcionalitāti, nevis rakstiet daudzus vienkāršus (piemēram, lauku obligātuma pārbaudes) testus.

Drošība

  • “Paroļu šifrēšana” nav vienīgā drošības problēma un/vai prasība.
  • Ja jūsu programmā ir dažādi lietotāji ar dažādām tiesībām, tad pieejas tiesības ir vienas no primārajām drošības prasībām, kas arī ir jātestē.
  • Pirms veidojiet “web” bāzētu sistēmu, iepazīstieties ar biežākajām drošības problēmām “web” bāzētajās sistēmās – sāciet ar SQL injekcijas problēmām.

Konfigurāciju pārvaldība

  • Mūsdienās veikt programmatūras koda pārvaldību tikai ar failu rezerves kopēšanas palīdzību profesionālam programmētājam vairs nebūtu pieļaujams.
  • Apgūstiet un lietojiet atbilstošus versiju kontroles rīkus, piemēram, Subversion, Git vai citus. Versiju kontroles rīki ir vieni no programmētāju pamatrīkiem.

Darbietilpības novērtēšana

  • Darbietilpības novērtēšana ir paredzēta, lai prognozētu potenciālo darbietilpību pirms jūs esat sākuši programmēt sistēmu. Darbietilpības novērtēšana nav paredzēta, lai pamatotu komisijai, ka jūs tiešām esat veltījuši 3 mēnešus darba izstrādei.
  • Neizmantojiet sarežģītas COCOMO novērtēšanas metodes, ja jums nav skaidrs, ko tās prognozē un ja jums rezultāti sanāk pavisam savādāki nekā faktiski patērētais darbs. Un netaisnojieties ar to, ka “COCOMO paredzēts lieliem projektiem” – lielie projekti nav nekas tāds briesmīgs, kuros pēkšņi visas vienkāršās lietas ir jātaisa piecreiz sarežģītāk.
  • Ja jūs izmantojat iteratīvo / spējo (Agile) pieeju pieeju, tad izmantojiet atbilstošas spējās novērtēšanas tehnikas.

Ceru, ka šīs manas rekomendācijas studenti nākamreiz “uzgooglēs” un ņems tās vērā kvalifikācijas darba izstrādē 🙂


Podkāsti programmētājiem

31.10.2008

Tā kā ikdienā es daudz laika pavadu automašīnā, tad es cenšos efektīvi izmantot arī šo laiku. Pēdējā laikā visvairāk automašīnā es klausos dažādus podkāstus un tādēļ gribēju padalīties ar informāciju par tiem, kas man liekas interesanti un vērtīgi.

Tā kā strādāju programmatūras izstrādes biznesā, tad lielu daļu sastāda tieši “podkāsti programmētājiem”:

Ruby on Rails podcastrails_podcast.png

Tā kā Ruby ir viena no manām mīļākajām programmēšanas valodām, tad sākšu ar šo. Šo podkāstu veido Geoffrey Grosenbach un tajā pamatā ir intervijas ar dažādiem Rubyistiem. Geoffrey vēl ir slavens ar to, ka viņš veido PeepCode screencasts, kuri ir ļoti noderīgi Ruby on Rails apgūšanai.

Rails Envyrails_envy.png

Šis ir regulārs iknedēļas podkāsts par Ruby un Rails jaunumiem, kuru veido Gregg Pollack un Jason Seifer. Jaunumi tiek pasniegti interesantā veidā ar nelielu (vai dažreiz lielu) humora devu. Popularitāti Ruby kopienā viņi ieguva ar savām Ruby on Rails video “reklāmām”.

Rubyology

Šis ir vēl viens Ruby podkāsts, ko veido Chris Matthieu, kur pēdējā laikā pamatā arī ir intervijas ar citiem Rubyistiem. Šim podkāstam joprojām pieklibo audio kvalitāti, kā rezultātā to ir grūti klausīties ejot pa ielu.

Pragmatic Programmerspragprog.png

Esmu lasījis daudz Pragmatic Programmers grāmatas, tādēļ arī klausos viņu podkāstu, kur ir intervijas ar jauno grāmatu autoriem.

FLOSS Weeklyfloss.png

Šo podkāstu veido Randal Schwartz un Leo Laporte (kurš veido arī ļoti daudz citus podkāstus) un kurš pedējā laikā tiešām ir iknedēļas podkāsts, kurā ir intervijas ar dažādu atvērtā koda jeb opensource projektu veidotājiem.

Stack Overflowstackoverflow.png

Šo podkāstu veido Jeff Atwood un Joel Spolsky, kas ir plaši pazīstami ar savām iepriekšējām blogošanas un citām publiskajām aktivitātēm. Šajā podkāstā viņi runā gan par kopējo Stack Overflow projektu, gan arī par daudzām citām interesantām programmatūras izstrādes lietām.

HanselminutesHanselminutes.png

Šis podkāsts pamatā ir par Microsoft .NET tehnoloģijām, ko veido Scott Hanselman, kas pats nesen ir sācis strādāt Microsoftā. Bet daudzas epizodes skar plašākas web izstrādes tēmas, tādēļ ir interesanti paklausīties arī tiem, kas nepārzin .NET tehnoloģijas.

Alt.NETaltnet.png

Šis ir vēl viens podkāsts par .NET tehnoloģijām, bet to veido Alt.NET grupas entuziasti, kam bieži vien ir savādāks viedoklis nekā Microsoftam. Vairākas epizodes ir par Ruby, JavaScript un Agile tēmām, kas mani interesē.

Agile Toolkitagiletoolkit.jpg

Šajā podkāstā pamatā ir intervijas ar Agile Software Development teorētiķeim un praktiķiem. Pēdējā laikā jaunas epizodes iznāk reti, bet arhīvos ir pieejamas ļoti daudzas interesantas intervijas.

SPaMCAST

Pilnā vārdā tas ir Software Process and Measurement Cast. Atbilstoši savam nosaukumam liela daļa no podkāsta tiešām ir spams, bet arhīvā var atrast pāris labas intervijas ar Agile klasiķiem – Mike Cohn, Ken Schwaber, Scott Ambler, Kent Beck, Johanna Rothman, Mary Poppendieck.

Technometria

Šo podkāstu veido Phil Windley, kas ir gan profesors, gan viens no IT Conversations producentiem. Šajā personīgajā podkāstā viņš regulāri ar saviem paziņām pārrunā programmatūras izstrādes un IT aktualitātes.

Vai kādam ir vēl kādas labas rekomendācijas par podkāstiem programmētājiem? Labprāt dzirdēšu komentāros.


Ruby muļķu konference Kopenhāgenā

26.01.2008

ruby_fools.jpg

Neesat muļķis, esat Ruby muļķis 🙂 Šāda devīze ir Ruby Fools konferencei, kas notiek 1. un 2. aprīlī Kopenhāgenā un kura pamatā ir orientēta uz Ruby un Rails iesācējiem.

Tā ka ja kādam ir vēlme ātri “iebraukt” Ruby un Rails pasaulē, tad šī konference varētu labi noderēt un nokļūšana uz Kopenhāgenu ir gana vienkārša. Pats uz šo konferenci gan neplānoju doties, jo plānos ir īstās RailsConf konferences.


Scratch – “objektorientētā” programmēšana bērniem

10.11.2007

scratch.pngNesen pamanīju ļoti interesantu projektu Scratch – vienkāršu, bet vienlaicīgi arī ļoti “spēcīgu” vizuālas programmēšanas vidi, kas pamatā orientēta uz programmēšanas mācīšanu bērniem. Ar Scratch palīdzību var viedot animācijas, spēles, audiovizuālus mākslas darbus un tamlīdzīgus brīnumus.

Šodien ar savu puiku izmēģinājām kopīgi uztaisīt pirmo Scratch projektu un interese bija gan man, gan arī puikam 🙂 Jebkuru Scratch projektu var arī vienkārši “nošārēt” Scratch web lapā.

Man kā programmēšanas valodu entuziastam likās interesanti, ka Scratch ir izteikti objektorientēta valoda – uz ekrāna izvietotie ķinķēziņi katrs ir objekts ar saviem atribūtiem (atrašanās vieta, virziens, izskats, …) un katram mēs varam vizuāli uzprogrammēt dažāduss skriptus (jeb metodes), kas tiek izpildītas dažādu notikumu gadījumā (nospiesta sākuma poga, saņemts ziņojums, nospiests kāds taustiņš vai kaut kas darīts ar peli, …).

Ja es salīdzinu ar sevi, kā es apguvu programmēšanas valodas, tad tas notika pilnīgi savādāk – vispirms apguvu procedurālo programmēšanu Basicā, C un citās procedurālās valodās, un tikai universitātē sāku apgūt objektorientēto programmēšanu. Bet te Scratchā uzreiz viss ir dabīgi objektorientēts un bērni to uztver ļoti dabīgi. Vēlāk šiem bērniem droši vien būs grūtāk saprast parasto procedurālo programmēšanu 🙂

Likās interesanti arī tas, ka Scratch ir veidots ar programmēšanas valodas Squeek palīdzību, kas savukārt ir objektorientēto valodu vecmāmiņas Smalltalk viena no implementācijām. Tā ka Scratch objektorientētība ir dziļi “iedzimta” no tā senčiem.

Rekomendēju visiem vecākiem, kam ir vēlme paprogrammēt kopā ar bērniem 🙂