…meie igapäevast IT’d anna meile igapäev…

2008-06-20

Ekstreemprogrammeerimine: head, vead ja inetused. Teine osa

Filed under: Infotehnoloogia — Sander @ 09:46:00

Kui eelmisel korral kirjutasin väledatest metoodikatest üldiselt, siis seekord üritan kirjutada agile development’i kõige rohkem tuntud ja promotud metoodikast: ekstreemprogrammeerimisest.

Mis see ekstreemprogrammeerimine on?

Kui üheksakümnendatel hakati rohkem rääkima väledatest metoodikatest, siis hakkas erinevaid alammetoodikaid tekkima nagu seeni pärast vihma (tõsi küll, mõned neist olid olemas juba enne agile development’ile nime panemist, osad on tulenenud juhtimismetoodikatest, osad (RUP) segavad waterfall ja agile metoodikaid). Rational Unified Process (RUP), Dynamic Systems Development Method (DSDM), Scrum, Test-Driven Development (TDD), Crystal Clear, Feature Driven Development (FDD) jpt. Kuid ükski ei saanud neist nii tuntuks kui extreme programming (XP) – mul on kuri kahtlus, et selle põhjuseks on eelkõige ekstreemprogrammeerimise cool nimi ja suured lubadused.

Alguse sai XP 1995. aastal, kui Ken Beck hakkas juhtima projekti Chrysler Comprehensive Compensation System (C3) – üldist palga maksmise süsteemi hiidkorporatsioonile Chrysler. 1997. aastal mindi üle metodoloogiale, mida tuntakse nüüd extreme programming nime all.

Mille XP-promojad reeglina rääkimata jätavad, on asjaolu et C3 oli totaalne läbikukkumine, nii rakendusena kui ka arenduse suhtes. Alguses võttis igakuine kümne tuhande inimese palga arvutamine 1000 tundi (!!!), pärast kolme kuud optimeerimist saadi see 12 tunni peale. Projekt pidi algselt lõppema 1997. aasta teises pooles, kuid see venis kuni 2000. aastani, mil Daimler-Benz Chrysleri ära ostis ja C3 arenduse lihtsalt seisma pani. Seda läbikukkumist ei saa siiski täielikult XP süüks panna, seal oli ka teisi pisemaid põhjuseid.

C3 kahekümnest osalejast viis on kirjutanud raamatuid ning müriaadi artikleid, kus nad väidavad et läbikukkumine oli tegelikult suur edu.

Mis on aga kõlava nime  extreme programming taga? Seda on vaja veidi pikemalt kirjeldada, kui siinse blogipostituse skoopi mahub. Soovitan alustada näiteks Wikipediast selle uurimist.

Mida aga reaalselt extreme programming nõuab ja pakub? Täpseid kirjeldusi on just nii palju kui on XP gurusid. Ühes on aga kõik ühel meelel – ekstreemprogrammeerimise põhidogmaks on, et pidev nõuete muutus on normaalne ja tervitatav.

Praktikas rõhutakse järgmisele (WP):

Fine scale feedback

Continuous process

Shared understanding

Programmer welfare

circles 

Vead ja inetused

Loomulikult kehtivad XP kohta kõik agiilsete metoodikate puudused, kuid on veel lisaks teisigi.

Üks kõige rohkem ette heidetud probleeme on XP paratamatu “kõik või mitte midagi” lähenemine – ehk nagu kirjutab Matt Stevens, “XP is like a ring of poisonous snakes, daisy-chained together. All it takes is for one of them to wriggle loose, and you’ve got a very angry, poisonous snake heading your way.”. Kui sa võtad XP metoodikast üle ainult osa, siis on tulemuseks kaos.

Paarisprogrammeerimine on teine pideva kriitikatule all olevaid praktikaid. Ekstreemprogrammeerimise gurude järgi peaks kaks programmeerijat ühe arvuti taga kirjutama rohkem koodi ja tegema vähem vigu, kui samad programmeerijad eraldi. Teatud määral see nii ka on – kuid tulemuste paranemine pole nii suur, kui alguses välja reklaamiti. Samuti on paarisprogrammeerimise tulemused paremad algajate programmeerijate puhul, senior programmer’ide puhul on näidatud isegi vastupidist tulemust. XP aga eeldab kogenuid ja häid programmeerijaid.

Lisaks veel saab oluliseks programmeerijate omavaheline “klapp”. Kui kahe inimese tööstiil omavahel ei sobi, siis tulemuseks halb kood ja närvis ning tigedad inimesed. Lisaks eelistab suur osa programmeerijaid töötada omaette, oma tempos ja pausidega. Nõnda ongi näidatud et paarisprogrammeerimine viib suurema kurnatuseni ja üleväsimusele – olgem ausad, kaheksa tundi päevas ilma pausideta koodi kirjutada on võimalik vaid ekstreemjuhtudel ja lühiajaliselt. Kes meist ei teeks aeg-ajalt pausi töös, et Postimeest või blogisissekandeid lugeda – on näidatud et sellised lühiajalised pausid viivad kokkuvõttes suurema tööviljakuse ja madalama stressini. Iseasi, kui muidugi päev läbi ratepede ollakse…

Nii ongi normaalne, et reaalset koodi kirjutatakse kuni kuus tundi päevas. Osa ülejäänud tööpäevast läheb organisatoorsele asjaajamisele, kohvipausidele, uudiste lugemisele, süsteemiadministraatori sõimamisele ja muule kommunikatsioonile. See ongi õige ja hea, nii tagatakse parem kvaliteet ja töötajate rahulolu. Kui aga töötatakse paaris, üks koodijatest on nikotiinisõltlane kes vajab iga poole tunni tagant viis minutit mürgikepikest ja teine inimene soovib teha kahetunniseid tihedaid koodimissessioone, mille järel on pool tundi lõdvestumiseks… kui suur on tõenäosus, et nende paaripanekust on oodata head koodi?

Liigne automatiseeritud testide usaldamine. Miski ei asenda inimesest testijat. Automatiseeritud test laseb läbi ilma igasuguste probleemideta kõik kasutajaliidese vead (kümne tähemärgi laiune ja kolme rea kõrgune kast, kuhu kasutaja peab kirjutama 1000 tähemärki teksti? No problemo!), kasutaja jaoks vaenulikud featuurid (pidevad salasõna küsimised), pärast nupuvajutust tuleb viisteist sekundit oodata, sest programmeerija polnud kuulnud where SQL-klauslist jne. Sellised asjad ei tohiks kunagi kasutajani jõuda, saab siis tiim neilt tagasisidet või ei.

Samuti võivad olulist osa mängida halvasti kirjutatud testid. Protseduur läbi testi etteantud parameetritega, näiteks esemete hulk netipoe ostukorvis – testis anti ette väärtused 0…100 – kuid testi kirjutanud programmeerija pole mõelnud asjaolule, et protseduur kasutab esemete arvu hoidmiseks byte-tüüpi muutujat ja kui siis kasutaja üritab osta 256 kondoomi… ei saa ta mitte lahedat puhkust, vaid tigeda overflow veateate.

XP on suunatud kliendile, kes ei tea mida ta tahab. Kui kliendil on soov saada veebileht, millel on ainult ja ainult võimalus lugeda viimaseid uudiseid, lehe raam on hall, laiust 800 pikslit ja fondiks Verdana, siis on skoop selge ja töö lihtne. Kui aga klient tuleb sooviga “teate, tahaks nagu sellist… sellist asja… noh, veebilehte… kus on uudised.. ja siis paneks veel ilmateate võibolla… ja ehk börsiteated… ja miks mitte horoskoop… ning äkki tuleb mulle veel midagi meelde… (miks tuli mulle kalev.ee pähe seda kirjutades?!), siis on selgelt näha, et on vaja kas kliendi vajadused enne väga selgelt välja uurida, visualiseerida ja kirja panna – või siis hakata lisama asju jupikaupa, ekstreemprogrammeerimise stiilis. Neljapäevaks saab uudised lehele, siis uurime mida järgmiseks teha.

Ning selle lähenemise ohuks on feature creep. Klient soovib peale uudisete, ilmateate, horoskoobi ja börsiteadete ilusat livesse jõudmist saada ka foorumit, uudiste kommenteerimise võimalust, veebikaamerat, kasutajate pilte, hinnavõrdlust, jututuba, ostu-müügi kuulutusi ja kasutaja poolt muudetavat kujundust. Aga hoole ja armastusega kirjutatud lehe mootor ei suuda enamikku nendest nõudmistest toetada ilma täieliku ümberkirjutamiseta, ei skaleeru ning tegelikult peaks olema see kirjutatud Javas mitte PHP’s. Ja ongi nii arendustiim kui ka klient maoli.

xp-project

Olen ennegi kirjutanud ühest Eesti esimesest ekstreemprogrammeerimise projektist – ja nagu siis, ei tea ma ka praegu kui palju sellest on tõsi ja palju urban legend. Pangad teadagi oma tarkvaarendusest avalikult ei räägi, olen ainult kuulujutte kuulnud.

Üks Eesti suurpankade IT-juhte oli kuulnud, et extreme programming on väga hea, ilus ja tore – seega tuleb seda rakendada. Kuivõrd Eestis XP spetsialiste polnud, siis palgati välismaalt hästi lõhnastatud, ülikonda kandev ja korralikult raseeritud XP-guru.

Vastupidiselt kõikidele eelnevast lõigust välja loetavatele asjaoludele oli XP-guru ka tegelikult teadja ja tegija mees. Tarkvara esimesed iteratsioonid olid head, töötasid korralikult, veavabalt ja kiiresti. Juhtkond oli rahul, kasutajad ka. Mindi edasi järgmiste arendustsüklitega… ja kuue kuu pärast saabus oli heast ja kiirest tarkvarast saanud aeglane ja vigane monstrum. Aga miks?

Algne arhitektuur oli igati korralik. Aga ei arhitekt ega arendajad ei osanud arvata, kui palju lisafunktsionaalsust soovitakse tarkvarale lisada – ja mingil hetkel paindlik arhitektuur enam ei paindunud. Ka ei käinud arendajad enam muutustest üle – so. muudatused hakkasid kuhjuma ja algse funktsionaalsuse veavabat tööd ei suudetud enam kontrollida.

Lõpuks pani pank arenduse seisma ja kirjutas kogu rakenduse uuesti, traditsioonilisi meetodeid kasutades. See pole otseselt XP süü, kuid on hea näide milliseid ohtusid XP endas sisaldab.

Siiski on kuuldavasti seal pangas mindud edasi agiilsete meetoditega, ehkki mitte alati ekstreemprogrammeerimisega.

Alguses käisid XP gurud välja slogani “no documentation”. Üsna pea sai sellest “documentation as needed”  ja vabandused “XP is not anti-documentation; it just recognizes that documentation has a cost and that not creating it might be more cost-effective.”. Mis on ju tõsi, kellele meeldiks dokumentatsiooni kirjutada, eriti kui seda kunagi ei loeta? Aga pahatihti on dokumentatsioon tarkvara puhul ülikriitiline, eriti kui tarkvata peab aastaid töötama – kui arhitekt, analüütik ja arendajad on firmast ammu lahkunud ja keegi enam ei tea kuidas miski töötab…

Eks kriitikat ekstreemprogrammeerimise kohta ole veel palju tehtud, kuid ülal peaks olulisemad punktid olema välja toodud. XP on üks nendest “super-hüper-ultra” ideedest, mis iga paari aasta tagant paistavad programmeerimismaailma raputavat (“goto on alati halb”, “objektorienteeritud programmeerimine on ainuke võimalik asi”, “funktsionaalne programmeerimine on ainuke võimalik asi”, “Ruby on Rails (asenda: Erlang, Python, Eiffel, Lisp) on ainuke keel, milles kõlbab programmeerida”, “SOA peab alati ja igal pool kasutuses olema”) ja millest ainukesena IT-raamatuid välja andvad kirjastused tulu saavad. Tark on võtta neist kasulik ja hype endast külmalt mööda lasta.

——-

Lõpetuseks – USA armee tarkvaraarenduses segati hiljuti edukalt agiilseid (sh XP) ja traditsioonilisi meetodeid (Google Cache, sest leht hetkel maas). Tõsi küll, tsükli pikkuseks oli kaks kuud, mis on agiilse arenduse jaoks väga pikk – kuid tühine võrreldes sealse traditsioonilise aastase tsükliga.

3 kommentaari »

  1. puhtalt võttes on kõik stiilid pahad, eks, sest mingi vea leiab ikka. Mulle tundub, et kõige õigem on toetuda oma enda heale praktikale… eeldusel muidugi, et see praktika puhta metsapoole pole:)

    Automaattestide puhul tahaks öelda, et ainult paha välja toomine jätab mulje, nagu nad oleks kasutud. Muidugi on, kui neid mõistuseta ja toore jõuga vorpida. Küll aga on neist kõvasti kasu päris-testija kõrval (ntx db kihi testid, mida testija ei pruugi osatagi/saadagi testida).

    XP’ga ma ise küll ühtegi projekti täismahus teinud ei ole, ja tegelt isegi ei pea seda tehnikat õigeks terve projekti jaoks. Küll aga oleme me XP’d kasutades kustutanud tulekahjusid, ja seal on see tehnika olnud täiesti omal kohal.

    kommentaar kirjutas urmas — 2008-06-20 @ 10:41:29 | Vasta

  2. Ei, automaattestid kindlasti kasutud ei ole. Pigem tõin ma välja, et ainult automaattestide (või õigemini unit testide) peale ei tasu loota, on väga palju veatüüpe mida saab ainult inimese testimine leida. Unit testid ja automaattestimine ei ole üks ja seesama, vt näiteks AutomatedQA produkte.

    kommentaar kirjutas dukelupus — 2008-06-20 @ 12:07:52 | Vasta


RSS feed for comments on this post. TrackBack URI

Lisa kommentaar

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Muuda )

Twitter picture

You are commenting using your Twitter account. Log Out / Muuda )

Facebook photo

You are commenting using your Facebook account. Log Out / Muuda )

Google+ photo

You are commenting using your Google+ account. Log Out / Muuda )

Connecting to %s

Create a free website or blog at WordPress.com.