Johdanto 1. Projektille esiteltävä versio. Kokemukset ja muutokset 3. Projektille esiteltävä versio. Iteraatio 2., suunnitelma

Transkriptio

1 SEPA päiväkirja BetaTeam Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus Juho Mäkinen Johdanto J.Mäkinen, Käytäntöön soveltaminen 2. J.Leppä Juho Mäkinen Projektille esiteltävä versio J Mäkinen Kokemukset ja muutokset J Mäkinen J Mäkinen J Mäkinen Projektille esiteltävä versio Iteraatio 2., suunnitelma Iteraatio 2. kokemukset

2 SEPA päiväkirja Pariohjelmointi Juho Mäkinen, 57796V & Jari Leppä, 42710V Sisältö 1. Johdanto 2. Käytäntöön soveltaminen 3. Kokemukset 1. Johdanto Me valitsimme SEPA aiheeksemme pariohjelmoinnin. Tämä on ohjelmointitekniikka jossa kaksi kehittäjää toimii saman tietokoneen ääressä, toinen aktiivisesti ohjelmoiden ja toinen vierestä seuraten ja kommentoiden. Ohjelmoijat vaihtavat säännöllisin väliajoin roolejaan, ja näin ohjelmakoodi syntyy ohjelmoijien tiiviin yhteistyön tuloksena. Pariohjelmointi on osa laajempaa Extreme Programming käytäntöperhettä. Katsomme että pariohjelmointi tuo monenlaisia hyötyjä ohjelmistokehitykseen. Virheiden määrä ohjelmakoodissa vähenee, kun koodia tarkkailee kaksi silmäparia yhden sijasta. Myös vaikeat solmukohdat ratkeavat helposti kun niitten ratkaisusta voi keskustella parin kanssa ja vaihtaa erilaisia mielipiteitä erilaisten ratkaisumenetelmien hyödyllisyydestä. Parhaimmillaan pariohjelmointi on silloin kun toinen ohjelmoija on huomattavasti kokeneempi kuin toinen. Tällöin ohjelmoijien välillä on eräänlainen mestari oppipoika -suhde, jolloin kokemattomampi ohjelmoija pääsee näkemään miten kokenut kollega ratkaisee erilaisia käytännön ongelmia. Myös kokenut ohjelmoija saattaa saada kokemattomammalta uudenlaisia ratkaisuehdotuksia joita hän ei ole aiemmin osannut ottaa huomioon. Pariohjelmointi edesauttaa hyvää työmoraalia ja motivaatiota, halukkuus pitää taukoja kesken työn on pienempi ja fokusoituminen ongelmanratkaisuun on korkeampi. Pariohjelmointiin liittyviä artikkeleita olemme lukeneet internet sivulta Erityisesti Professori Randall W. Jensen:in artikkelia osoitteessa pidimme erittäin informatiivisena. Tarkastelimme myös artikkelia: Wikipedia, Pair Programming

3 2. Käytäntöön soveltaminen Hajautettu projektimme aiheuttaa haastetta pariohjelmoinnin käytäntöön soveltamisessa. Projektillamme ei ole vakituista yhteistä toimipaikkaa, kuten esimerkiksi oikeassa työelämässä yleensä on. Asiakkaamme on kuitenkin antanut käyttöömme yhden kannettavan työaseman, joka tässä tapauksessa korvaa puutetta. Toinen rajoitteemme on, että projektiryhmässämme on vain kolme kehittäjää. Kolme on sekä pieni että pariton lukumäärä. Päätimme edellä mainituista huolimatta testata menetelmää tässä projektissa, koska oletamme sen kuitenkin antavan kokemusta kyseisestä käytännöstä tämänkin kaltaisessa ympäristössä. Projektimme teknologiassa on osuuksia, joista ei kenelläkään ole tietämystä. Päätimme soveltaa pariohjelmointia näissä kohteissa. Myös testauksessa näimme mahdollisuuden hyödyntää paritestausmenetelmää. Lopuksi myös integraatiovaiheessa aiomme soveltaa pariohjelmointia. Pariohjelmoinnin ajatus on, että toinen parista on aktiivinen ja toinen häntä tukeva ohjelmoija. Roolit vuorottelevat sessiosta toiseen. Sessio projektissamme tarkoittaa kahden tunnin yhtämittaista työskentelyjaksoa, jonka jälkeen roolit vaihdetaan. Uuden työjakson alussa roolit on aina vaihdettava. IMPLEMENTAATIO I Suunnitelma Viikolla 46 Ohjelmointi; Fortran osuuksia; asiakkaan nykyjärjestelmän ohjelmakoodin muokkausta Systeemi-integraatio o Kauko ja Raine Testaus; buildin integraatiotestaus Viikolla 47 o Kauko ja Raine Testaus; Integraatiotestaus Viikolla 48 o Kauko ja Raine Testitapausten suunnittelua Testitapausten suunnittelua

4 IMPLEMENTAATIO II Suunnitelma Viikolla 3 ja 4 o Requirement F6: Query generating for specific data objects by user options Viikolla 3 ja 4 o Requirement F7: Query to partially match an object s contents Viikolla 4 ja 5 o Tietokannan valinta Napan käyttöliittymässä Viikolla 6 ja 7 o Paritestaus o Kauko Juho 3. Kokemukset ja muutokset 3.1 Projektin suunnittelu Projektin aloitusvaiheessa SEPA aihe ei ollut vielä selvillä. Uskomme myös, että pari ohjelmointi metodia ei olisi voinutkaan hyödyntää projektin suunnittelussa. 3.2 Implementaatio 1 Saimme myönteisiä kokemuksia niistä ohjelmointiosuuksista, joihin olimme aikoneet soveltaa pari-ohjelmointia. Erityisesti asiakkaan Fortran koodin muokkaamisessa oli eniten etua tästä menetelmästä, koska kyseinen ohjelmointikieli ei ollut kummallekaan entuudestaan tuttua. Taustatekijöistä voimme todeta, että molemmat ohjelmoijat olivat samalla lähtötasolla Fortranin suhteen. Kokonaisuudessaan koko asiakkaan järjestelmä oli tuntematon, joten menetelmä tarjosi hyötyä myös siihen tutustumisessa. Käytännössä tuli todetuksi, että inhimillisistä syistä johtuen ei aina ollut selkeää roolijakoa aktiivisen ja tätä tukevan ohjelmoijan välillä. Toisinaan syntyi tilanne, että näppäimistöllä oli enemmänkin kuin sallitut kaksi kättä. Edellä mainittuun pyrittiin kuitenkin reagoimaan.

5 Koska kumpikin ohjelmoija oli samalla kokemustasolla, niin tässä tapauksessa ei voitu havaita mestari-oppipoika pariohjelmointihyötyjä. Yleisesti ottaen projektissa käytettiin Java-ohjelmointikieltä. Koska molemmat ohjelmoijat olivat kokeneita Java ohjelmoijia, niin pariohjelmointia ei nähty välttämättömäksi soveltaa näissä osuuksissa. Toisaalta tätä rajoitti myös hajautetun projektin luonteesta johtuvat olosuhdetekijät. Tekemämme suunnitelma ei täysin täsmännyt siihen, miten toteutus syntyi. Ohjelmointitehtävät Fortranin osalta suoritettiin, kuten oli ajateltu. Systeemi-integraatiota ei kuitenkaan varsinaisesti sisältynyt projektiin, vaikka olimme niin olettaneet. Testauksen osalla aiheutui suurimmat poikkeamat suunnitelmaan, koska esimerkiksi testitapausten suunnitteluun ei käytännön syistä voitu käyttää tätä filosofiaa. Projektin osalta testaus viivästyi joka tapauksessa, ja lopulta ei jäänyt riittävästi aikaa käydä tätä menetelmää lävitse. Toisessa vaiheessa meillä on enemmän siinä tarvittavia resursseja toteutuksen suunnitteluun. 3.3 Implementaatio 2 Kokemuksemme toisella iteraatiokierroksella olivat suurelta osin saman kaltaisia kuin ensimmäisellä kierroksellakin. Java ohjelmointikieltä sisältäneet ohjelmointiosuudet toteutettiin erillistyönä kuten aiemminkin. Fortrania ja C-kieltä käsittäneet osat suoritettiin osittain pariohjelmoiden, koska kyseiset kielet eivät olleet kovinkaan tuttuja. Suurin osa käytetystä pariohjelmointiajasta kohdistui ohjelmavirheiden metsästämiseen, jolloin toinen pariohjelmoija toimi koodin review osapuolena. Esimerkkinä mainittakoon Fortrankoodissa ollut virhe, jonka löytäminen oli poikkeuksellisen hankalaa yksinään toimineelle ohjelmoijalle havaittiin pariohjelmoidessa hyvin tehokkaasti. Suunnitelma ei toteutunut aivan täsmällisesti, koskien ennakkoon oletettuja aihealueita. Suunnitelmaan aiheutti eniten poikkeamaa ennakoimaton EXE käännösongelma, joka aiheutti päänvaivaa kehittäjille. Tässä pariohjelmointia käytäntöön sovellettaessa ongelma saatiin kuitenkin hyvin haltuun. Implementoiduista vaatimuksista toteutettiin pariohjelmointimetodia käyttäen F6 (Requirement F6: Query generating for specific data objects by user). Tietokannan valinta Napan käyttöliittymästä ratkesi (Requirement F16) samassa yhteydessä ponnisteltaessa EXE käännöksen kansa. Paritestauksen osalta emme odotuksistamme huolimatta saaneet käytännön kokemuksia. Syynä tähän keskeisimmin saattoi olla koordinoinnissa olleet puutteet projektin tehtävien jakautumisessa, josta emme syytä kuitenkaan mitään osapuolta.

6 3.4 Yhteenveto Sepan aikataulusta johtuen, emme päässeet soveltamaan pariohjelmointia täysipainoisesti 1. implementaatiossa. Käyttöönottaminen tapahtui vasta ensimmäisen iteraatiokierroksen puolivälissä. Toisen kierroksen aikana olemme ottaneet menetelmän alusta lukien huomioon. Eritoten uuteen järjestelmään perehdyttäessä, totesimme pariohjelmoinnista olevan eniten hyötyä. Menetelmä todettiin joka tapauksessa tutustumisen ja kokeilemisen arvoiseksi. Toisen kierroksen kuluessa pääsimme hyödyntämään pariohjelmointia huomattavasti konkreettisemmin. Myös jälkimmäisessä iteraatiossa kokemukset olivat vähintään yhtä myönteisiä kuin aiemmin. Tulevaisuutta silmällä pitäen kokeilusta jäi hyvä maku. Miettimisen aihetta tuotti kuitenkin se, että onko usein järkevää asettaa kahta ohjelmoijaa saman ongelman kimppuun. Perinteinen individuaalinen ohjelmointitapa saattaa olla silti mahdollisempi soveltaa kuin pariohjelmointi. Työn tuottavuus voi olla kahden summaa pienempi, silloin kun käsillä oleva ongelma ei ole kovin monimutkainen.