Vikipeedia

Ekstreemprogrammeerimine

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.

Planeerimise ja tagasiside skeem ekstreemprogrammeerimises

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 nimetuse 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 kindla ajavahemiku 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.

Tegevused muuda

Ekstreemprogrammeerimises on neli põhitegevust, mis kuuluvad tarkvaraarenduse protsessi juurde: koodi kirjutamine, testimine, kuulamine ja disainimine.

Koodi kirjutamine muuda

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

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

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

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]

Põhimõtted muuda

Ekstreemprogrammeerimine püüab vähendada muudatuste maksumust kasutades mitu väikset arendustsükleid ühe suurema asemel. Sellises metoodikas muutused on loomulik ja soovitud osa arendusprojektides ja neid tuleb planeerida ja mitte vältida. Ekstreemprogrammeerimine lisab agiilsele projektijutimisele ka mitu põhiväärtusi, printsiipe ja tegutsemisviisi.

Tagasiside muuda

Ekstreemprogrammeerimise seisukohalt tagasiside on kõige kasulikum, kui see on sage ja kohene. Metoodika rõhutab, et õppimiseks ja muudatuste tegemiseks on vajalik minimaalne viivitus tegevuse ja tagasiside vahel. Erinevalt traditsioonilisest arendusest, suhtlemine kliendi ja tootja vahel toimub palju sagemini. Kliendil on selge arusammine süsteemist ning ta saab ise anda tagasisidet ja vajadusel juhtida arendust. Sage tagasiside annab kliendile võimalust kiiremini märgata, kui arendaja on valesti disainist aru saanud ja seetõttu arendaja saab kergemini vead parandada.

Ühiktestid on suur osa kiire tagasiside printsiibist. Nad annavad otsene tagasiside koodi kirjutamisel muutuste peale. Lisaks sellele, ühiktestid peavad kontrollima mitte ainult seda koodi, mida programmeerija on kirjutanud, vaid terve projekti, kasutades automatiseeritud protsessi, mida on võimalik käivitada ühe käsuga. Sellisel juhul, kui arendaja muudab midagi projektis, mis põhjustab veat teises projekti osas, automaatiseeritud testimine avaldab seda. Tavalise arenduse metoodikas sellise testimise puudumine põhjustaks seda, et ühe vigane koodi muutus oleks peidetud kuni toimuks integreerimistestimine või isegi tootmisel. Sellisel juhul oleks keeruline leida seda muutust paljude teiste muutuste seas.

Lihtsus muuda

Iga problebleemi tuleb käsitleda nii nagu tema lahendus oleks "ekstreemselt lihtne". Traditsiooniline arendusmetoodika nõuab tuleviku planeerimist ja kirjutada koodi korduskasutamiseks. Ekstreemprogrammeerimine lükab sellised ideed tagasi.

Ekstreemprogrammeerimise pooldajad väidavad, et suurte muudatuste tegemine ühe korraga ei ole mõistlik ega kasulik. XP kasutab lisanduvaid muudatusi. Näiteks süsteem uuendub iga kolme nädala tagant. Väiksed sammudega on arendus kliendi suurema kontrolli all.

Kriitika muuda

Ekstreemprogrammeerimise esialgne populaarsus ja uute meetoite kasutamine sai tugevalt kritiseeritud McBreeni,[6] Boehm ja Turneri,[7] Matt Stephens ja Doug Rosenberg'i poolt.[8] Teiselt poolt, mõned arvavad, et sellise kriitika põhjus on agiilsest projektijuhtimisest valesti aru saamine.[9]

Kriitika sisaldab:

  • Metoodika on ainult nii kasulik, kui inimesed, mis seda kasutavad. Agiilne projektijuhtimine ei lahenda seda
  • Kasutatakse, et saada kliendist rohkem finantse, sest ei saa talle esitada lõpliku toodet
  • Kindla struktuuri ja dokumentatsiooni puudumine
  • Töötab ainult kui on tegemist seenior-arendajatega
  • Sisaldab puudulikku tarkvara disaini
  • Vajab palju kohtumisi klientide raha eest
  • Nõuab liiga palju kultuuri muutust, et seda kasutada
  • Võib põhjustada keerulisemad kontrakti läbirääkimised
  • Võib olla väga ebaefektiivne, kui üks koodi osa on vaja ümber kirjutada mitu korda, kuid traditsioonilise arendusmetoodikas koodi kirjutatakse ainult üks kord
  • On võimatu ennustada, kui palju tööd ja ressursse projekt vajab

Ajalugu muuda

Ekstreemprogrammeerimise lõi Kent Beck ajal, mil ta töötas Chrysler Comprehensive Compensation System (C3) palgaarvestussüsteemi projekti kallal.[10] Beck sai C3 projektijuhiks märtsis 1996. aastal. Ta hakkas projektis kasutatud arendusmetoodikat viimistlema ning kirjutas sellest metoodikast raamatu "Extreme programming explained", mis ilmus 1999. aasta oktoobris.[10]

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.[11] 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 tarkvara 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

1990ndatel 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 nn dot-comi 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,[10] 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.[12]

Beck on toimetanud 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 1990ndate lõpus ja 2000ndate alguses.[13]

Viited muuda

  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. ↑ P. McBreen (2003). Questioning Extreme Programming. Boston: Addison-Wesley. ISBN 0-201-84457-5.
  7. ↑ R. Turner, B. Boehm (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN 0-321-18612-5.
  8. ↑ Doug Rosenberg, Matt Stephens (2004). The irony of extreme programming. Dr Dobbs journal.
  9. ↑ sdmagazine, originaali arhiivikoopia seisuga 16. märts 2006, vaadatud 4. jaanuaril 2018
  10. ↑ 10,0 10,1 10,2 "Extreme Programming", Computerworld (online), detsember 2001, (vaadatud 29.01.17)
  11. ↑ Charles S.Wasson "System Engineering Analysis, Design, and Development: Concepts, Principles, and Practices", Wiley 2015, lk 327 (vaadatud 31.01.17)
  12. ↑ http://www.extremeprogramming.org
  13. ↑ Priit Valdmees "Ekstreemprogrammeerimine: ülevaade, praktikad ja võrdlus teiste väledate arendusmeetoditega", 2006, lk 7 (vaadatud 31.01.17)
Pärit leheküljelt "https://et.wikipedia.org/w/index.php?title=Ekstreemprogrammeerimine&oldid=6387268"