SEPA diary. Dokumentti: SEPA_diary_PK_RI.doc Päiväys: Projekti : AgileElephant

Transkriptio

1 AgilElephant SEPA Diary Pasi Kallioniemi 49477B Rauli Ikonen 51051V Tekijä: Kallioniemi&Ikonen Omistaja: ElectricSeven Aihe: RI & PK Sivu 1 of 11

2 Dokumenttihistoria Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision tekijä Ensimmäinen versio (kuvaus menetelmästä). Rauli Ikonen Päivitetty dokumenttia johdannon ja rakenteen osalta. Pasi Kallioniemi Lisätty I1-vaiheen teksti Rauli Ikonen Dokumentin rakennetta muutettu Esa Mommo I2-vaiheen kokemuksista kompleksisuusmittarien näkökulmasta Pasi Kallioniemi I2-koodikatselmoinneista ja FindBugsista Rauli Ikonen FD-vaiheesta ja yhteenvetoa kompleksisuusmittareihin. Pasi Kallioniemi Pientä viilausta Rauli Ikonen Hyväksyjät Tämä dokumentti vaatii seuraavien henkilöiden hyväksymiset Nimi Rauli Ikonen Pasi Kallioniemi Tehtävä Jakelu Tämä dokumentti jaetaan seuraaville henkilöille Nimi Projektiryhmä Seppo Sahi Tehtävä Mentor Aihe: RI & PK Sivu 2 of 11

3 Sisällysluettelo 1. Esittely Tarkoitus Menetelmän kuvaus Viitteet Käyttöönotto Kokemukset ja muutokset PP-vaihe I1-vaihe I2-vaihe FD-vaihe Yhteenveto...9 Liite A: FindBugs virhekoodit...11 Aihe: RI & PK Sivu 3 of 11

4 1. Esittely 1.1 Tarkoitus Tämän dokumentin tarkoitus on kuvata AgilElephant projektissa käytettyä SEPA (Software Engineering Practice Assignment)-menetelmää. Menetelmä esitellään ja perustellaan luvussa 1. Luku 2 sisältää suunnitelmat menetelmän käyttöönotolle. Lukuun 3 kirjataan kokemuksia ja havaintoja menetelmän hyödyistä ja sopivuudesta projektin tarpeisiin. 1.2 Menetelmän kuvaus SEPA aiheenamme on staattiset metodit koodianalysoinnnissa. Staattinen koodianalysointi tarkoittaa ohjelmakoodin analysointia ilman että koodi ajetaan. Mahdollisia analysoitavia asioita ovat koodin laatu (rakenne, koko, viittaukset moduulista toiseen jne..), ohjelmakoodin virheet sekä koodin oikeellisuus tehtävien toiminnallisuuksien kannalta. Yleisesti staattista koodianalyysiä voidaan tehdä automatisoidusti työkaluilla tai ihmisten tekemänä, esim. koodikatselmuksilla. Automatisoidussa staattisessa analysoinnissa käytetään työkaluja jotka laskevat erilaisia mittareita ohjelmakoodista ja luovat niistä raportteja varoittaen ohjelmakoodin huonosta laadusta tai virheistä. Käytettyjä mittareita ovat mm. metodissa/luokassa olevan koodin rivimäärä, yhden luokan viittausten määrä moduulista toiseen, sekä McCaben syklomaattinen kompleksisuus (ohjelmakoodin haarautumisluku). Myös bugeja voidaan analysoida koodista ohjelmilla jotka esim. ensin tekevät koodista vuokaavion ja analysoivat tämän avulla onko mahdollisuuksia ikuisiin silmukoihin tai rinnakkaisuusongelmiin. Raporttien tekeminen ei ole ainoa vaihtoehto automatisoinnille, sillä nykyisin osa työkaluista pystyy integroitumaan käytettävään kehitysympäristöön ja antamaan ohjelmoijalle suoraan palautetta hänen kirjoittaessaan koodia. Koodia ei välttämättä voida analysoida kattavasti automatisoituna. Tällöin analysointiin käytetään ihmisiä. Koodikatselmus on tekniikka jolla pystytään levittämään tietämystä koodien toiminnasta usealle henkilöille projektissa, samalla varmistaen että tehty toiminnallisuus on selkeä sekä toimiva. Uuden ominaisuuden katselmoinnissa valitaan joukko ihmisiä tekemään katselmointia. Tällöin henkilö(t) käyvät tehdyn ominaisuuden lävitse tekijän opastuksella, ja he esittävät tekijälle kysymyksiä epäselvistä kohdista ja kommentoivat koodia. Toiminta perustuu siihen että tekijästä tulee helposti sokea omille virheilleen ja on mahdollisesti jumittunut tottumuksesta johonkin huonoon koodaustyyliin, joten ulkopuolisten ihmisten antama palaute toimii kehittävänä tekijänä virheiden paljastuksen ohella. Valitsimme tämän aiheen siksi että koimme sen tarjoavan hyvän ja realistisen mahdollisuuden parantaa ohjelmakoodin laatua tällä kurssilla tehtävässä projektissa. Lisäksi staattinen koodianalysointi on mielestämme mielenkiintoinen alue johon kumpikaan meistä ei ole vielä työelämässä päässyt tutustumaan. Toivomme että asia osoittautuu vaivan arvoiseksi ja tämän kurssin jälkeen osaamme soveltaa sitä työelämässä menestyksekkäästi. Aihe: RI & PK Sivu 4 of 11

5 1.3 Viitteet Staattinen analyysi: Finding faults in multi-threaded programs, Cyrille Artho 2001; Koodikatselmukset: Practical Software Testing. Ilene Burnstein Aihe: RI & PK Sivu 5 of 11

6 2. Käyttöönotto Tulemme integroimaan staattisia koodianalysointityökaluja kääntöympäristöömme niin, että työkalut ajetaan automaattisesti päivittäisen käännöksen yhteydessä ja saadut tulokset liitetään kääntöjärjestelmän luomaan raporttiin. Järjestelmään integroitavat työkalut ovat FindBugs ja JavaNcss. Edellinen hakee koodista automaattisesti yleisiä ohjelmointivirheitä ja jälkimmäinen laskee koodista kompleksisuustunnuslukuja. Lisäksi tulemme ajamaan satunnaisesti JLint-työkalua ja mahdollisesti Teaminaboxia. Näitä ei kuitenkaan integroida buildijärjestelmään. Sen lisäksi, että FindBugsin löytämät virheet korjataan, tullaan virheet myös kategorisoimaan asteikolla vähäinen (ei mahdollisesti lainkaan virhe), normaali ja vakava. Lisävirheiden löytämiseksi tulemme suorittamaan koodista kaksi kahden tunnin koodikatselmointia, toinen vaiheen I1 ja toinen vaiheen I2 lopussa. Katselmoinneissa löytyneet virheet kategorioidaan kuten automaattityökalujen löytämät virheet. Vaiheen I2 jälkeen tulemme analysoimaan löytyneet ongelmat, käyttäen pohjana koodin kompleksisuusmittareita: Korreloiko löytyneiden virheiden määrä suhteessa luokkien ja metodien kompleksisuuksiin. Ottaen huomioon kehitettävän järjestelmän suhteellisen pienen koon ja staattiseen koodianalyysiin käytettävissä olevan varsin rajallisen ajan, on mahdollista, että virheitä ei löydy niin paljon, että niistä voisi tehdä mielekästä tilastollista analyysiä. Jos näin käy rajoittuu menetelmän hyöty lähinnä koodin parempaan laatuun sekä raportointiin kokemuksista staattisista koodianalyysityökaluista yleensä. Virheiden korjaamisen ja kompleksisuuteen pohjautuvan analysoinnin lisäksi tulemme vaiheen I2 loppupuolella käyttämään noin neljä tuntia koodin refaktorointiin. Refaktoroitavat osat valitaan JavaNcss:n tuottamien kompleksisuusmittarien ja oman harkinnan pohjalta; refaktoroitavaksi päätyvät kompleksisuudeltaan suurimmat metodit mitkä vaikuttavat myös asianomaisista kaikkein vaikeaselkoisimmilta. Tälläkin pyritään luonnollisesti ohjelman laadun ja jatkokehityksen parannettavuuteen. Aihe: RI & PK Sivu 6 of 11

7 3. Kokemukset ja muutokset 3.1 PP-vaihe Staattisia menetelmiä ei sovellettu vielä tässä vaiheessa. 3.2 I1-vaihe I1-vaiheessa integroitiin sekä JavaNcss että FindBugs buildijärjestelmän osaksi. Järjestelmä ajaa molemmat työkalut joka yö normaalin käännöksen yhteydessä ja laittaa tulokset esille osoitteeseen Koska järjestelmän todellinen implementointi alkoi vasta iteraation aivan loppupuolella, ei tämän iteraation puitteissa vielä voitu tehdä mitään erityistä analyysiä virheistä tai luokkien kompleksisuuksista. Ainakin FindBugs kuitenkin osoitti jo hyödyllisyytensä löytämällä kolme todellista virhettä (SA, UwF, DE) sekä neljä validia huomautusta huonosta rakenteesta ja tehottomasta koodista (EI, EI2, Dm, RCN). Kaikkien löydettyjen varsinaisten virheiden vakavuusaste oli normaali. Kaksi rakennevirhettä (EI, EI2) esiintyi yhteensä 22 kertaa. (Tarkempi listaus virhekoodeista ja virheistä lisätään I2-vaiheessa.) I1-vaiheessa oli alkuperäisen suunnitelman mukaan myös tarkoitus suorittaa koodikatselmus. Johtuen implementaation myöhäisestä alkamisajankohdasta ei koodikatselmointia ehditty suorittaa tässä vaiheessa. I1-vaiheen koodikatselmus siirretään tästä johtuen I2-vaiheen puoliväliin ja I2-vaiheen loppuun suunniteltu katselmus suoritetaan FD-vaiheen puolivälissä. 3.3 I2-vaihe I2-vaiheessa järjestelmän laajentuessa tarkkailimme valitsemiamme mittareita. Kompleksisuusluvut näyttivät hyvin pitkälti pysyvän maltillisissa arvoissa. Olimme sopineet alustavasti että kompleksisuusarvot jotka ovat yli 20, niitä seurataan tarkemmin (JavaNcssraporteissa metodit on järjestetty kompleksisuuden mukaan ja yli 20 menevät arvot näkyvät punaisina). Kahdenkymmenen raja perustui SEI:n yhdelle suositusmallille kompleksisuuden ja mahdollisen riskin vertaamiselle. (Lähde: Cyclomatic Complexity Risk Evaluation 1-10 a simple program, without much risk more complex, moderate risk complex, high risk program Aihe: RI & PK Sivu 7 of 11

8 greater than 50 untestable program (very high risk) Mutta kuitenkaan mitään ehdottomia ala/ylärajoja emme mielestämme voineet määrittää koodeille koska kyseinen mittari on hyvinkin tapauskohtainen ja muutenkin näihin ohjearvoihin pitää suhtautua mielestämme varauksellisesti. Perusteluksi tälle olivat omat kokemuksemme ohjelmistojenkehityksessä ja erityisesti sen tilannekohtaisesta vaihtelevuudesta. Muutamat metodit I2-vaiheen kuluessa olivat kylläkin arvoiltaan jo paljon ylitse kahdenkymmen rajan: BacklogItemManagerBean.changeBacklogItemStatus(), CCN=48 CycleManagerBean.getPortfolioReleases(), CCN=33 GetPortfolioDetails.doStartTag(), CCN=29 Tarkastelun jälkeen emme kuitenkaan päätyneet refaktoroimaan mitään näistä metodeista mm. seuraavista syistä johtuen. changebacklogitemstatus on metodi, jota kutsutaan RMI-rajapinnan lävitse web-palveluista. Sen tarkoituksena on muuttaa yhden backlogitemin tilaa toiseen jos annettu tila on mahdollinen. Metodissa on hyvin paljon lisätarkistuksia parametrien oikeellisuudesta ja annetun tilan vaihdoksen mahdollisuudesta. Ne eivät kuitenkaan haarauta ohjelman tilaa metodin sisällä vaan suuri osa näistä ehdoista aiheuttaa poistuman metodista virheilmoituksen kera. Kyseessä on siis enemmänkin hyvin vikasietoinen koodi kuin erittäin monimutkainen. getportfolioreleases-metodi sisälsi myös kohtalaisesti tarkistuksia, mutta korkeaan lukuun sisältyi muu syy. Kyseinen metodi hakee kaikki release-tiedot jotka liittyvät yhteen portfolioon. Tämä olisi kuitenkin ollut yhtenä tietokantahakuna todella monimutkainen joten koodissa oli päädytty ratkaisemaan tämä ohjelmallisesti, eli järjestämään ja filtteroimaan tulosjoukko ohjelmakoodissa. Eli loppujen lopuksi tässä metodissa oli tehty tietoinen valinta ratkaisun monimutkaisuudesta, mutta silti se nähtiin kannattavammaksi tavaksi tehdä näin. dostarttag-metodissa oli kyseessä hausta ja haun tuloksien tallentamisesta jsp-sivun käytettäväksi. Tässä toistui sama syndrooma kuin changebacklogitemstatus-metodissa, eli tehtiin hyvin paljon tarkistuksia parametrien arvoista. Lopuksi voidaan todeta että yleisestikin tuntuu siltä että kompleksisuusmittarit voivat helposti saada kohtalaisen suuria lukuja web-pohjaisessa ohjelmoinnissa jossa täytyy tarkistaa käyttäjän antamien parametrien kelpoisuutta, muokata niitä esitettävään muotoon, sekä tehdä myös sisäistä virhetarkistusta. Edellä mainittujen korkean kompleksisuuden omaavien metodien lisäksi katselmoimme useita muita kohtia koodista. Valitut kohdat olivat lähinnä satunnaisia pyrkien saamaan mahdollisimman suuren variaation. Kirjattaessa virheitä pyrittiin kiinnittämään huomiota virheen sisältävän luokan ja metodin kompleksisuusmetriikoihin mahdollisen korrelaation havaitsemiseksi. Katselmoinnin yhteydessä löytyi seitsemän virhettä. Virheistä kolme oli vakavia ja ne aiheuttivat järjestelmän kannalta vakavaa virheellistä toimintaa. Kaksi virhettä eivät aiheuttaneet käyttäjille näkyviä virheitä, vaan aiheuttivat turhan tiedon tallentamista tietokantaan. Kaksi virhettä ei nykyisellään aiheuttanut lainkaan virhettä, mutta olisivat voineet helposti johtaa kyseessä olleen ominaisuuden toimimattomuuteen toisaalla tapahtuvien muutosten johdosta. Aihe: RI & PK Sivu 8 of 11

9 Virheiden esiintymispaikan ja kompleksisuusasteen välillä ei ollut havaittavissa mitään korrelaatiota. Toki otoskin jäi niin pieneksi, ettei mitään tilastollista yhteyttä olisi voinut kovin vakaalla pohjalla esittää. Sen sijaan koodin kirjoittajan ja virhetodennäköisyyden välillä oli selvästi havaittava yhteys. Ohjelmointia suorittaneista henkilöistä yhdellä oli vastaavista järjestelmistä paljon kokemusta, kahdella jonkin verran ja kolmella varsin vähän. Kaikki virheet löytyivät niiden henkilöiden kirjoittamista koodeista kenen kokemus vastaavista järjestelmistä tai yleensä käytetystä ohjelmointikielestä tai ohjelmoinnista olivat vähäisimmät. Koodikatselmusten yhteydessä tuli myös ilmeiseksi se, että nyt kehitettävä ohjelmisto ei sovellu parhaalla mahdollisella tavalla koodikatselmointiin. Todennäköisimpiä virhelähteitä ovat ongelmat parametrien välityksessä HTML-sivuilta Servleteille ja toisinpäin, sekä tageilta jspsivuille. Myös ongelmat HQL (SQL) queryissä ovat varsin todennäköinen ongelmalähde. Mitään näistä ongelmista ei ole erityisen helppoa havaita lukemalla koodia läpi, koska virheiden havaitseminen vaatii monesti usean eri tiedoston samanaikaista tutkimista sekä keskittymistä logiikan kannalta epäolennaisiin asioihin kuten oikeinkirjoitukseen. FindBugs löysi I2-iteraation aikana kuusi virhettä. Kaksi Dm virhettä, kaksi SBSC virhettä, yhden UrF virheen, sekä yhden DE virheen. Virhekoodit selitykseen on listattu liitteessä A. Tällä kertaa FindBugsin ilmoittamat virheet eivät paljastaneet yhtään vakavaa, todellista ongelmaa koodissa. Ilmoitukset olivat toki aiheellisia ja ne korjattiin/korjataan, mutta varsinaista vaaraa niistä ei ollut. FindBugsin osalta tulos oli pienoinen pettymys; hyvän alun jälkeen sen toivottiin paljastavan useitakin todellisia ongelmia, mutta näin ei käynyt. FindBugs on kuitenkin edelleen käytön helppouteen ja nopeuteen suhteutettuna hyvä lisätyökalu virheiden etsimisessä. FD-vaiheessa tullaan vielä suorittamaan koodikatselmointia osalle sen aikana tuotetusta koodista. Katselmukset pyritään suuntaamaan I2-vaiheen kokemusten pohjalta enemmän koodin kirjoittajan kuin koodin kompleksisuusasteen mukaan. Myös FindBugsin käyttämistä tullaan jatkamaan ja JavaNcss-metriikoitakin kerätään, vaikkakaan niille ei tulla antamaan kovin paljon painoarvoa. 3.4 FD-vaihe FD-vaiheessa uusia toiminnallisuuksia ei implementoitu enää niin paljoa kuin edellisissä vaiheissa, vaan keskityttiin enemmänkin bugien korjaukseen ja testaukseen. Toki muutamia laajennuksia aikaisempiin toiminnallisuuksiin tehtiin, joten seurasimme edelleen kompleksisuusarvoja. Tämä ei kuitenkaan tuottanut mitään uusia huomattavia arvoja. Kompleksisuusarvot olivat pysyneet maltillisissa lukemissa ja kasvua ei ollut tapahtunut juuri ollenkaan. Yhteenveto-kappaleessa pohdimme syitä kompleksisuusarvojen maltillisuuteen. FindBugs löysi FD-vaiheessa lisätyistä koodeista 8 epäilyttävää kohtaa. Kohdat olivat DE, EI2, Dm (x3) ja SBSC (x3). Mikään epäilyttävistä kohdista ei aiheuttanut varsinaisia ongelmia, mutta edustivat huonoa ohjelmointitapaa. 3.5 Yhteenveto Mielestämme SEPA-harjoituksemme onnistui osittain tavoitteissaan. Onnistumisia olivat se että pystyimme helposti soveltamaan erilaisia staattisia menetelmiä projektiin, sekä tutustumaan niiden käyttöön käytännöntasolla. Staattiset menetelmän toimivat projektin aikana automatisoidusti joten ne olivat suhteellisen vaivaton lisä. Ainoat resurssikulut muodostuivat Aihe: RI & PK Sivu 9 of 11

10 näiden työkalujen asentamisesta, ajoittaisesta seuraamisesta sekä tuloksien analysoinnista. Joten voidaan todeta että koko projektin mittakaavassa tämä on olematon rasite. Harjoitusta aloittaessamme toivoimme kompleksisuuden mittaamisen paljastavan useita ongelmia ja huomioitavia varoitusmerkkejä. Näin ei kuitenkaan käynyt, sillä kompleksisuuden arvot pysyivät hyvin maltillisissa luvuissa ja emme joutuneet refaktoroimaan mitään komponenttia. Pohdittuamme syitä miksi kompleksisuusmittarit eivät paljastaneet mitään huomattavia ongelmia, päädyimme lopulta seuraaviin syihin: 1. Projekti oli kestoltaan suhteellisen lyhytikäinen ja vähäresurssinen. Se että projekti kesti n. 6 kuukautta sisältäen vain osa-aikaista työtä ja huomattavan osan byrokratiaa sekä määrittelyä, ei ohjelmointiosuudelle jäänyt erityisen suurta osuutta. Tämä taas vaikutti siihen että ohjelmakoodit eivät ehtineet kasvaa edes hirveän suuriksi ja koodihistoria ei ollut valtava. Pitempiaikaisten projektien/tuotteiden kehittämisessä voivat kompleksisuusluvut huomaamattomasti kasvaa hitaalleen suuriinkin (ongelmallisiin) arvoihin. 2. Arkkitehtuuri oli hyvin suunniteltu. Projektissa käytetty arkkitehtuuri oli hyvin abstrahoitu, sekä modulaarinen ja näin ollen helpotti ns. purkkaviritysten välttämistä. 3. Ryhmämme oli suhteellisen pienikokoinen, ryhmäosaaminen oli korkeatasoista ja ryhmähenki oli hyvä. Väitämme, että ryhmämme oli kokonaisuudessaan erittäin osaava tällä ohjelmistokehitysalueella, ja jokaiselle jäsenelle löytyi ominainen rooli täydentämään kokonaisuutta. Huonoa koodia ei yksinkertaisesti päässyt muodostumaan ryhmän jäsenten osaamisen takia. Se että ryhmähenki oli hyvä koko projektin ajan ja ryhmäkoko oli kompakti, tarkoitti tämä sitä että jokainen koodari otti vastuuta koko järjestelmästä eikä päästänyt havaittuja ongelmia lävitse sormiensa ajatellen että joku muu on vastuussa ja hoitaa tämän. Näin lopuksi voidaan todeta että vaikka koimme että menetelmät eivät tuoneet mitään erittäin merkittävää hyötyä projektille, ei voida kuitenkaan sanoa että nämä menetelmät ovat turhia. Tämä yksittäinen projekti ei riitä todistamaan menetelmiä tarpeettomaksi, ja joka tapauksessa on järkevämpää kokeilla kuin katua, sillä näiden analysointityökalujen asentamisesta ole koskaan haittaa. Aihe: RI & PK Sivu 10 of 11

11 Liite A: FindBugs virhekoodit Koodi Dm SBSC UrF UwF EI EI2 RCN Selite Turha new String( string ) kutsu pelkkä string tekee saman (performance) Stringien yhdistämistä +-operaattorilla loopissa (performance) Lukematon muuttuja; muuttuja on esitelty mutta sitä ei käytetä koskaan Kirjoittamaton muuttuja; muuttuja on esitelty mutta sen arvoa ei koskaan aseteta Epäsuora mahdollisuus muuttaa olion tilaa esim. palauttamalla suora viite olion sisältämään toiseen olioon minkä tilaa voidaan muuttaa Epäsuora mahdollisuus muuttaa olion tilaa esim. antamalla parametrina suora viite olioon toiselle oliolle mikä tallentaa vain viitteen null-tarkistus oliolle minkä null-statusta ei ole tarkistettu aiemmin koodissa; tarkitus on joko turha tai se pitäisi olla jo aikaisemmin SA Arvon asettaminen arvoon itseensä; x = x; DE Mahdollinen exceptionin huomoimatta jättäminen Aihe: RI & PK Sivu 11 of 11