Refaktorointi teknisen velan hallintavälineenä Simo Mäkinen Tietojenkäsittelytieteen laitos Helsingin yliopisto Mäkinen / Refaktorointi teknisen velan hallintavälineenä, FISMA ry kevätseminaari, 6.4.2016 6.4.2016 1
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.: http://www.n4s.fi/ 6.4.2016 2
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. 2014 6.4.2016 3
Refaktorointi Refaktoroinnilla tarkoitetaan olemassaolevien ohjelmiston koodirakenteiden muokkaamista ilman ulkoisen toiminnallisuuden muutosta Refaktorointi tähtää koodin sisäisen laadun parantamiseen rakennemuutoksin 6.4.2016 4
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. 2015. 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. 61-68. 6.4.2016 5
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ä 6.4.2016 6
Tutkimusmenetelmä Semi-strukturoidut haastattelut kestoltaan tunnista kahteen Refaktorointiteemoja: määritelmä, menetelmät, työkalut, metriikat, riskit, hyödyt, haasteet, päätöksenteko, kehityssyklin vaikutukset 6.4.2016 7
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 6.4.2016 8
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 6.4.2016 9
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 6.4.2016 10
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 6.4.2016 11
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 6.4.2016 12
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 6.4.2016 13
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 6.4.2016 14
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 - 6.4.2016 15
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 6.4.2016 16
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 6.4.2016 17
Tapaustutkimus II: päätöksenteko refaktoroinnissa Keskityttiin tarkemmin kolmen yrityksen refaktoroinnin päätöksentekoon Yrityshaastattelujen lisäksi käytössä versionhallintadataa 6.4.2016 18
Miten refaktorointiprosessi etenee? 1. Alkuperäinen toteutus 2. Uusi tarve 3. Kehitys alkaa 4. Havainto refaktorointitarpeesta 5. Suunnittelu 6. Toteutus 7. Parikatselmointi 6.4.2016 19
Refaktoroinnin päätöksentekokehys Leppänen et al. 2015 6.4.2016 20
Refaktorointitapaus: Solita näkymä versionhallinnasta 6.4.2016 21
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. 2015 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. 61-68. 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. 93-107). Springer International Publishing. 6.4.2016 22
Kiitos! 6.4.2016 23