Refaktorointi teknisen velan hallintavälineenä Simo Mäkinen Tietojenkäsittelytieteen laitos Helsingin yliopisto

Transkriptio

1 Refaktorointi teknisen velan hallintavälineenä Simo Mäkinen Tietojenkäsittelytieteen laitos Helsingin yliopisto Mäkinen / Refaktorointi teknisen velan hallintavälineenä, FISMA ry kevätseminaari,

2 Need for Speed tutkimusohjelma (N4S) Valtakunnallisessa tutkimushankkeessa pyritään parantamaan suomalaisten ohjelmistoyritysten reaktiivisuutta kykyä toimittaa ohjelmistoja nopeammin loppukäyttäjälle Hankkeessa n. 30 yritystä ja n. 10 tutkimuslaitosta Ref.:

3 Tekninen velka Tekninen velka on ohjelmiston rakenteisiin kertynyttä korjausvelkaa Tekninen velka johtuu ohjelmiston suunnittelussa, toteutuksessa tai ylläpidossa otetuista oikopoluista Teknisen velan alatyyppejä tunnistettu useita* Rakenteellista velkaa Suunnitteluvelkaa Arkkitehtuurivelkaa Testivelkaa Automaatiovelkaa *Yli-Huumo et al

4 Refaktorointi Refaktoroinnilla tarkoitetaan olemassaolevien ohjelmiston koodirakenteiden muokkaamista ilman ulkoisen toiminnallisuuden muutosta Refaktorointi tähtää koodin sisäisen laadun parantamiseen rakennemuutoksin

5 Tutkimuksia refaktoroinnista Leppänen, M.; Mäkinen, S.; Lahtinen, S.; Sievi-Korte, O; Tuovinen, A.-P.; Männistö, T, "Refactoring-a Shot in the Dark?," in IEEE Software, vol.32, no.6, pp.62-70, Nov.-Dec Leppänen, M; Lahtinen, S; Kuusinen, K; Mäkinen, S; Männistö, T; Itkonen, J.; Yli-Huumo, J; Lehtinen, T, "Decision-Making Framework for Refactoring," IEEE 7th International Workshop on Managing Technical Debt (MTD), 2015, pp

6 Tapaustutkimuksen taustat Haastateltiin (TTY/HY) keväällä 2015 yritysten kokeneita ohjelmistokehittäjiä ja arkkitehtejä 10 haastattelua, 12 haastateltavaa, 9 yritystä Yritysten toimialueet vaihtelivat verkkosovelluksista teollisiin sulautettuihin järjestelmiin Haastateltavat toimivat yleensä alle 10 henkilön tiimeissä Ohjelmistokehitys sisäistä, ulkoiselle asiakkaalle tehtävää tai sopimuspohjaista konsulttityötä

7 Tutkimusmenetelmä Semi-strukturoidut haastattelut kestoltaan tunnista kahteen Refaktorointiteemoja: määritelmä, menetelmät, työkalut, metriikat, riskit, hyödyt, haasteet, päätöksenteko, kehityssyklin vaikutukset

8 Mikä on refaktorointia? Päivittäin tehtäviä pieniä rakennemuutoksia ei usein koettu refaktoroinniksi Refaktorointi miellettiin enemmän useita työpäiviä kestäväksi koodin uudellenorganisoimiseksi Haastateltavien käsitys refaktoroinnista vastaa paremmin restrukturoinnin (restructuring, reengineering) käsitettä Kehittäjät arvioivat käyttävänsä n. viidenneksen työajastaan refaktorointiin tai restrukturointiin

9 Mistä refaktorointitarpeet johtuvat? Kiireen takia tehdään tietoisesti rakenteeltaan heikompia koodiratkaisuja Kehitystyötä aloitettaessa ei ole täydellistä tietoa nykyisistä ja tulevista tarpeista Kehittäjät oppivat koko ajan uutta ja kokonaisuus nähdään myöhemmin uudessa valossa

10 Refaktorointipäätösten rationaalisuus Refaktoroinnin tarve lähtee ohjelmistokehittäjistä Kehittäjillä käsitys rakenteellisista ongelmakohdista Kehittäjien hankala kvantifioida refaktorointitarpeita Refaktoroinnin tarpeellisuuden määrittäminen haastavaa

11 Laatumetriikoiden käyttö yrityksissä Haastateltavat eivät pääsääntöisesti pitäneet laatumetriikoita oleellisina Laatumetriikan parantamisesta voi tulla tavoite itsessään, huomio keskittyy vääriin asioihin Staattista koodianalyysia kuitenkin hyödynnettiin jonkin verran turvallisuuskriittisissä tapauksissa

12 Refaktoroinnin hyödyt Refaktorointi helpottaa tai mahdollistaa ohjelmiston jatkokehitystä Refaktoroinnin myötä koodista voi tulla kehittäjille helppotajuisempaa ja ymmärrettävämpää Koodin suorituskyky saattaa parantua rakenteellisten muutosten jälkeen Kehittäjien henkinen hyvinvointi voi myös parantua

13 Refaktoroinnin riskit ja haitat Kattavista testeistä huolimatta koodi voi hajota ja virheiden määrä lisääntyä Muutokset ulkoisiin rajapintoihin saattavat vaikuttaa kolmannen osapuolen palveluihin Ei takeita koodin muutoksesta parempaan suuntaan, laatu voi huonontua Vaivalla tehty isompi rakenteellinen muutos saatetaan joutua hylkäämään

14 Refaktoroinnin tekniset vaatimukset ja työkalut Versionhallintajärjestelmät Automatisoidut testit eri tasoilla antavat regressiovarmuutta Jatkuvan integraation palvelimet Kehitysympäristöjen refaktorointiapuvälineet hyvä lisä, mutteivät täysin välttämättömiä kehitystyölle

15 Refaktoroinnin koetut hyödyt ja haasteet kootusti + Jatkokehitys helpompaa Ymmärrettävyys Uudelleenkäyttö Laatuattribuuttien parantaminen Moraalin ja motivaation kasvatus Jonkin hajoaminen Ulkoisesti näkyvien muutosten aiheuttaminen Koodin laadun heikkeneminen Ajan ja työn haaskaaminen

16 Refaktoroinnin dilemma Pyrittävä näkemään millaisia tarpeita ohjelmiston tulee täyttää tulevaisuudessa Kehittäjän tulee tehdä paras arvaus mitkä osat koodista pysyvät staattisina, mitkä mahdollisesti muuttuvat Lyhyen elinkaaren omaavilla ohjelmistotuotteilla refaktorointi ei ehkä kannata

17 Näkemys refaktoroinnin Siinähän on sellanen toivomus, että kun mä refaktoroin, niin säästän aikaa tulevaisuudessa. Eli siinä tehdään tavallaan sijoitus tulevaisuuteen, ja se sijoitus ei välttämättä realisoidu. Haastateltu ohjelmistoarkkitehti

18 Tapaustutkimus II: päätöksenteko refaktoroinnissa Keskityttiin tarkemmin kolmen yrityksen refaktoroinnin päätöksentekoon Yrityshaastattelujen lisäksi käytössä versionhallintadataa

19 Miten refaktorointiprosessi etenee? 1. Alkuperäinen toteutus 2. Uusi tarve 3. Kehitys alkaa 4. Havainto refaktorointitarpeesta 5. Suunnittelu 6. Toteutus 7. Parikatselmointi

20 Refaktoroinnin päätöksentekokehys Leppänen et al

21 Refaktorointitapaus: Solita näkymä versionhallinnasta

22 Lähteet Leppänen, M.; Mäkinen, S.; Lahtinen, S.; Sievi-Korte, O; Tuovinen, A.-P.; Männistö, T, "Refactoring-a Shot in the Dark?," in IEEE Software, vol.32, no.6, pp.62-70, Nov.- Dec Leppänen, M; Lahtinen, S; Kuusinen, K; Mäkinen, S; Männistö, T; Itkonen, J.; Yli-Huumo, J; Lehtinen, T, "Decision-Making Framework for Refactoring," IEEE 7th International Workshop on Managing Technical Debt (MTD), 2015, pp Yli-Huumo, J., Maglyas, A., & Smolander, K. (2014). The sources and approaches to management of technical debt: A case study of two product lines in a middle-size finnish software company. In Product-Focused Software Process Improvement (pp ). Springer International Publishing

23 Kiitos!