Teknillinen korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija Lmodels Pariohjelmointi Tuomas Luttinen Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset 1.0 15.1.2004 Tuomas Luttinen Ensimmäinen palautettava versio 2.0 21.3.2004 Tuomas Luttinen Lopullinen raportti
Sisällysluettelo 1 Johdanto...1 1.1 Mitä on pariohjelmointi...1 1.2 Dokumentin tarkoitus...1 2 Pariohjelmointi...2 2.1 Pariohjelmoinnin ajatus...2 2.2 Pariohjelmoinnin edut...2 2.3 Pariohjelmoinnin haitat...2 3 Käyttö Lmodels-projektissa...3 3.1 Käyttötapa...3 3.2 Käytön onnistumisen arviointiperusteet...3 4 Tulokset pariohjelmoinnin käytöstä...4 4.1 Pariohjelmoinnin toteutunut käyttö Lmodels-projektissa...4 4.2 Pariohjelmoinnin mitatut tulokset...4 4.3 Mittauksen ja mittareiden ongelmat...4 4.4 Käyttäjien palaute...5 5 Yhteenveto...5
1 Johdanto 1.1 Mitä on pariohjelmointi Toisin kuin perinteisessä työtavassa, jossa jokainen ohjelmoija työskentelee yksin oman osuutensa kimpussa pariohjelmoinnissa työskennellään nimen mukaisesti tiiviinä parina saman ohjelmakoodin äärellä. Parin osapuolten roolit ovat aktiivinen ohjelmoija ja tarkkailija. Aktiivinen ohjelmoija tekee varsinaista koodin kehitystä ja kirjoitusta, kun taas tarkkailija tarkkailee jatkuvasti sekä pieniä yksityiskohtia, että miettii kokonaisuutta koettaen vähentää mahdollisia virheitä koodin syntyessä. 1.2 Dokumentin tarkoitus Tämän dokumentin tarkoituksena on antaa kuva pariohjelmoinnista ja kertoa sen käytöstä ja käytön hyödyllisyyden arviointiin käytettävistä mittareista, näiden mittareiden antamista tuloksista, ihmisten kokemuksista sekä näistä johdetuista johtopäätöksistä pariohjelmoinnin käytöstä ohjelmatyö-kurssin puitteissa Lmodels-projektissa. 1
2 Pariohjelmointi 2.1 Pariohjelmoinnin ajatus Pariohjelmoinnissa pari jäsenet siis toimivat kahdessa roolissa. Jäsenet ovat kuitenkin tasa-arvoisia, sillä rooleja vaihdetaan aika ajoin tarpeen mukaan. Jos tarkkaileva jäsen joutuu selittämään useamman lauseen verran ajatustaan, on parempi, että hän siirtyy aktiiviseksi ohjelmoijaksi näppäimistön ja hiiren ääreen toisen ihmisen taas siirtyessä tarkkailijaksi. Tarkkailijan tehtävänä on siis tarkkailla syntyvää tulosta niin pienten yksityiskohtien, kuten oikeinkirjoituksen ja koodin muotoilun osalta, kuin myös suuremman kokonaisuuden osalta, kuten rajapintojen oikeanlaisen käytön osalta sekä tekniseltä kannalta kuin myös ajatuksellisen tason kannalta. 2.2 Pariohjelmoinnin edut Pariohjelmointi tarjoaa useamman edun, joista suurin on koodin jatkuva katselmointi. Vaikka katselmointia pidetään vanhentuneena ja jäykkänä käytäntönä sillä on kuitenkin vahvat puolensa virheiden löytämisessä. Kun pariohjelmoinnissa se tehdään heti ja jatkuvasti, niin tälllöin se varmasti tulee tehtyä toisin kuin jälkikäteisenä käytäntönä. Kaiken kaikkiaan pariohjelmointia hyödyntäen tuloksena on vähemmän virheitä sisältävää ja selkeämpää koodia. Muita etuja pariohjelmoinnin käytössä on jatkuva tuki, jonka toinen henkilö vieressä tarjoaa. Vaikean ongelman tullessa vastaan on paikalla heti kaksi sitä miettivää ihmistä, joiden lähestymistavat varmasti eroavat toisistaan ja näin laajentavat kenttää, jolta ratkaisu voi löytyä. Vaikka ihmisten välillä olisi roima taitoero, niin silti toisen ihmisen läsnäolo antaa tukea, sillä hän todennäköisesti osaa kysyä juuri niitä vaikeita asioita, joihin vastaamiseksi taitavamman ihmisen pitää jäsentää asia selkeämmäksi ja paremmin ymmärrettäväksi kokonaisuudeksi päässään. Tällä tavalla myös molempien osapuolten tietämys projektin luonteesta ja sen yksityiskohdista kasvaa, jolloin ei synny koodia, jonka vain yksi ihminen ymmärtää ja osaa tarvittaessa sitä muuttaa tai korjata. 2.3 Pariohjelmoinnin haitat Pariohjelmoinnin haitalliset puolet liittyvät lähinnä sen aiheuttamiin ennakkoluuloihin ja inhimillisiin tekijöihin. Pariohjelmointi vaatii tosiaan tiivistä yhteistyötä, joten se ei välttämättä sovi kaikille ihmisille tai edes kaikille mahdollisille pareille, jotka saadaan aikaiseksi yhdistämällä pariohjelmointiin sopivia ihmisiä, koska henkilöiden keskinäisenkin kemian on pelattava. Pariohjelmointiin siirtyminen ei ole helppoa, koska ihmiset ovat tottuneet ohjelmoimaan yksin, joten siihen siirtyminen vaatii uusien tapojen omaksumista, mikä yleisesti on hidas prosessi. Myös työtä johtavilla ihmisillä saattaa esiintyä epäilyksiä pariohjelmoinnin tehokkuudesta, koska se helposti näyttää kaksikertaisten resurssien laittamiselta yhden ihmisen töihin, eikä sen antamaa tehokkuuden kasvua ongelmatilanteiden ratkaisuissa ja tarvittavan virheenkorjaamisajan pienenemisessä nähdä. 2
3 Käyttö Lmodels-projektissa 3.1 Käyttötapa Pariohjelmointia tullaan Lmodels-projektissa hyödyntämään järjestelmän sisäisten vaikeiden ja ratkaisevien kohtien toteutuksessa. Tälle on etenkin tarvetta, jotta projektiin liittyvää teknistä tietämystä pystyttäisiin jakamaan laajemmalle alalle, koska se on alunperin keskittynyt aika tiukasti vain parin ihmisen harteille. Pariohjelmoinnin kohteeksi valitaan eri vaiheissa tiettyjä järjestelmän osia, joita toteutetaan joko kokonaan saman parin voimin tai sitten kolmen ihmisen voimin siten, että nämä ihmiset sopivat keskenään ohjelmointiaikoja, jolloin pariohjelmoidaan uutta koodia työn alla olevan osan toteuttamiseksi ja parit vaihtuvat aina ohjelmointikerrasta toiseen. Jotta pariohjelmoinnille olisi olemassa vertailtavaa tuotosta myös perinteistä yksinohjelmointia käytetään koko projektin ajan pariohjelmoinnin rinnalla. 3.2 Käytön onnistumisen arviointiperusteet Pariohjelmoinnin käyttöä tullaan arvioimaan erilaisin mittarein. Jotta vertailutilanne olisi mahdollisimman selkeä, pyritään vertailuun ottamaan sekä pariohjelmoitua että yksinohjelmoitua koodia selkeästi uusia toiminnallisuuksia lisäävistä koodikokonaisuuksista. Näitä tullaan vertailemaan sekä niihin käytetyn ajan, niiden sisältämän koodin kuin niistä raportoitujen ja korjattujen virheidenkin osalta. Ensimmäinen kysymys pariohjelmoinnin kohdalla on sen tuottavuus jo uuden koodin kirjoittamisen kohdalla. Pariohjelmoinnin olisi tarkoitus jopa lisätä tuottavuutta mitattavissa määrin vaikkei virheiden korjaukseen kulunutta aikaa laskettaisikaan vielä pariohjelmoinnin hyödyksi. Tätä mitataan laskemalla vertailuun otetuista moduleista koodirivimäärät per modulin tuottamiseen käytetty henkilötyötuntimäärä sekä pariohjelmoinnille että perinteiselle yksinohjelmoinnille vastaavat luvut kaikkien vertailuun otettujen modulien osalta. Toisekseen pariohjelmoinnin virheitä vähentävää vaikutusta mitataan laskemalla raportoidut virheet näissä moduleissa ja jakamalla ne moduulien yhteenlasketulla rivimäärällä, jotta saadaan sekä moduleille lasketut että projektille kummankin ohjelmointitavan osalta lasketut virhettä per rivimäärä -luvut. Kolmantena asiana mitataan kokonaistaloudellisuutta, eli mukaan vertailuun otetaan vielä yllä laskettujen virheiden korjaamiseen käytetty aika, joka lisätään kunkin modulin työmääriin. Näin lasketaan vielä toiset rivimäärä per henkilötyötuntimäärä -luvut, jotka siis kuvaavat kokonaistaloudellisuutta pariohjelmoinnin ja yksinohjelmoinnin kohdalla. 3
4 Tulokset pariohjelmoinnin käytöstä 4.1 Pariohjelmoinnin toteutunut käyttö Lmodels-projektissa Pariohjelmoinnin määrä jäi ehkä hieman alakanttiin suunnitellusta. Järjestelmällisesti sitä hyödynnettiin translaattorin ja linearisaattorin toteuttamisessa. Translaattorilla tarkoitetaan tässä sitä kokonaisuutta, jonka muodostavat pakettien model ja nodes luokat ja niitä formats- ja prosessors-pakettien luokkia, joilla saadaan aikaan mallin luku tiedostosta, sen syntaksipuun muodostaminen ja normalisointi. Ehkä projektin järjestelyt eivät edesauttaneet pariohjelmointia, kun ihmiset eivät yleisesti olleet samaan aikaan samassa paikassa tekemässä töitä, mutta silti epäilisin, että muutosvastarinta oli suurin syy siihen, että pariohjelmointia ei käytetty kuin sellaisissa tapauksissa, joissa itse olin parin toinen osapuoli. Pariohjelmoinnin ajatuksenahan nimenomaan on ajatus vaihtaa pareja aika ajoin, joten voisi olettaa, että seitsemän ihmisen joukosta kaksi saataisiin samaan paikkaan tekemään samaa asiaa hieman helpommin kuin kaikki seitsemän paikalle. Mittareilla tehtävää vertailua varten valittiin edellä mainitut kaksi pariohjelmoitua pakettia ja niiden vastapariksi kaksi muuta kokonaisuutta. Näiksi kahdeksi muuksi kokonaisuudeksi valikoituivat ratkaisija, eli käytännössä solver-paketin sisältämät luokat ja yhden luokan kokonaisuus LPXFormat, joka tulostaa mallin LPX-kielelle, jota useampikin lineaaristen ongelmien ratkaisija pystyy lukemaan. Valitaperustana käytettiin kummankin kohdalla yksinohjelmoitua yhtenäistä teknistä kokonaisuutta. Ensimmäisenä tuli valituksi ratkaisija suurempana kokeneen ohjelmoijan tekemänä kokonaisuutena. Tätä tasapainottamaan otin LPX-kirjoittimen, koska se on selkeästi rajatun ongelman ratkaiseva kokonaisuus ja projektipäällikkömme kirjoittamaa koodia, eli projektin keskivertoa kokemattomamman ohjelmoijan tekemä luokka. 4.2 Pariohjelmoinnin mitatut tulokset Yllämainitut osat projektia valikoituivat siis mittausten kohteiksi ja niille tehtiin suunnitellut mittaukset. Seuraavassa taulukossa on esitetty tulokset kunkin modulin toteutusiteraation tulokset. Moduli Koodirivit Työtunnit/ toteutus Bugit Työtunnit/ kloc Bugit/ kloc Linearisaattori 340 32 8 94,12 23,53 Translaattori 1021 48 17 47,01 16,65 Ratkaisija 706 36 3 50,99 4,25 LPX-kirjoitin 151 5 0 33,11 0 Tässä vertailussa on koodiriveinä otettu huomioon vain toiminnalliset koodirivit, ei siis kommentteja. Työtunteihin on laskettu iteraation aikana tehdyt työtunnit kunkin moduulin kohdalta, pariohjelmoinnissa tietenkin kahdelta ihmiseltä yhteenlasketut tunnit. Bugien 4
määrä on saatu virheiden seuraamisjärjestelmästä laskemalla kunkin kokonaisuuden kohdalle raportoidut virheet. Näiden lukujen perusteella ei näytä siltä, että pariohjelmointi olisi erityisen tehokasta koodin tuottamiseen, toisaalta ei myöskään mahdottoman tehotontakaan. Virheitä pariohjelmointi ei näyttäisi pystyvän vähentämään. Seuraavassa taulukossa on huomioon otettu kunkin modulin kohdalla tehty työ varsinaista toteutusta seuraavassa iteraatiossa, jossa on tehty virheiden korjausta ja edelleen uutta kehitystyötä. Moduli Koodirivit korjattuna Työtunnit/ korjaus Bugit Kokonaistyötunnit/ kloc Bugit/ kloc Linearisaattori 355 19 N/A 143,66 N/A Translaattori 1057 9 N/A 53,93 N/A Ratkaisija 706 1 N/A 52,41 N/A LPX-kirjoitin 151 0 N/A 33,11 N/A Näiden lukujen valossa näyttää katoavan viimeinenkin toivo siitä, että pariohjelmoinnilla olisi saavutettavissa tehokkuushyötyä edes virheiden vähäisemmän määrän ja niiden varhemmasta havaitsemisesta johtuvan korjausajan pienenemisen myötä tämän projektin parissa. 4.3 Mittauksen ja mittareiden ongelmat Pariohjelmoinnin edut eivät siis tulleet tässä projektissa esiin mitattavissa määrin. Yksi suuri syy tähän on varmasti mittausaineiston epätasaisuus; pariohjelmointia nimenomaan käytettiin juuri niissä suuritöisissä vaikeissa osakokonaisuuksissa, joissa yksinohjemoiden olisi myös mennyt suuri määrä tunteja per aikaansaatu koodirivi, kun taas yksinohjelmointia käytettiin tuottamaan suurehkojakin nopeasti kirjoitettavia koodimääriä esimerkiksi tekstinkäsittelyyn ja käyttöliittymään. Valitettavasti myöskään projektin tunti- ja bugiraportointi ei ollut aivan riittävän tarkkaa, jotta olisin voinut saada loppuun asti luotettavia lukuja bugeista ja niihin kuluneista korjaustunneista. Yllä olevat virhemäärät on saatu projektin virhejärjestelmästä, jonne ei ole talletettu kaikkia virheitä, vaan vain ne vakavammat, joita ei ole heti pystytty korjaamaan. Myöskään modulin toteutusiteraatiota seuraavassa iteraatiossa olevista tunneista ei pystynyt päättelemään onko ne käytetty bugien etsimiseen ja korjaamiseen vaiko mahdollisesti modulin edelleen kehittämiseen. Vaikka tässä on nyt valitettu yhtä ja toista mittaamista vaikeuttaneista tekijöistä, niin yhtä asiaa on vasta sivuttu; tähän mennessä ei ole vielä pystytty kehittämään yleisiä ja yksiselitteisiä mittareita projektien monimutkaisuudelle, työläydelle ja laadukkaalle lopputulokselle. Tässä käytetty rivimäärä on kuitenkin vain kompromissi, jonka tuottamisen vaativuus voi olla eri tilanteissa peräti erilainen, kuten yllä on jo vihjattu. Ja paras mahdollinen ohjelmakoodi ei varmastikaan ole pisin mahdollinen vaikka tuottavuutta mitattaisiinkin henkilötyötunnissa tuotetun rivimäärän perusteella. 5
4.4 Käyttäjien palaute Edellä olevasta voi jo päätellä, että pariohjelmointiin osallistuneiden määrä oli vähäinen ja näin ollen palautettakin tuli vain parilta ihmiseltä. Tällaisesta otoksesta ei voi mitään yleisiä johtopäätöksiä tehdä, joten nämä kokemukset kuvaavat pariohjelmointia tämän projektin puitteissa. Yleisesti ottaen palaute oli positiivista. Pariohjelmointi nähtiin tapana saada alkuun uusi teknisesti vaikea projekti, johon käyvillä tekijöillä ei ole kovin suurta kokemusta projektin vaatimasta tietotaidosta. Toisekseen sen nähtiin tuovan hyötyä monimutkaisen komponentin toteutuksen aikana tehtävien virheiden vähentämisessä. Palaute oli yksimielisen epäluuloinen pariohjelmoinnin tehokkuushyödystä, jopa osin virheenkorjaamisajan vähentämisen huomioiden. Totta tietenkin, että tämä tapa ei sopine projektiin, joka on pystytty määrittelemään hyvin ja missä koko henkilökunta on tehtäviensä tasalla. Vaikka pariohjelmointia tässä projektissa käytettiinkin välillä kahden huomattavasti eri tasoilla olevan ihmisen kanssa, ei sen hyötyä tietotaidon siirtäjänä nähty, vaan todettiin sen sopivan paremmin tilanteeseen, jossa parin molemmat osapuolet ymmärtävät mitä ollaan tekemässä. 6
5 Yhteenveto Vaikka tämä kokeilu ei mittareiden mukaan kovin hyvin mennytkään, niin silti pidän sitä opettavaisena kokemuksena. Ehkä tämän harjoituksen tärkein opetus on että laadun tuominen ohjelmistotuotantoon ei ole käytännössä mitenkään helppoa, eikä siihen ole mitään yksikäsitteisiä oikoteitä, vaan kyse on kokonaisvaltaisesta prosessista, jonka yhtenä osana voidaan pariohjelmointia käyttää. Tämä projekti tuskin olisi kaatunut, vaikka pariohjelmointia ei olisikaan ollenkaan käytetty, mutta mikäli kaikki muutkin ohjelmistotuotantonnon menetelmät olisi projektista karsittu, olisi yhteisvaikutus saattanut jo riittää koko projektin kaatamiseen. Toinen opetus mitä tämä kokeilu, ja koko muukin kurssi tässä ohessa, antoi, on psykologisen pelisilmän kehittyminen havaitsemaan eri ihmisten ominpia toimintatapoja ja muutosvastarinnan vahvuus näitä tapoja muutettaessa. Mikäli ihmisellä itsellään ei ole halua eikä järkeviä syitä nähtävissä muuttaa tapojaan, niin ei niiden tapojen muuttaminen ulkopuoleltakaan onnistu. 7