If it works, fix it! – Refaktorointi kannattaa aina
If it works, fix it! – Refaktorointi kannattaa aina
Refaktorointi, eli jo toimivan koodin muokkaaminen ilman että toimintoja lisätään, on monessa tuotekehitysorganisaatiossa vähän vaikea asia. Usein on niin, että prioriteetista päättävät ihmiset karsastavat ajatusta käyttää päiviä tai viikkoja jo toteutetun koodin muuttamiseen, ja voimavarat laitetaan mieluummin uuden toiminnallisuuden tekemiseen.
Refaktorointi helpottaa tekemistä
Päättäjillä on tietenkin yrityksen paras vain mielessä: uusilla toiminnoilla halutaan tarjota asiakkaille enemmän. Ohjelmistokehittäjien tulisi kuitenkin pitää mielessä ja pyrkiä nostamaan refaktoroinnin tuomia etuja enemmän esiin.
Kuka tahansa osaa tehdä koodia, jonka tietokone ymmärtää. Taitavat kehittäjät tekevät koodia, jonka ihminen ymmärtää.
Kumpaa yleensä tehdään enemmän, kirjoitetaan uutta koodia vai luetaan vanhaa?
Esitänpä tässä yhden kysymyksen: kumpaa yleensä tehdään enemmän, kirjoitetaan uutta koodia vai luetaan vanhaa? Väitän, että keskimäärin kehittäjät käyttävät ajastaan moninkertaisen osan koodin lukemiseen ja vain dramaattisen pienen osan uusien koodirivien kirjoittamiseen. Kuinka paljon uuden koodin kirjoittaminen tehostuisi, jos vanha koodi olisi paljon luettavampaa ja helpompaa ymmärtää?
Luettavuus on vain yksi refaktoroinnin motivaatiopiste. Refaktoroinnilla voidaan saavuttaa myös suorituskykyetuja, bugifiksauksen ja muutosten nopeuttamista ja ratkaisun robustisuuden parantamista, vain muutamia etuja luetellakseni.
Elefantti syödään pikku palasina
Kokemukseni perusteella (ja olen itse tähän syyllinen, koska usein olin itse päättämässä tekemisen prioriteeteista!) refaktorointia tehdään yleensä aivan liian vähän. Miten organisaatiossa olisi sitten helpointa tehdä riittävästi refaktorointia ja osata huomata tilanteet missä se on erityisesti tarpeen?
Kaikkein paras tapa tehdä refaktorointia on
- pienissä paloissa ja
- koko ajan.
Muuta rakenne ensin sellaiseksi, että uuden tekeminen on helppoa!
Esimerkiksi, jos tulee vastaan tarina, missä pitää lisätä joku tietty toiminto, ja selviää että toiminnon lisääminen on hankalaa koodin nykyisen rakenteen takia, JUURI TÄSSÄ on paikka tehdä refaktorointia. Eli – refaktoroi koodi ensin niin, että uuden toiminnon lisääminen olisi helppoa, ja vasta sitten lisää toiminto. Tämä tarkoittaa sitä, että kun tarinoita tiimissä estimoidaan, pitäisi käyttää pikkuisen aikaa siihen, että ei pelkästään heitetä storypoint-arviota tarinalle, vaan vaikka puoli tuntia katsottaisiin läpi, että mitenkäs tämän voisi tehdä. Ja jos törmätään tarpeeseen tehdä refaktorointia, se leivotaan tarinan effortiin sisään. Näin saadaan jatkuva refaktorointi käyntiin. Näin toimivat menestyvät tuotekehitysorganisaatiot, ja näin vältetään hirvittävän isot refaktorointiydinpommit vuosien päästä.
Most wanted -lista
Meillä oli eräässä tiimissä käytössä termi ”Class written by God”, koska sitä ei ymmärtänyt kukaan muu kuin Jumala.
Toinen tapa, miten refaktorointia saadaan to do -listalle, on ylläpitää listaa pahimmista outlaw-luokista, mitkä on PAKKO kohta uudistaa. Meillä oli eräässä tiimissä käytössä termi ”Class written by God”, koska sitä ei ymmärtänyt kukaan muu kuin Jumala. Eli tämmöiset osat softa-assetista pitäisi tunnistaa ja ne pitäisi listata. Ehdotan, että tiimi pitää ”refaktorointi to do” -listaa jossain, vaikka Confluencessa.
Pelottele pomojasi
Tämä lista pitää sitten ”myydä” sisäisesti tuotehallinnalle ja tuotteen omistajalle. Tähän voi olla kaksi keinoa: pelottelu tai hyötyjen esittely. Hyötynä voi esitellä että jonkun heille kriittisen featuren tekeminen helpottuu huomattavasti, jos refaktorointi tehdään. Pelotteluna taas voi kuvailla, mitä karmeuksia tapahtuu, jos tätä ja tätä koodin osaa ei refaktoroida. Yöllä tulee mörkö ja syö lapsesi. Tai naapurin lemmikkimarsu pureksii klassikkoporschesi sähköjohdot raketti-spagetiksi. No, nuo olivat vaan kielikuvia.
Ideana on maalata realistinen kuva siitä mitä tapahtuu tulevaisuudessa, JOS ei JUURI NYT kirjoiteta jotain osaa koodista uudelleen. Muuten käy niin, että refaktorointia pusketaan aina vaan tulevaisuuteen, kunnes joskus ollaan pikkuhiljaa tilanteessa, jossa muutosten tekeminen vain aina vaan hidastuu ja hidastuu, ja tekeminen muuttuu tehottomammaksi ja tehottomammaksi. Kaikki voimme kuvitella, että tuollaisessa ympäristössä työskentely ei ole enää kivaa.
Do it or die
Tulevaisuuden tuotekehityksessä ei vaan voi pärjätä, jos refaktoroinnin unohtaa.
Refaktoroinnilla on tarkoitus saada koodista helpommin luettavaa ja muutettavaa, mistä taas seuraa se, että muutosten tekeminen on nopeampaa ja tiimi saa enemmän asioita tehdyksi. Tästä tulee positiivinen kierre, jossa kaikki voittavat. Tulevaisuuden tuotekehityksessä ei vaan voi pärjätä, jos refaktoroinnin unohtaa. Refaktoroinnin Raamattu on kirja: Martin Fowlerin ”Refactoring: Improving the design of existing code”, jonka pitäisi löytyä jokaisesta tiimistä ja jonka 50 ensimmäistä sivua on pakollista luettavaa jokaiselle ohjelmistokehittäjälle.
Contribyte on suomen johtava tuotekehityksen auttaja. Meiltä saat monipuoliset palvelut organisaatiosi kehittämiseen!
P.S. Haluatko pysyä perillä Contribyten uutisista sekä koulutuksista ja tapahtumista? Tilaa uutiskirjeemme!
Arto Kiiskinen
Senior Consultant
Arto on urallaan nähnyt tuotekehitystä monista eri näkökulmista. Hänellä on kokemusta mm. Product Ownerin, Scrum Masterin ja tuotekehitysjohtajan tehtävistä. Niin isojen kuin pientenkin firmojen toimintatavat ovat tulleet tutuiksi. Arto rakastaa parantaa organisaatioiden oppimista sekä tuoteomistajien osaamista, ja kirjoittaa blogeja eri aiheista. Koska retrospektiivit on yksi Arton suosikkiaiheista, ovat jotkut asiakkaat antaneet hänelle lisänimen "Retromies". Vapaa-aikana Arto yrittää elää terveellisesti, ostaa mahdollisimman paljon autoja, katsoo yhä uudelleen Tähtiportti-sarjan jaksoja ja opiskelee Personal Traineriksi. Arto on kirjoittanut kirjan "OWN IT – 8 Simple Secrets of Product Owner Success". Lisää Arton ajatuksia voi lukea täältä.
