COTOOL dokumentaatio SEPA: Refaktorointi

Transkriptio

1

2 Table of Contents Refaktorointi Tehtävänanto Johdanto Refaktoroinnin taustaa Menetelmä Edut Haitat Käytännön sovellutus Kokemukset ja muutokset Toteutus Toteutus 1a ja 1b Toteutus 2a ja 2b Yhteenveto Viitteet

3 1 (3) Refaktorointi Autere Aleksi, 57412R Welin Jan, 49620N Versiohistoria Versio Pvm Tekijä Kuvaus Hyväksyjä AA & AA & AA & Ensimmäinen versio - Toinen versio - Vain pieniä muutoksia - 1 Tehtävänanto Refactoring means improvement of source code without adding any functionality. The purpose of refactoring is to guard the code against decay that is typical to any software developed for a longer time. Assignment: Plan how and when you will do refactoring, and how you decide when refactoring is necessary, e.g., based on the occurrence of bad code smells. [Fowler and Beck] 2 Johdanto Valitsimme refaktoroinnin SEPA aiheeksi koska projektissamme tultaisiin joka tapauksessa käyttämään ko. tekniikkaa, koska otimme käyttöön kesken projektin evolutiivisen kehityksen ja yksinkertaisen suunnittelun ja refaktoroinnin. Tekniikka on suurimmalle osalle projektilaisista uusi, tosin muutamat ryhmän jäsenet ovat käyttäneet refaktorointia järjestelmällisesti myös aikaisemmissa projekteissasaan. 3 Refaktoroinnin taustaa Refaktorointi (eng. refactoring) tarkoittaa suomeksi tekijöihin jakamista uudelleen eli tekijöiden yhdistämistä, mutta tietotekniikassa puhuttaessa tarkoitetaan lähdekoodin rakenteen muokkaamista siten että ohjelman tominnallisuus ei muutu. Tarkoituksena on saada koodista selkeämpää ja ymmärrettävämpää. Tekniikan tutkimus ja systemaattinen käyttö on melko uutta ohjelmistotuotannossa. Näkemyksiä refaktoroinnista näyttää olevan monia, aina DO-NOT-FIX-IT-IF-IT-IS-WORKING näkemyksestä "refaktoroi kunnes ei ole enää refaktoroitavaa" ideologiaan. Huomattavaa on että refaktorointia tapahtuu jokaisessa ohjelmistokehtiysprojektissa vaikka tekniikkaa ei systemaattisesti tai tiedostaen käytettäisi. Armoton refaktorointi (engl. Refactor Mercilessly) on yksi XP-metodologian menetelmä, joka lähtee ajatuksesta "Refactor whenever and wherever possible.". / 1/, /4/ 4 Menetelmä Refaktorointia voidaan tehdä usealla eri tasolla. Alimmalla tasolla refaktoroitaessa toimitaan yksittäisten luokkien sisällä. Tällöin voidaan esimerkiksi vaihtaa muuttujien nimiä kuvaavimmiksi tai pilkkoa metodeja pienempiin kokonaisuuksiin jne. Seuraavalla tasolla, eli luokkatasolla refaktorointi tarkoittaa arkkitehtuurin selkeyttämistä luokkarakennetta muokkaamalla. Esimerkkejä luokkatason refaktoroinnista ovat luokkien yhdistäminen tai pilkkominen

4 2 (3) tarvittaessa mikäli luokissa on liikaa tai liian vähän toiminnallisuutta. Ylimmän tason refaktorointi koskee pakettirakennetta. Luokkia voidaan jakaa selkeämpään hierarkiaan niiden ominaisuuksien mukaan. Refaktorointi sekoitetaan monesti virheellisesti koodin uudelleenkirjoittamiseen. Tästä ei kuitenkaan ole varsinaisesti kysymys, vaan refaktorointi on koodin rakenteen muokkaamista. Refaktorointia tulisi tehdä ohjelmoinnin yhteydessä, eli ohjelmoijan pitäisi miettiä jatkuvasti tuottamaansa koodia ja parannella sitä vastaamaan hyviä ohjelmointikäytäntöjä. Monissa tapauksissa myös muut ohjelmoijat voivat refaktoroida toistensa koodia. Erityisesti tätä on rohkaistu tekemään XP-ohjelmointikäytännössä. Yleisesti tulisi välttää kerralla tehtäviä laajoja refaktorointeja, koska virheiden mahdollisuus kasvaa ja on mahdollista tehdä vaikeasti peruutettavia virheellisiä toimenpiteitä. Yksi tapa välttää virheitä laajaa refaktorointia tehtäessä, on ottaa refaktorointia varten kopio tarvittavasta koodista ja tehdä refaktorointi kopiolle. Tämän jälkeen muutokset tuodaan alkuperäiseen koodiin pienemmissä osissa. Jokaisen muutoksen jälkeen testataan toimivuus. /3/ 5 Edut Tässä kappaleessa on pyritty miettimään menetelmän tuomia etuja. - Koodin ymmärettävyys ja ylläpidettävyys paranee. - Refaktoroidusta koodista saattaa olla helpompi löytää virheitä. 6 Haitat Tässä kappaleessa on pyritty miettimään menetelmän mahdollisia haittoja. - Refaktoroimalla on mahdollista rikkoa ohjelman toimivuus. - Refaktorointi on työtä, joka ei varsinaisesti näy lopputuotteessa, eli käännetyssä ohjelmassa. - Refaktorointi saattaa sekoittaa "liian suurissa annoksissa" muiden projektilaisten käsitystä koodin rakenteesta. Ja aiheuttaa näin lisätyötä. - Jos refaktorointiin käyttää väärään aikaan liikaa resursseja, saattaa käsillä oleva työtehtävä kärsiä. - Jos refaktoroinnin jälkeen ei suoriteta regressiotestausta on vaarana että systeemi menee rikki. /2/, 7 Käytännön sovellutus Projektin kaikki ohjelmakoodi kirjoitetaan Eclipseä käyttäen. Eclipse tukee monia tyypillisimpiä refaktorointeja helpottaen niiden tekemistä huomattavasti. Esimerkiksi muuttujan tai metodin nimeä muutettaessa Eclipse korjaa kaikki projektissa esiintyvät viittaukset automaattisesti. Lisäksi metodien ja instanssimuuttujien siirtely perittävältä luokalta perijälle tai toiseen suuntaan onnistuu Eclipsen avustamana helposti. Myös muihin siirtoihin, kuten metodien siirtoon luokkien välillä ja luokkien siirtoon pakettien välillä löytyy Eclipsestä automatiikkaa. Refaktorointia kasittelevällä wiki-sivustolla /5/ esitellään tiettyjä refaktorointikäytäntöjä, joista käytämme ainakin seuraavia: - The First Refactoring Step Ennen refaktorointia tulee olla toimivat yksikkötestit valmiina muutettaville luokille. Tällä tavoin voidaan varmistua siitä, ettei refaktorointi aiheuta uusia virheitä. - Bodyguard Pattern Mikäli virheitä kuitenkin syntyy, varmistutaan siitä, että voidaan palata refaktorointia edeltävään tilanteeseen. Taaksepäin palaaminen on helppoa CVS-versionhallintaa käyttäen.

5 3 (3) - Refactoring In Very Small Steps Refaktorointi suoritetaan aina mahdollisimman pienissä erissä, ja testataan koodin toimivuus jokaisen refaktoroinnin jälkeen. Suuriin muutoksiin syntyy helpommin virheitä, ja virheiden löytäminen suuresta massasta on vaikeampaa kuin pienestä. 8 Kokemukset ja muutokset 8.1 Toteutus 1 Toteukset 1 ja 2 jaettiin ensimmäisen iteraation alussa alitoteutuksiin 1a, 1b, 2a ja 2b Toteutus 1a ja 1b Käytännössä systemaattista refaktorointia ei ensimmäisen a-iteraation aikana tapahtunut. Syynä tähän oli aikataulun venyminen kuten projektisuunnitelmasta käy ilmi. 1b-vaiheessa "refaktorointia" kuitenkin käytettiin lähes aina kun koodia tuotettiin tai muokattiin. Lienee kuitekin oikeaoppisempaa puhua jollain muulla termillä tästä iteratiivisesta koodin kehityksestä kuin termillä refaktorointi, koska koodi/luokkarakenne muuttui niin usein. 8.2 Toteutus 2a ja 2b Täydennetään myöhemmin 8.3 Yhteenveto 9 Viitteet Kaikki internet-viittaukset avautuvat uuteen ikkunaan