Microsoft Eneta

Tere,

Kuna on küpsemas plaan teha praegu käimasolevate loengusarjade sees ettekanne testipõhise arenduse (TDD) teemal, siis oleks vahva saada infot võimalikelt huvilistelt kästilemist väärivate teemade kohta, et lühike ajaraam mõistlikult kasutatud saaks.

Kas oleksite huvitatud teooria- ja ideeselgitustest/aruteludest või rohkem praktilisest maadlemisest konkreetse ülesande kallal konkreetses koodis?

Ja keerukuslikus plaanis - kas eelistaksite pigem sissejuhatavat ülevaadet kogu teemasse või ootaksite arutelu mõnel konkreetsel TDD probleemil või valdkonnal, mis praktikas muret teeb.

Andke aga teada, muidu on oht kas joosta elementaarsete käibetõdedega mürtsuga lahtisest uksest sisse või vastupidi, ehmatada või tüüdata kuulajaid arusaamatute aruteludega :)

Mulle kui algajale pakuks huvi praktiline sissejuhatav pool. Päris kuiva teooriat ei tahaks :)

Minu kogemus räägib, et ettekannetele tuleb meil enamasti nii neid, kes juba väga hästi oskavad kui ka neid, kes ühe või teise teemaga varem kokku pole puutunud. Selles mõttes ehk tasuks mõelda nii, et saab kõik oluline selgitatud ja näidatud ning kindlasti peaks midagi olema ka oskajate jaoks põnevat.

Mind ennast isiklikult huvitaks selline level 300/400 tasemel esitlus, kuid veelkord - ärme unusta neid, kellele teema võib uus olla. :)

Mu väike nägemus, kuidas võiks kogu seda teemat õpetada:

1. Komponenditestid (unit tests) - see peaks ära katma, kuidas alustada ja peamised printsiibid, et korralikud testid tuleksid.

2. Komponeditestide mustrid - kuidas hoiduda suurtest haldusprobleemidest, sest testide koodi on tihti rohkem kui toote oma.

3. Isoleerimine (mocks, stubs) - kuidas isoleerida testitavat objekti; kuidas mock/stub-e käsitsi teha; millised raamistikud on olemas ja kuidas neid kasutada.

4. Testitav kood ja disain - kuidas kirjutada koodi, et seda oleks võimalik ka testida. Peamiselt objekt-orienteeritud printsiibid.

5. Test Driven Development/Design, Behavior Driven Development - see võiks eelkõige olla demona, sest nii tabab selle tsükli kõige lihtsamini ära. Kuna TDD on peamiselt disiplineeriv praktika, siis oleks kasulik eelnevatest punktidest teadlik olla, sest raske on omandada koheselt TDD.

6. Ruby ja .NET - kuidas kasutada Ruby raamistikke efektiivselt .NET koodi testimiseks (Cucumber) ja millised alternatiivid on .NET maailmas. See oleks mulle endale kõige huvitavam teema.

Kuna see teema üldiselt on küllaltki suur, siis iga punkti juures võiks olla lühike ettekanne ja seejärel väike praktika, et inimesed saaksid koheselt järjele ja proovida ja ka kinnitada teadmisi. Muidugi see eeldaks juba päevast üritust.

... iga punkti juures võiks olla lühike ettekanne ja seejärel väike praktika, et inimesed saaksid koheselt järjele ja proovida ja ka kinnitada teadmisi. Muidugi see eeldaks juba päevast üritust.

Ma arvan, et kuulajate osas ei oleks probleemi. Kui keegi hea inimene sellise kava kokku suudab panna koos korraliku näidete ja do-it-by-yourself ülesannetega ning selle asja ka läbi viia, siis oleks tegemist igati tervitatava nähtusega. Enne soovitan vähemasti ühe pooleteise tunnise ettekande ära teha - see on hea õppetund endale, mida 1.5h tantsu ja tralli vaimule ja füüsisele tähendab.

Päevaste ürituste peale olen ise ka mõelnud. Mina suudaks katta MVC, Office, SharePoint ja .NET jõudluse teemad ära. Kindlasti leiaks midagi veel. Samas oleks neid üritusi vaja alustuseks nii palju, et saaks kohe kindel korrapära sisse, et need toimuksid perioodiliselt ja et teemad oleksid huvitavad. Testimine on vaieldamatult asi, mille kohta võiks kasvõi mitu päevast praksi teha :) 

 1,5h tundi ettekande jaoks on liiga palju. 0,5h pikkused ettekanded oleksid palju paremad, siis ei hakka inimesed ka enda rüpperaale kotist välja võtma.

Tüüpilise müügiesitluse ja niisama ekraanpaukude näitamisel on see nii. Aga kui on demod ka, siis pool tundi tähendab seda, et demod tuleb teha väga kiiresti ja see muudab nad igavaks - inimesed ei jõua lihtsalt järgi, sest nemad näevad seda kõike esimest korda. Kui tegemist on asjadega, mida audients ise pole kuigi palju torkinud, siis seda enam on vaja tempot, mis jätab neile süvenemiseks mingisugusegi aja. Selles valguses on 1.5h täiesti paras aeg.

Tegelikult oleme seni jaganud aega selliselt, et 1:15 oleks ettekandele ja 15 min küsimustele. Samas - vähemasti minu jaoks - pole olnud ka selles probleemi kui keegi vahele mõne täpsustava küsimuse küsib või kui demode juures midagi ebaselget selgitada palub.

Seega kui on demoda midagi pole, siis 45 minutit on tõesti tagumine aeg, millele veel haigutamata vastu peab. Kui on demod ka, siis peab juba ise kella vaatama, et ajalistesse raamidesse jääda. Seda enam, kui vahele küsimusi ka küsitakse.

Iga ettekandega müüd mingit ideed. Võib-olla ei peagi nii palju demoma, vaid hoopis tekitama suurt huvi inimestes teema vastu ning hiljem uurivad ise edasi. Koolipingistki tuleb meelde, et huvitavamad loengud ja tunnid oli need, kus ei surutud kulbiga tarkust pähe, vaid räägiti lugu või tekitati lihtsalt huvi aine vastu. 

Lisaks on alati võimalik teha praktikum või töötuba ettekandele järgi, et soovijad saaksid teemakohaseid katseid ja eksperimente teha.

Seni toimunut vaadates ei ole ühtegi sellist teemat olnud, mida ilma demodeta teha oleks mõtet. Kindlasti, kui on teema, mille juures konkreetsed tehnilised vahendid ei oma tähtsust, ei ole ka demomist vaja. Selge on see, et kui tegemist on ettekandega, mille jaoks inimesed varuvad omale aega, et kuhugi tulla ja sõita ja midagi teada saada, siis pelgalt 30 minutine etteaste ei pruugi seda vaeva üles kaaluda. Seega siis pigem 30+30 ettekanded ja nagu koolist harjunud, siis vahetund või suitsupaus vahele. :)