Tiimi perii laskutusmoduulin, jota kukaan ei täysin ymmärrä. Sillä ei ole testejä, jotka suojaavat olemassa olevaa toimintaa. Sen "siivoamiseksi" ehdotetaan sprinttiä, ja suunnitelmana on kirjoittaa ydin uudelleen uudella rakenteella. Kukaan ei osaa sanoa, mistä he tietäisivät, että uusi versio veloittaa asiakkaita edelleen oikein.
Tämä on havainnollistava skenaario, ei dokumentoitu tapaus. Se kuvaa aukkoa, jonka refaktorointikoulutusprojektin on kurottava umpeen: insinöörit, jotka näkevät koodin olevan sotkuista, mutta eivät vielä pysty suunnittelemaan rajattua parannusta ja osoittamaan, että toiminta säilyi.
Tämä opas on tarkoitettu suunnittelupäälliköille ja suunnittelupäälliköille. Se kattaa suorituskykyongelman kuvaamisen, puutteiden diagnosoinnin, suunnittelun valmistelun ja käytännön toteutuksen, tapauksen läpikäymisen ja sen arvioinnin, voidaanko taitoa soveltaa käytännön työhön. Se käsittelee suunnittelun koulutusta. Ohjelmasi koodi, testit ja säännöt tulisi validoida vanhempien insinöörien toimesta omalla ohjelmointikoodipinollasi.
Mikä on refaktorointikoulutusprojekti?
Refaktorointikoulutusprojekti on strukturoitu työ vanhentuneen koodin parissa, jonka tarkoituksena on sekä kehittää kyvykkyyttä että parantaa koodia. Oppijat suunnittelevat pienen, rajatun muutoksen, suojaavat olemassa olevaa toimintaa testeillä, parantavat suunnittelua pienin askelin ja osoittavat todisteita siitä, ettei mikään ole hajonnut. Koodi paranee ja mikä tärkeintä, insinöörit harjoittelevat tarvitsemaansa harkintakykyä todellisen teknisen velan kanssa.
Nopeita faktoja
| Kysymys | Lyhyt vastaus |
|---|---|
| Mikä on tehtävä? | Suunnittele ja validoi rajatun vanhan koodin parannus. |
| Mitä pisteitä saat? | Riskianalyysi ja näyttö siitä, että olemassa oleva käyttäytyminen säilyi. |
| Onko laaja uudelleenkirjoitus hyvä koulutusprojekti? | Yleensä ei. Se peittää harjoiteltavan taidon ja tekee säilytetyn käyttäytymisen näyttämisen vaikeaksi. |
| Riittääkö pelkkä refaktorointimallien testi? | Ei. Se vahvistaa edellytykset, mutta ei sitä, pystyykö insinööri suunnittelemaan ja validoimaan muutoksen. |
| Kuka vahvistaa sisällön? | Suunnittelupäällikkö ja vanhempi insinööri, joka tuntee koodikannan. |
| Mitä harjoitus ei korjaa? | Puuttuvat testaustyökalut, irrotuspaine, epäselvä omistajuus ja ei aikaa huoltotöille. |
| Mistä tiedät, että se toimi? | Uusi, aiemmin käsittelemätön vanhan koodin tapaus, pisteytetty sovittujen kriteerien perusteella ja seurattu käytännön työn perusteella. |
1. Kuvaile suorituskykyongelma
Aloita tehtävästä: suunnittele ja validoi rajatun vanhan koodin parannus. ”Rajattu” on tärkeä sana. Oppija valitsee riittävän pienen muutoksen viimeistelyksi ja voi sanoa, mikä kuuluu ja mikä ei kuulu parannuksen piiriin.
On hyödyllistä olla tarkka termien suhteen. Martin Fowler kuvailee uudelleenjärjestelyä seuraavasti hallittu tekniikka olemassa olevan koodikannan suunnittelun parantamiseksi, joka koostuu pienistä, käyttäytymistä säilyttävistä muunnoksista. Ilmaus "käyttäytymistä säilyttävä" erottaa refaktoroinnin uudelleenkirjoituksesta, ja se on se, mikä harjoittelun on tehtävä näkyväksi. Tekninen velkametafora itsessään keksi Ward Cunningham, ja Fowlerin keskustelu on hyödyllinen muistutus siitä, että velkaa voidaan ottaa harkitusti ja harkiten, joten jokainen sotkuinen moduuli ei ole virhe, joka pitäisi korjata.
Michael Feathersin kirja vanhasta koodista suhtautuu käytäntöön samalla tavalla. Kustantajan kuvauksen mukaan se opettaa kehittäjiä kirjoittamaan testejä, jotka varmistavat he eivät muuta sovellusta tahattomastija saada olemassa oleva ohjelmisto hallintaan ilman täydellistä uudelleenkirjoittamista.
Kirjoita suorituskykylausunto yhteen lauseeseen ja pyydä suunnittelupäällikköä tarkistamaan se: ”Kun otetaan huomioon vanha moduuli ja määritelty tavoite, insinööri ehdottaa rajattua muutosta, lisää testejä, jotka määrittävät nykyisen käyttäytymisen, tekee muutoksen pienin askelin ja osoittaa, että käyttäytyminen säilyy.”
2. Diagnosoi oppimis- ja kontekstikuivat
Ennen kuin rakennat mitään, vertaa vaadittua tehtävää nykyiseen harjoitteluusi ja arvioi sitä. Kolme kysymystä erottaa yleensä koulutusvajeen jostakin muusta:
- Käyttääkö nykykäytäntö todellista tehtävää? Jos koulutus kattaa diojen refaktorointimallit, mutta kukaan ei koskaan muuta testaamatonta koodia, kukaan ei ole harjoitellut suojauskäyttäytymistä. Jos arviointi on monivalintatesti koodin hajuista, se mittaa muistamista.
- Mikä on kognitiivinen vaatimus? Bloomin tarkistetussa taksonomiassa muutoksen turvallisuuden arviointi tapahtuu analysointi- ja arviointitasoilla, ja suunnitelman ja testien suunnittelu etenee luontitasolle. Toimintojen yhteensovittamista näille tasoille käsitellään oppaassamme oppimistoimintojen yhdistäminen Bloomin taksonomiaan.
- Onko jokin muu kuin taito esteenä? Tarkista henkilöstö, työkalut ja menettelytavat. Jos koonti kestää tunnin, kukaan ei suorita testejä usein. Jos huoltotöitä ei koskaan aikatauluteta, insinöörit tekevät uudelleenjärjestelyjä vain salaa. Ilmoita koulutuksen ulkopuolisista syistä henkilöille, jotka voivat korjata ne.
3. Suunnittele tarkoituksenmukainen valmistautuminen ja harjoittelu
Kun tiedät, mitä aukkoja koulutus voi paikata, anna jokaiselle vaiheelle erillinen tehtävä.
Valmistautuminen. Tarkista esitiedot lyhyellä diagnostiikalla: miten testikehys toimii, mikä on karakterisointitesti ja miten tiimisi tarkastelee ja yhdistää tehtäviä. Omaan tahtiin opiskelu sopii tähän vaiheeseen. Kertaustarkistus vahvistaa vain esitiedot.
Harjoitella. Käytä systemaattisia ja selkeän muodon omaavia refaktorointiprojekteja. Aloita pienestä, turvallisesta otoksesta ja siirry sitten todelliseen, mutta rajattuun osaan omaa koodikantaasi. Gilded Rose -kata on tunnettu lähtökohta ensimmäiselle vaiheelle. Sen README-tiedostoa ylläpitää Emily Bache. suosittelee testien kirjoittamista ennen koodin muuttamista ja kehystää harjoituksen pienten askelten harjoitteluna, testien suorittamisen usein ja suunnittelun parantamisen pala palalta. Järkevä järjestys kullekin projektille on: määrittele tavoite ja raja, kirjoita testit, jotka kuvaavat koodin nykyistä toimintaa, muuta yksi asia kerrallaan, suorita testit jokaisen vaiheen jälkeen ja kirjoita ylös, mitä opit.
Palaute. Yhdistä palaute päätöksiin, älä kokonaispistemäärään. ”Otit esiin alennuslogiikan, mutta testisi kattoivat vain onnellisen polun, joten et ehkä huomannut pyöristysmuutosta” on hyödyllisempi kuin ”3/5”.
Live-ohjaajan syöte vai asynkroninen arviointi? Live-syöte tuo eniten arvoa silloin, kun valinta on epäselvä, esimerkiksi pitäisikö lopettaa ja lisätä puuttuva testi vai jatkaa. Asynkroninen arviointi riittää, kun oppijat vertaavat suunnitelmaansa ja testejään kommentoituun asiantuntijaversioon. Monet tiimit käyttävät molempia: ensin omaan tahtiin valmistautumista ja sitten fasilitoitua istuntoa vaikeiden tapausten parissa.
4. Käytä realistista esimerkkiä
Havainnollistava. Tekniikan päällikön tulisi validoida tapaus ja vastauskriteerit ennen käyttöä.
Tapaus. Vanha funktio laskee tilauksen kokonaissumman, joka sisältää alennuksen, veron ja toimitussäännön. Sillä ei ole testejä. Tiimi ehdottaa koko laskutusmoduulin uudelleenjärjestelyä, jotta siitä tulisi "siistimpi".
Tehtävä. Oppija selittää, mitä hän tekisi, mainitsee keräämänsä todisteet ja kertoo, mitä lisätietoa tai tukea hän tarvitsee.
Ensimmäinen yritys. ”Jakaisin moduulin kolmeen palveluun ja siirtäisin logiikan, ja sitten tarkistaisin numerot vaiheittaisessa vaiheessa.” Oppija on valinnut suuren muutoksen ja myöhäisen, manuaalisen tarkistuksen. Ei ole mitään keinoa sanoa, vastaavatko vanhat ja uudet versiot reunatapauksia.
Palaute ja uudelleenyritys. Tarkastaja kysyy, mitä funktio tekee tänään tyhjälle korille, alennukselle, joka tekee kokonaissummasta negatiivisen, ja pyöristystapaukselle. Uudelleenyrityksessä oppijaa pyydetään rajaamaan soveltamisala yhteen käyttäytymiseen ja kertomaan, miten hän todistaisi, ettei se muuttunut.
Vahvempi yritys. ”Jättäisin moduulirakenteen nyt rauhaan. Tallentaisin testeinä, mitä tilauksen kokonaissummafunktio palauttaa tänään joukolle syötteitä, mukaan lukien reunatapaukset. Sitten erottaisin alennuslaskelman omaksi funktiokseen, suorittaisin testit kyseisen vaiheen jälkeen ja lopettaisin. Huomauttaisin, että toimitussäännöllä on toimintaa, jota en ymmärrä, ja kysyisin kollegalta ennen kuin kosken siihen.” Huomaa, että tämä vastaus rajoittaa muutosta, suojaa toimintaa ensin ja nimeää sen, mikä on tuntematonta.
Miksi kukin vastaus on puolusteltava tai epätäydellinen. Arvioi kutakin hyväksyttyjen kriteerien, älä arvioijan mieltymysten, perusteella. Ensimmäinen yritys voi olla järkevä pitkän aikavälin suunta, mutta se on epätäydellinen suunnitelma, koska siinä ei ole näyttöä säilyneestä käyttäytymisestä. Vahvempi yritys on pieni, tarkistettavissa ja rehellinen epävarmuuden suhteen.
5. Arvioi kyvykkyydet ja suunnittele siirto
Kyvykkyyden näyttö on suoriutuminen uudessa, oppijaa aiemmin näkemättömässä vanhan koodin tapauksessa. Pisteytä riskianalyysi ja todisteet käyttäytymisen säilymisestä. Yksinkertainen arviointimatriisi käyttää asteikkoa 0–2 kriteeriä kohden:
| Kriteeri | Havaittavissa oleva näyttö |
|---|---|
| Tehtävän suorittaminen | Suunnittelee ja validoi rajatun vanhan koodin parannuksen ja tallentaa toimenpiteet ja niiden taustalla olevat todisteet. |
| perustelut | Selittää rajoitukset, vaihtoehdot ja epävarmuuden sekä tarkistaa riskit ja todisteet siitä, että käyttäytyminen säilyi. |
| Rajat | Käyttää hyväksyttyjä menettelytapoja ja pyytää apua, kun tiedot tai valtuutus ei riitä. |
Ankkurit: 0 puuttuu tai sitä ei tueta, 1 on osittainen ja siinä on olennaisia puutteita, ja 2 on täydellinen ja perusteltu sovittujen kriteerien perusteella. Määrittele kriittiset virheet erikseen, kuten käyttäytymisen muutos ilman, että testi olisi havainnut sitä, jotta kokonaispistemäärä ei voi peittää sitä. Tämä arviointimatriisi on ehdotus, ei validoitu valmiusstandardi: mukauta sitä suunnittelupäällikön kanssa ja kokeile sitä. Oppaamme... interaktiivisen käytännön suunnittelu hyödyllisen palautteen avulla näyttää, miten kirjoitetaan päätöksiin linkittävää palautetta.
Suunnittele siirto harkitusti. Harjoituksen jälkeen anna jokaiselle insinöörille pieni, todellinen velkapala, jonka hän voi käsitellä arvioijan kanssa, tai pidä lyhyt retrospektiivi viimeaikaisesta muutoksesta, joka rikkoi jotain. Tarkista siirto sopivan työkokemuksen jälkeen, ei heti työpajan jälkeen.
Missä interaktiivinen toimitus auttaa
Interaktiiviset formaatit auttavat, kun kaikkien tulisi sitoutua ennen ryhmän tapaamista. Live-istunnossa fasilitaattori voi näyttää lyhyen esittelytekstin, pyytää jokaista insinööriä lähettämään ensimmäisen tekemänsä muutoksen ja miten he todistaisivat sen turvalliseksi, ja sitten paljastaa levityksen ennen keskustelua. Sama kehote voi toimia omaan tahtiin valmistautumista varten. AhaSlides tukee interaktiivista oppimista ja siirtymistä live- ja omaan tahtiin tapahtuvan toimituksen välillä. Se on esitys- ja oppimistyökalu, ei paikka koodin suorittamiseen tai analysointiin, joten suorita itse refaktorointi omassa ympäristössäsi. Tarkista kaikki erityiset kirjoitus-, palaute- tai raportointitoiminnot, joihin aiot luottaa omaa työnkulkuasi vasten. Ohjeita formaattien valintaan on artikkelissamme aiheesta milloin käyttää adaptiivista, interaktiivista ja reaaliaikaista oppimista.
Mittaa, mikä muuttui
Päätä etukäteen, mikä osoittaisi insinöörien pystyvän tehtävään. Vertaa riskianalyysin laatua ja säilyneen käyttäytymisen todisteita näkymättömässä tapauksessa lähtötasoon. Määrittele, ketkä ovat mukana, nimittäjä ja ajoitus. Jos tulokset paranevat, tarkista, mitä muuta on muuttunut samana aikana, kuten uudet testaustyökalut, nopeampi koonti tai omistajanvaihdos, ennen koulutuksen hyväksilukemista.
Rajoitukset, jotka saattavat jäädä
- Aikaa huoltotöille. Jos velkatyötä ei koskaan suunnitella, koulutetuilla insinööreillä ei ole vieläkään paikkaa, missä käyttää taitoa.
- Testaustyökalut. Ilman käyttökelpoista testijohtosarjaa tai nopeaa kokoamista on vaikeaa tehdä pieniä askeleita ja tehdä usein toistuvia tarkastuksia.
- Tapauksen kattavuus. Yksi perinteikäs tapaus osoittaa muutamia riskityyppejä. Pisteytys ei kuvaa insinöörin harkintakykyä yleisesti.
- Refaktoroinnin välttäminen Jotkin koodit on parempi jättää rauhaan, korvata tai poistaa käytöstä, ja tämä päätös vaatii muutakin kuin taitoa.
- Siirto. Katassa suoritus ei ole sama kuin paineen alla olevassa tuotantomoduulissa suoritus.
Mainitse nämä sponsoreille ajoissa ja suunnittele erilliset korjaukset. Koulutus parantaa insinöörin suunnittelu- ja testauskykyä. Se ei luo aikaa tai työkaluja.
Usein kysyttyjä kysymyksiä
Mikä on refaktorointikoulutusprojekti?
Se on strukturoitua käytäntöä vanhan koodin parissa, jossa insinöörit suunnittelevat pienen muutoksen, suojaavat olemassa olevaa toimintaa testeillä, muuttavat suunnittelua pienin askelin ja osoittavat, ettei mikään ole hajonnut.
Onko täydellinen uudelleenkirjoitus hyvä tapa oppia teknisestä velasta?
Yleensä ei. Uudelleenkirjoitus on laaja, vaikeasti validoitava ja piilottaa taidon, jota haluat kehittää. Rajoitettu muutos testeillä, jotka tallentavat nykyisen käyttäytymisen, tekee päättelyn näkyväksi.
Miten arvioit, pystyvätkö insinöörit refaktoroimaan turvallisesti?
Anna uusi tapauskoodi ja pisteytä riskianalyysi sekä todisteet siitä, että toiminta säilyi sovittujen kriteerien mukaisesti. Refaktorointimalleja koskeva tietokilpailu vahvistaa vain esitiedot.
Tarvitsetko esimerkkikoodikantaa koulutusta varten?
Tarvitset turvallisen paikan harjoitteluun. Monet joukkueet aloittavat julkisella katalla ja siirtyvät sitten oman koodinsa rajattuun osaan. Teknisen johtajasi tulee varmistaa, että koodi on sopiva.
Mistä aloittaa
Valitse koodikannassasi yksi pieni, toistuva perinteikäs muutos. Kirjoita suorituskykylausunto, pyydä suunnittelupäällikköä validoimaan tapaus ja testit, jotka osoittaisivat säilyneen toiminnan, ja laadi kolmikriteerinen arviointimatriisi asteikolla 0-2 ja luettelolla kriittisistä virheistä. Testaa sitä pienryhmässä ennen käyttöönottoa.
Jos haluat nähdä, kuinka refaktorointipäätösharjoitus voitaisiin suorittaa reaaliajassa oman tiimisi kanssa ja käyttää sitä uudelleen omaan tahtiin jälkeenpäin, tutustu AhaSlides-sivustoon.
