Kasutaja:Achaad/Ekstreemprogrammeerimine

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

Ekstreemprogrammeerimine (ingl. k. Extreme Programming, XP) on tarkvara arenduse metoodika mille eesmärgiks on parandama tarkvara kvaliteedi ja tundlikkust kliendi muutvatele nõuetele. Ekstreemprogrammeerimine on agiilse projektijuhtimise liik[1][2] ja seetõttu propageerib tarkvara väljalasket lühikestes arendustsüklites, mis parandab produktiivsust ja annab kliendile võimalust esitada uued nõuded.

Teised ekstreemprogrammeerimise elemendid on paarisporgrammeerimine, ulatuslik koodi arvustus, terve koodi ühiktestimine, ebavajalikke funktsioonide lisamise vältimine, vahejuhtimise puudumine, koodi lihtsus ja selgus, eeldus, et kliendi nõuded muutuvad aja möödudes ning probleemi selginedes ja sage suhtlus klieniga ja prgrammeerijate vahel.[2][3] Metoodika on oma nime saanud ideest, et tavalise tarkvaraarenudse kasulikud elemendid on viidud "ekstreemsele" tasemele. Näiteks sageli kasutatakse koodi arvustust ning ekstremaalsel tasemel see on paarisprogrammeerimine, kui kaks inimest kirjutavad koodi sellisel viisil, et üks nendest kirjutab ja teine kontroliib ja mingi aja pärast nad vahetavad rollid.

Mõisted[muuda | muuda lähteteksti]

Eesmärgid[muuda | muuda lähteteksti]

"Extreme Programming Explained” ütleb, et ekstreemprogrammeerimine on tarkvaraarenduse distsipliin, mis organiseerib inimesi tootma kõrgema kvaliteediga tarkvarat tootlikumalt.
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.

Tegevused[muuda | muuda lähteteksti]

XP kohaselt programeerimises on neli erinevat tegevust, mis on koodi kirjutamine, testimine, kuulamine ja kavandamine.

Koodi kirjutamine[muuda | muuda lähteteksti]

Ekstreemprogrammeerimise metoodika kasutajad väidavad, et kõige olulisem tarkvaraarenduse tulemus on kood ehk reeglid, mida täidab arvuti. Ilma koodita ei ole töötavat tarkvarat.
Koodi kirjutamine aitab leida kõige parema lahendust. Koodi saab kasutada, et vestlema probleemidest. Kui programmeerija soovib seletada mingit keerulist lahendust võib kasutada lihtsamat koodi, et paremini edastada oma mõtlemisviisi. XP pooldajad väidavad, et kood on alati selge ja sisutihe ning seda saab tõlkida ainult ühel viisil.

Testimine[muuda | muuda lähteteksti]

Ekstreemprogrammeerimisel arvatakse, et kui tavaline testimine saab tuvastada mõned vead, siis ulatuslik testimine leiab neid mitu korda rohkem.

  • Ühiktestimine kontrollib kas üks konkreeetne funksioon töötab nii, nagu ta peaks. Programmeerijad kirjutavad nii palju kontrollteste, kui palju potentsiaalselt ohtlikke juhtumeid nad saavad välja mõelda. Kui kõik testid on edukalt läbitud, siis koodi kirjutamine on lõpetatud. Programmeerijad kontrollivad iga koodi osa enne seda, kui hakkavad töötama järgmise osaga.
  • Vastuvõtu testid kinntiavad programmeerijad saavad nõuetest aru nii, et tarkvara rahuldaks kliendi.

Kuulamine[muuda | muuda lähteteksti]

Programmeerijad peavad kuulama kliente ja aru samma, mida tarkvara peab tegema ja millist tegevusloogikat kasutama. Nad peavad nendest vajadustest aru saama piisavalt hästi, et anda kliendile tagasiside sellest, kuidas saab seda ülesaneet lahendada või millised on raskused.

Kavandamine[muuda | muuda lähteteksti]

Kavandamine aitab vältida sellist olukorda, et tarkvara muutub liiga keeruliseks ja selle sõltuvused arusaamatuks. Kavandamine aitab koostada projekti struktuuri, mis korraldab kogu loogikat.

Printsiibid[muuda | muuda lähteteksti]

Tagasiside[muuda | muuda lähteteksti]

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.

Lihtsuse eeldus[muuda | muuda lähteteksti]

Iga problebleemi tuleb kohtlema 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 muutuste tegemine ühel korral ei ole mõistlik ega kasulik. XP kasutab lisanduvaid muutusi. Näiteks süsteem uuendub iga kolme nädala tagant. Kui tehakse väiksed sammud, siis arendus on kliendi suurema kontrolli all.

Hõlma muutused[muuda | muuda lähteteksti]

Muutuste hõlmamisprintsiib seisneb selles, et ei ole vaja töötada nende vastu vaid tuleb neid kasutada. Näiteks, kui ühe kohtumise jooksul selgub, et kliendi soovid on muutunud, arendajad peavad seda tunnustama ja hakkama planeerima uued nõuded järgmiseks sammuks.

Kriitika[muuda | muuda lähteteksti]

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

Kriitika sisaldab:

  • Metoodika on ainult nii kasulik, kui inimesed, mis seda kasutavad. Agiilne projektijuhtimine ei lahenda seda
  • Kasutatakse, et saada kliendist tohkem finantse, sest ei saa talle esitada lõpliku toodet
  • Kindla struktuuri ja dokumentatsiooni puudumine
  • Töötab ainult kui on tegemist senior-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 ebaeffektiivne, kui üks koodi osa on vaja ümberkirjutada mitu korda, kuid traditsioonilise arendusmetoodikas koodi kirjutatakse ainult üks kord
  • On võimatu ennustada, kui palju tööd ja resurse projekt vajab

Vaata veel[muuda | muuda lähteteksti]

Viited[muuda | muuda lähteteksti]

  1. "Human Centred Technology Workshop 2005", 2005, (vaadatud 04.01.18)
  2. 2,0 2,1 "Extreme Programming"(vaadatud 04.01.18)
  3. "Manifesto for Agile Software Development", Agile Alliance, 2001, (vaadatud 04.01.18)
  4. McBreen, P. (2003), Questioning Extreme Programming, Boston, MA: Addison-Wesley, ISBN 0-201-84457-5 
  5. Boehm, B.; R. Turner (2004), Balancing Agility and Discipline: A Guide for the Perplexed, Boston, MA: Addison-Wesley, ISBN 0-321-18612-5 
  6. Stephens, Matt; Doug Rosenberg (2004), The irony of extreme programming, , MA: Dr Dobbs journal, http://www.drdobbs.com/the-irony-of-extreme-programming/184405651 
  7. sdmagazine, http://www.sdmagazine.com/documents/s=1811/sdm0112h/0112h.htm. Välja otsitud 2018-01-04