Extreme Programming ( Extreme Programming , XP ) on yksi ketteristä ohjelmistokehitysmenetelmistä . Metodologian kirjoittajat ovat Kent Beck , Ward Cunningham , Martin Fowler ja muut.
Metodologian nimi tulee ajatuksesta soveltaa hyödyllisiä perinteisiä ohjelmistokehityksen menetelmiä ja käytäntöjä ja viedä ne uudelle "äärimmäiselle" tasolle. Joten esimerkiksi koodintarkistuskäytäntö , jossa yksi ohjelmoija tarkistaa toisen ohjelmoijan kirjoittaman koodin, "äärimmäisessä" versiossa on "pariohjelmointi", kun yksi ohjelmoija kirjoittaa koodia ja hänen kumppaninsa samalla tarkistaa jatkuvasti mitä kirjoitettua koodia.
Metodologian kehitti Kent Beck työskennellessään Chrysler Comprehensive Compensation System (C3) -palkkaprojektissa . Beckistä tuli projektipäällikkö maaliskuussa 1996. Hän alkoi parantaa projektissa käytettyä kehitysmetodologiaa ja kirjoitti siitä kirjan Extreme Programming Explained (julkaistu lokakuussa 1999). [1] Hanke päättyi helmikuussa 2000.
Kaksitoista Extreme Programming -perustekniikkaa (Extreme Programming -julkaisun ensimmäisen painoksen mukaan ) voidaan ryhmitellä neljään ryhmään:
XP sisältää automaattisten testien kirjoittamisen (koodi, joka on kirjoitettu erityisesti testaamaan muun koodin logiikkaa). Erityistä huomiota kiinnitetään kahteen testaustyyppiin:
Kehittäjä ei voi olla varma kirjoittamansa koodin oikeellisuudesta ennen kuin ehdottoman kaikki hänen kehittämänsä järjestelmän yksikkötestit toimivat. Yksikkötestien (yksikkötestien) avulla kehittäjät voivat varmistaa, että jokainen niistä toimii erikseen oikein. Ne auttavat myös muita kehittäjiä ymmärtämään, miksi tiettyä koodinpalaa tarvitaan ja miten se toimii - testikoodin tutkimisen aikana selviää testattavan koodin logiikka, koska on selvää, miten sitä tulisi käyttää. Yksikkötestien avulla kehittäjä voi myös refaktoroida ilman pelkoa .
Toiminnalliset testit on suunniteltu testaamaan useiden (usein melko vaikuttavan kokoisten) osien vuorovaikutuksesta muodostuvan logiikan toimivuutta. Ne ovat vähemmän yksityiskohtaisia kuin yksikkötestit, mutta ne kattavat paljon enemmän - eli testeillä, jotka suorittaessaan vaikuttavat suurempaan määrään koodia, on luonnollisesti suurempi mahdollisuus havaita virheellinen käyttäytyminen. Tästä syystä teollisessa ohjelmoinnissa toiminnallisten testien kirjoittaminen menee usein kirjoitusyksikkötestien edelle.
XP:ssä TDD-niminen lähestymistapa ( englanninkielisestä test-driven development - development through testing ) on korkeampi prioriteetti. Tämän lähestymistavan mukaisesti kirjoitetaan ensin testi, joka alun perin epäonnistuu (koska logiikkaa, jonka pitäisi tarkistaa, ei yksinkertaisesti vielä ole), sitten toteutetaan testin läpäisemiseen tarvittava logiikka. TDD mahdollistaa tietyssä mielessä kätevämmän koodin kirjoittamisen - koska testiä kirjoitettaessa, kun logiikkaa ei vielä ole, on helpointa huolehtia tulevan järjestelmän mukavuudesta.
Suunnittelupelin päätavoitteena on muodostaa nopeasti karkea työsuunnitelma ja päivittää sitä jatkuvasti tehtävän ehtojen selkiytyessä. Suunnittelupelin artefaktit ovat joukko paperikortteja, jotka sisältävät asiakkaan toiveet (asiakastarinat) ja karkean työsuunnitelman tuotteen seuraavan yhden tai useamman pienen version julkaisua varten. Kriittinen tekijä, joka tekee tästä suunnittelutyylistä tehokkaan, on se, että tässä tapauksessa asiakas on vastuussa liiketoiminnallisista päätöksistä ja kehitystiimi teknisistä päätöksistä. Jos tätä sääntöä ei noudateta, koko prosessi hajoaa.
XP:n "asiakas" ei ole se, joka maksaa laskut, vaan ohjelmistotuotteen loppukäyttäjä. XP väittää, että asiakkaan on oltava koko ajan yhteydessä ja käytettävissä kysymyksiin.
Pariohjelmointi olettaa, että kaikki koodit ovat samassa tietokoneessa työskentelevien ohjelmoijaparien luomia. Toinen heistä työskentelee suoraan ohjelman tekstin kanssa, toinen katselee työtään ja seuraa kokonaiskuvaa siitä, mitä tapahtuu. Tarvittaessa näppäimistö siirtyy vapaasti toisesta toiseen. Projektin parissa työskennellessä parit eivät ole kiinteät: ne on suositeltavaa sekoittaa niin, että jokaisella tiimin ohjelmoijalla on hyvä käsitys koko järjestelmästä. Siten pariohjelmointi tehostaa vuorovaikutusta tiimin sisällä.
Jos integroi kehitettävää järjestelmää riittävän usein, voit välttää suurimman osan siihen liittyvistä ongelmista. Perinteisissä menetelmissä integrointi suoritetaan pääsääntöisesti tuotteen työskentelyn lopussa, kun katsotaan, että kaikki kehitettävän järjestelmän komponentit ovat täysin valmiita. XP:ssä koko järjestelmän koodiintegrointi suoritetaan useita kertoja päivässä, sen jälkeen kun kehittäjät ovat varmistaneet, että kaikki yksikkötestit toimivat oikein.
Refaktorointi on tekniikka koodin parantamiseksi muuttamatta sen toimintoja. XP tarkoittaa, että kun koodi on kirjoitettu, se melkein varmasti uusitaan monta kertaa projektin aikana. XP-kehittäjät muokkaavat armottomasti aiemmin kirjoitettua koodia parantaakseen sitä. Tätä prosessia kutsutaan refaktorointiksi. Testin kattavuuden puute provosoi refaktoroinnin hylkäämisen, koska pelätään järjestelmän rikkoutumista, mikä johtaa koodin asteittaiseen huononemiseen.
Tuotteen versiot (julkaisut) tulee ottaa tuotantoon mahdollisimman usein. Kunkin version työstämisen tulisi kestää mahdollisimman vähän aikaa. Samanaikaisesti jokaisen version tulee olla riittävän merkityksellinen liiketoiminnalle.
Mitä aikaisemmin ensimmäinen toimiva versio tuotteesta julkaistaan, sitä aikaisemmin asiakas alkaa saada siitä johtuvaa lisätuottoa. Muista, että tänään ansaittu raha on arvokkaampaa kuin huomenna ansaittu raha. Mitä nopeammin asiakas aloittaa tuotteen käytön, sitä nopeammin kehittäjät saavat häneltä tietoa siitä, mikä vastaa asiakkaan vaatimuksia. Nämä tiedot voivat olla erittäin hyödyllisiä seuraavan julkaisun suunnittelussa.
XP lähtee siitä, että työn aikana ongelman olosuhteet voivat muuttua toistuvasti, mikä tarkoittaa, että kehitettävää tuotetta ei tule suunnitella etukäteen kokonaan ja täydellisesti. Järjestelmän yksityiskohtaisen suunnittelun yrittäminen heti työn alussa on ajanhukkaa. XP ehdottaa, että suunnittelu on niin tärkeä prosessi, että sitä on tehtävä jatkuvasti koko projektin elinkaaren ajan. Suunnittelu tulee tehdä pienin askelin jatkuvasti muuttuvat vaatimukset huomioon ottaen. Joka ajankohtana sinun tulee yrittää käyttää yksinkertaisinta nykyiseen ongelmaan sopivaa mallia ja muuttaa sitä ongelman olosuhteiden muuttuessa.
Kent Beck ja Martin Fowler [2] ehdottavat "yksinkertaisen suunnittelun" kuvaamista seuraavien neljän kriteerin täyttymiseksi:
Robert Martin on samaa mieltä [3] näistä säännöistä, mutta aikaisemmassa työssään [4] hän ehdottaa myös "yksinkertaisen suunnittelun" kuvaamista seuraavilla kolmella periaatteella:
Arkkitehtuuri on esitys järjestelmän osista ja niiden suhteista toisiinsa. Kehittäjien on analysoitava ohjelmistoarkkitehtuuria ymmärtääkseen, mihin järjestelmään heidän on lisättävä uusia toimintoja ja minkä kanssa uusi komponentti on vuorovaikutuksessa.
Järjestelmän metafora on analoginen sen kanssa, mitä useimmat tekniikat kutsuvat arkkitehtuuriksi. Järjestelmämetafora antaa tiimille käsityksen siitä, miten järjestelmä tällä hetkellä toimii, mihin uusia komponentteja lisätään ja missä muodossa niiden tulisi olla.
Hyvän metaforan valitseminen auttaa kehitystiimiä ymmärtämään järjestelmän toimintaa. Joskus tämä ei ole helppoa.
Tässä vaiheessa Bob Martin on myöntänyt, että järjestelmän metafora on vanhentunut ja se pitäisi korvata Domain Driven Designilla .
Kaikkien työryhmän jäsenten tulee noudattaa yhteisten koodausstandardien vaatimuksia. Siten:
Jos tiimi ei käytä yhtenäisiä koodausstandardeja, kehittäjien on vaikeampaa reagoida uudelleen. kun vaihdat kumppaneita pareittain, on enemmän vaikeuksia; yleisesti ottaen projektin eteneminen on vaikeaa. XP:n puitteissa on tarpeen tehdä vaikeaksi ymmärtää, kuka on tämän tai tuon koodin kirjoittaja - koko tiimi toimii yhtenäisellä tavalla, kuin yksi henkilö. Ryhmän on muodostettava sääntöjoukko, ja jokaisen tiimin jäsenen on noudatettava näitä sääntöjä kirjoittaessaan koodia. Sääntöluettelo ei saa olla tyhjentävä tai liian laaja. Tehtävänä on muotoilla yleiset ohjeet, jotka tekevät koodista ymmärrettävän jokaiselle tiimin jäsenelle. Koodausstandardin tulee olla aluksi yksinkertainen, sitten se voi vähitellen muuttua monimutkaisemmaksi, kun kehitystiimi saa kokemusta. Standardin laatimiseen ei tarvitse käyttää liikaa aikaa.
Yhteinen omistajuus tarkoittaa, että jokainen tiimin jäsen on vastuussa kaikesta lähdekoodista . Näin ollen jokaisella on oikeus tehdä muutoksia mihin tahansa ohjelman osaan. Pariohjelmointi tukee tätä käytäntöä: työskentelemällä eri pareissa kaikki ohjelmoijat tutustuvat kaikkiin järjestelmän koodin osiin. Koodin kollektiivisen omistajuuden tärkeä etu on, että se nopeuttaa kehitysprosessia, koska virheen sattuessa kuka tahansa ohjelmoija voi korjata sen.
Jokaisen ohjelmoijan oikeus muuttaa koodia on vaarassa, että ohjelmoijat, jotka luulevat tietävänsä mitä tekevät, mutta eivät ota huomioon joitain riippuvuuksia, tuovat esiin virheitä. Äärimmäiset ohjelmoijat uskovat, että hyvin määritellyt yksikkötestit ratkaisevat tämän ongelman: jos tarkistamattomat riippuvuudet aiheuttavat virheitä, seuraava yksikkötesti epäonnistuu ja paljastaa ongelman.
| Ohjelmistokehitys | |
|---|---|
| Prosessi | |
| Korkean tason käsitteet | |
| Ohjeet |
|
| Kehittämismenetelmät _ | |
| Mallit |
|
| Merkittäviä lukuja |
|