Ekstreemprogrammeerimine

Allikas: Vikipeedia
Jump to navigation Jump to search
Planeerimise ja tagasiside skeem ekstreemprogrammeerimises.

Ekstreemprogrammeerimine on tarkvaraarenduse metoodika, mis on mõeldud parandama tarkvara kvaliteeti ja vastavust kliendi muutuvatele vajadustele. Agiilse tarkvaraarenduse alaliigina[1][2] [3]toetab see sagedasi „avaldamisi“ lühikeste arengutsüklite jooksul, parandamaks produktiivsust ja tutvustamaks kontrollpunkte, kus uued klientide nõuded vastu võtta.

Ekstreemprogrammeerimise elemendid on paarisprogrammeerimine või ulatuslike koodi ülevaatuste tegemine, kogu koodi üksuskatsetamine, funktsioonide programmeerimise vältimine enne, kui neid on tegelikult vaja, kindel juhtimisstruktuur, koodi lihtsus ja selgus, eeldamine, et kliendi nõuded muutuvad aja möödudes ning probleemi selginedes ja sage suhtlus kliendiga ja programmeerijate vahel.[2][3][4] Metoodika on oma nime saanud ideest, et traditsioonilise tarkvaratehnika tavade kasulikud elemendid on viidud „ekstreemsele“ tasemele. Näiteks tuleb programmeerimises läbi viia koodi ülevaatusi, et teha kindlaks, kas see töötab nii nagu vaja. N-ö ekstreemne koodi ülevaatamine seisneb selles, et koodi ei vaadata üle mitte kindlate ajavahemike tagant, vaid kogu aeg - seega toimib paarisprogrammeerimine, kus kaks programmeerijat hoiavad jooksvalt teineteise kirjutatud koodil silma peal ning teevad kindlaks, et see vastab nõuetele.

Tegevus[muuda | muuda lähteteksti]

Ekstreemprogrammeerimises on neli erinevat tegevust, mis kuuluvad tarkvaarenduse protsessi juurde: koodi kirjutamine, testimine, kuulamine ja disainimine.

Koodi kirjutamine[muuda | muuda lähteteksti]

Ekstreemprogrammeerimise pooldajad väidavad, et ainus tõeliselt oluline süsteemi arendamise protsessi saadus on kood - tarkvara juhised, mida arvuti saab interpreteerida. Ilma koodita pole ka töötavat tulemust.

Koodi kirjutamist saab kasutada ka selleks, et jõuda sobivaima lahenduseni. Koodi kirjutamine võib aidata vahetada mõtteid programmeerimise probleemide kohta. Programmeerija, kes tegeleb keeruka programmeerimisprobleemiga või kellel on raskusi lahenduse seletamisega kaasprogrammeerijatele, võib seda kirjutada lihtsustatult ning kasutada seda koodi näitamaks, mida ta mõtleb. Kood, ütlevad selle seisukoha pooldajad, on alati selge ja lühike ning seda ei saa tõlgendada mitmel viisil. Teistel programmeerijatel on võimalik anda tagasisidet koodile samuti koodi kirjutades.[5]

Testimine[muuda | muuda lähteteksti]

Ekstreemprogrammeerimise lähenemisviis seisneb selles, et kui vähene testimine võib kõrvaldada mõned vead, siis testides palju võib kõrvaldada kõvasti rohkem vigu.

Üksustestid teevad kindlaks, kas antud funktsioon töötab nii nagu mõeldud. Programmeerijad kirjutavad võimalikult palju automatiseeritud teste, mis võimaldavad koodis olevaid vigu päevavalgele tuua. Kui kõik testid jooksevad edukalt, siis on koodi kirjutamine lõpule viidud. Igat kirjutatud koodiosa testitakse enne järgmiste funktsioonide juurde liikumist.

Kasutuselevõtu testid kontrollivad, kas nõuded, nii nagu programmeerijad neist aru on saanud, vastavad kliendi tegelikele vajadustele.[5]

Kuulamine[muuda | muuda lähteteksti]

Programmeerijad peavad kuulama, mida klient soovib, et süsteem teeks seda, mida äriloogika nõuab. Oluline on mõista kliendi vajadusi piisavalt hästi, et osata anda talle tagasisidet probleemi lahendamise tehniliste aspektide kohta. Ekstreemprogrammeerimises rakendatavat kliendi ja programmeerija vahelist suhtlust nimetatakse plaanimismänguks.[5]

Disainimine[muuda | muuda lähteteksti]

Lihtsustatult vaadates võib öelda, et süsteemiarendus ei vaja rohkemat kui koodi kirjutamist, testimist ja kuulamist. Kui need tegevused on edukalt läbi viidud, peaks süsteem töötama. Praktikas see siiski nii lihtne ei ole. Disainimiseta võib saada palju tehtud, kuid ühel hetkel jäädakse jänni. Süsteem muutub liiga keeruliseks ning süsteemi sees olevad sõltuvused ei ole enam nii selged. Seda on võimalik vältida, luues disaini struktuuri, mis organiseerib süsteemis olevat loogikat. Hea disain väldib paljusid süsteemis esinevaid sõltuvusi: see tähendab, et süsteemi ühe osa muutmine ei mõjuta enam teisi osasid.[5]

Ajalugu[muuda | muuda lähteteksti]

Ekstreemprogrammeerimise lõi Kent Beck ajal, mil ta töötas Chrysler Comprehensive Compensation System (C3) palgaarvestussüsteemi projekti kallal.[6] Beck sai C3-e projektijuhiks märtsis 1996. aastal ning ta hakkas projektis kasutatud arendusmetoodikat viimistlema ning kirjutas sellest metoodikast raamatu (1999. aasta oktoobris avaldati tema raamat „Extreme programming explained“).[6]

Paljusid ekstreemprogrammeerimise praktikaid on kasutatud juba mõnda aega. Ekstreemprogrammeerimise metoodika viib „parima praktika“ äärmuslikule tasemele. Näiteks, testide planeerimist ja kirjutamist enne igat mikrojuurdekasvu kasutati juba NASA Mercury programmi ajal varajastel 1960ndatel.[7] Et lühendada kogu arenduseks kuluvat aega, on mõned formaalsed testidokumendid (nagu näiteks kasutuselevõtu test) välja töötatud paralleelselt tarkvara valmimisega testimiseks (või vahetult enne seda, kui tarvara on testimiseks valmis). NASA sõltumatu katserühm saab kirjutada katsemeetodeid, mis põhinevad vorminõuetel ja loogilistel piiridel juba enne, kui tarkvara on valmis kirjutatud ja riistvaraga integreeritud. See kontseptsioon on viidud ekstreemprogrammeerimises äärmuslikule tasemele, kirjutades automatiseeritud teste (nt tarkvara moodulite sees), mis kinnitavad isegi väikeste tarkvara kirjutamise osade operatsioone, mitte ei testi ainult suuremaid tunnusjooni.

Päritolu[muuda | muuda lähteteksti]

1990ndatel aastatel kujundasid tarkvaraarendust peamiselt kaks tegurit: sisemine ja välimine tegur. Sisemiselt mõjutas tarkvaraarendust see, et protseduurilise programmeerimise asendas objektorienteeritud programmeerimine. Välimiseks mõjuteguriks oli interneti kasutamise kasv ja punkt-com buum, mis rõhutasid toodete turule jõudmise kiirust ning ettevõtte kasvu kui konkurentsile orienteeritud majandustegevuse faktoreid. Kiiresti muutuvad vajadused nõudsid lühemaid toote elutsükleid ja olid tihti vastuolus traditsiooniliste tarkvaraarenduse meetoditega.

Chrysler Comprehensive Compensation System (C3) projekti otsustati sisse tuua Kent Beck,[6] silmapaistev smalltalki praktikant, et ta teeks süsteemile jõudluse häälestust, kuid Kent Becki roll laienes, kuna ta märkas seoses arendusprotsessiga mitmeid probleeme. Ta haaras kinni võimalusest esitada ja rakendada mõningaid muudatusi.

Beck kutsus projekti Ron Jeffriesi, et ta aitaks neid meetodeid arendada ja viimistleda. Jeffries tegutses seejärel treenerina, püüdes muuta praktikaid C3 tiimile harjumuseks.

Informatsiooni ekstreemprogrammeerimise taga olevate põhimõtete ja tavade kohta jagati laiemale maailmale läbi arutelude algupärases wikis, Cunninghami WikiWikiWebis. Erinevad panustajad arutasid ja arendasid teemat edasi ning selle tulemusel tekkisid mõningad spinn-off metoodikad, nt agiilne tarkvaraarendus. Lisaks on ekstreemprogrammeerimise mõisteid selgitatud mitu aastat, kasutades hüperteksti süsteemi kaarti ekstreemprogrammeerimise veebilehel http://www.extremeprogramming.org ca 1999.

Beck on toimetanud mitmeid ekstreemprogrammeerimise teemalisi raamatuid, kaasa arvatud tema enda kirjutatud raamat „Extreme programming explained“ (1999, ISBN 0-201-61641-6), levitades oma ideid laiema publiku hulgas. Raamatute autorid on käinud läbi erinevaid aspekte seoses ekstreemprogrammeerimise ja selle praktikatega, mõni neist on lähenenud ka kriitilisema poole pealt.

Ekstreemprogrammeerimine tekitas tarkvarakogukondades märkimisväärset huvi hilistel 1990ndatel ja varastel 2000ndatel.[8]

Viited[muuda | muuda lähteteksti]

  1. "Human Centred Technology Workshop 2005", 2005, (vaadatud 29.01.17)
  2. 2,0 2,1 "Design Patterns and Refactoring", University of Pennsylvania, 2003, veebilehekülg: UPenn-Lectures-design-patterns.(vaadatud 29.01.17)
  3. 3,0 3,1 "Extreme Programming"(vaadatud 29.01.17)
  4. "Manifesto for Agile Software Development", Agile Alliance, 2001, (vaadatud 29.01.17)
  5. 5,0 5,1 5,2 5,3 Priit Valdmees "Ekstreemprogrammeerimine: ülevaade, praktikad ja võrdlus teiste väledate arendusmeetoditega", 2006, lk 14-16 (vaadatud 31.01.17)
  6. 6,0 6,1 6,2 "Extreme Programming", Computerworld (online), detsember 2001, (vaadatud 29.01.17)
  7. Charles S.Wasson "System Engineering Analysis, Design, and Development: Concepts, Principles, and Practices", Wiley 2015, lk 327 (vaadatud 31.01.17)
  8. Priit Valdmees "Ekstreemprogrammeerimine: ülevaade, praktikad ja võrdlus teiste väledate arendusmeetoditega", 2006, lk 7 (vaadatud 31.01.17)