Kasu:
- Võimalus seadistada test-turvavõrk, mis fikseerib praeguse käitumise enne ümbertöötamist
- Võimalus küsida tehisintellekti väikesi, üheastmelisi käitumist säilitavaid teisendusi ja iga sammu valideerida
- Võimalus tuvastada ja prioritiseerida tehnilisi võlgu ärikontekstis
Refaktoreerimine on koodi sisemise struktuuri parandamine ilma selle välist käitumist muutmata: muutes selle loetavamaks, lihtsamaks ja hooldatavamaks. Tehniline võlg seevastu on kiire lahenduse nimel tehtud disainikompromiss, mis aja jooksul "koos intressidega" tagasi makstud — iga täna lõigatud nurk tuleb homme tagasi aeglustuse või veana. Tehisintellekt on võimas abiline, mis kiirendab korduvaid ja mehaanilisi taastekke ülesandeid; Kuid ümbertöötamisel on üks kuldreegel ja AI üksi ei saa seda tagada: käitumine ei tohi muutuda.
Selles üksuses õpime, kuidas teha tehisintellektiga ohutut ümbertöötlust: väikesed ja pööratavad sammud, testidega kaitsmine, koodilõhnade tuvastamine ja tehniliste võlgade tähtsuse järjekorda seadmine. Kriitiline punkt on järgmine: käitumise säilimist tõestab testide läbimine, mitte AI sõna.
Refaktoreerimise kuldreegel: käitumine jääb konstantseks
Refaktoreerimise teeb ohtlikuks see, et muudab eneseteadmatult käitumist, öeldes: "Ma paranen". Tingimuse lihtsustamisel tähise kõrvalejätmine, tsükli teisendamisel järjekorra rikkumine, funktsiooni jagamisel kõrvalmõju puudumine – kõik annavad "puhta välimusega", kuid katkise koodi.
Seetõttu on testimine refaktoreerimise eelduseks: enne muutmist peavad teil olema testid, mis fikseerivad olemasoleva käitumise. Need testid on "turvavõrk"; Kui te kogemata midagi ümbertegemise käigus lõhute, lähevad nad katki ja hoiatavad teid. Kui teil pole teste, kirjutage esmalt testid, mis parandavad olemasoleva käitumise (nagu me õppisime 5. üksuses) – siin saab AI hüppeliselt alguse.
Ettevaatust: AI-ga toetatud refaktoreerimine ilma testvõrguta on üks salakavalamaid vigade allikaid. Lihtne on öelda "ma säilitasin käitumise"; Tõestus on see, et samad testid läbivad enne ja pärast muudatust.
Samm-sammult: turvaline taastekitamise voog
- Seadke turvavõrk üles. Laske olla teste, mis fikseerivad ümberkujundatava koodi praeguse käitumise; Kui ei, siis kirjutage need kõigepealt üles (ja vaadake, kuidas need läbi lähevad).
- Nimetage lõhn. Mida sa parandad ja miks? "See funktsioon teeb 3 asja", "sama loogika kordub 4 kohas", "nimed on eksitavad".
- Küsige väikeseid üheastmelisi samme. Küsige AI-lt ühte teisendust (nt lihtsalt "jagage see funktsioon pooleks"), mitte kogu faili ümber kirjutamist.
- Käivitage testid. Pärast iga sammu. Kui see on roheline, jätkake, kui see on punane, võtke see tagasi.
- Loe Diff. Kinnitage rida-realt, et muutus on tõepoolest käitumist säilitav; Kui öeldakse, et AI on "lihtsalt struktuur", võib esineda loogika libisemist.
- Kombineerige väikesteks tükkideks. Suured ühekordsed ümbertegemise PR-d on nii riskantsed kui ka ülevaatamatud.
Kolm miniümbrist
Juhtum 1 – 220-realine funktsioon on ohutult poolitatud. Ühel meeskonnal oli 220-realine tellimuste töötlemise funktsioon. Esimesed 14 testi kirjutati (AI abiga), mis jäädvustasid hetkekäitumise ja kõik läbisid. Seejärel jagas funktsioon tehisintellekti abil samm-sammult 5 väiksemaks funktsiooniks; Testid viidi läbi pärast iga sammu. Ühes etapis läks kaks testi katki – AI-l jäi äärekorpuse tagasitulek vahele. Testid tabasid selle kohe ja parandasid selle. Ilma võrguta oleks viga võinud ulatuda kuni tootmiseni.
Juhtum 2 – katastroof ilma testvõrguta. Teine arendaja "puhastas" kuupäeva arvutamise mooduli, millel ei olnud tehisintellektiga teste. Kood nägi parem välja, kuid see arvutas liigaasta valesti; Viga ilmus kaks nädalat hiljem kliendi kaebusega. Kaotus kaalus tunduvalt üles ümbertöötamisest säästetud aja. Õppetund: refaktoreerimine ilma testimiseta on õnnemäng.
Juhtum 3 – tehniline võlgade prioritiseerimine. Üks meeskond andis tehisintellektile mahajäämuse umbes 30 "täiustatava" punktiga ja igaüks neist hinnati teljel "muutuste sagedus × risk × pingutus". Saadud tabelis oli inetu moodul, mida harva puudutati, tegelikult madala prioriteediga, samas kui keskmise keerukusega moodul, mida sageli muudeti, oli kõrge prioriteediga. Meeskond suunas oma energia õigesse kohta.
Neli kopeeritavat malli
Koodilõhna tuvastamine ja prioriseerimine:
Loetlege refaktoreerimiskandidaat selles koodis: pikk funktsioon, kordus (DRYViolation), eksitav nimi, sügav pesastatud seisund, peidetud kõrvalmõju, maagiline number. Igaühe kohta: asukoht, probleemi põhjus, soovitatud väike samm, hinnanguline risk (madal/keskmine/kõrge). ÄRGE veel koodi MUUDA, lihtsalt planeerige.{{code}}
Üheastmeline käitumist säilitav transformatsioon:
LIHTSALT tehke seda: {{ühekordne konversioon, nt. Jaga see funktsioon 3 väiksemaks nimega funktsiooniks}}. MUUDA nähtavat käitumist, allkirja ja tagastusväärtusi. Kirjutage ühe lausega, miks kõik, mida muutsite, säilitab käitumise.{{code}}
Turvavõrk enne refaktorit (iseloomustustest):
Kirjutage teste, mis fikseerivad selle funktsiooni PRAEGUSE käitumise (õige või mitte); eesmärk on tabada, kas käitumine muutub refaktoreerimise käigus. Kaasake tüüpilised + serva kirjed. Kirjutage ootused funktsiooni praeguse väljundi alusel.{{function}}
Tehnilise võla kirje (mahajäämuse) genereerimine:
Lisage prioriteetide tabelisse järgmine lõhnade loend: aine, mõjutatud piirkond, muutuste sagedus (minu teada: {{...}}), risk, hinnanguline pingutus, soovitatav prioriteet. Asetage ülaosale tugeva löögi ja vähese pingutusega tooted. {{smell_list}}
Nõrk viip / Tugev viip
Nõrk: "Puhastage see kood ja muutke see paremaks."
Tugev: "Jagage see 90-realine funktsioon 3 väiksemaks funktsiooniks ühe vastutusega, muutmata selle välist käitumist ja allkirja. Hoidke kõrvalmõjud (DB kirjutab) praeguses järjekorras. Mul on testid, käitumine peaks jääma samaks. Andke erinevus ja selgitage ühe lausega, miks iga jaotus on käitumist säilitav. [kood]"
Võimas versioon; See nõuab ühte konkreetset teisendust, kehtestab selgesõnaliselt käitumis- ja allkirjapiirangu ning nõuab põhjendust. Ebamäärased taotlused, nagu "tee paremini", viivad kontrollimatute ja riskantsete muutusteni.
Refaktori tüüp
AI usaldusväärsus
Eeltingimus
ümber nimetada
kõrge
Kas ulatus on õige?
Funktsioonide jaotus
keskmine-kõrge
Testnet on kohustuslik
Korduse jagamine
keskmine
Käitumiserinevus võib olla peidetud
Algoritmi/struktuuri muutmine
madal
Ulatuslik testimine + inimese valideerimine
Arhitektuurne ümberkorraldamine
madal
Inimese juhitud, tehisintellekti toetatud
Tehnilise võla haldamine, mitte selle kustutamine
Tehniline võlg pole kõik halb; Mõnikord on teadlik laenamine (saadavuse saavutamiseks) õige otsus. Eesmärk ei ole võlga kaotada, vaid muuta see nähtavaks ja juhitavaks. Tehisintellekt on võlgade tuvastamisel ja tähtsuse järjekorda seadmisel kiire, kuid otsustamine „milline võlg tasuda ja millest loobuda” nõuab ärikonteksti: kui sageli see moodul muutub, kui palju inimesi see mõjutab, milline on risk? Selle otsuse teeb meeskond, kes tunneb koodibaasi ja toodet; AI lihtsalt selgitab võimalusi.
Näpunäide: hoidke oma suhtekorralduse ümberkujundamine lahus suhtekorraldusest, mis hõlmab käitumise muutusi. Võimalus öelda "see PR on lihtsalt ümberkujundamine, käitumine on sama", muudab uurimise lihtsamaks ja võimaldab teil probleemi ilmnemisel kiiresti põhjust kitsendada.
Levinud vead
- Refaktoreerimine ilma testvõrguta. Teil ei ole midagi, mis tõestaks, et käitumine on säilinud.
- See tähendab "kogu faili kustutamist". Suured kontrollimatud muudatused peidavad vea ja neid ei saa uurida.
- Diffi aktsepteerimine seda lugemata. AI võis loogikast mööda minna, kui ta ütles "lihtsalt struktuur".
- Segadusse ajav ümberkujundamine käitumismuutustega. Mõlema sama PR-ga tegemine muudab algpõhjuste jälgimise võimatuks.
- Proovin parandada iga lõhna. Inetu kood, mis muutub harva, on sageli madala prioriteediga; Jaotage energiat kohta, mis sageli muutub.
Kokkuvõttes
Ainus refaktoreerimise reegel on see, et käitumine jääb konstantseks ja selle tõestuseks on testid. AI on võimas koodilõhnade, üheastmeliste teisenduste tuvastamisel ja tehniliste võlgade tähtsuse järjekorda seadmisel; kuid sa pead seadma turvavõrgu üles, tegema testid ja lugema diff pärast iga sammu. Tehke väikseid, pöörduvaid samme; eristada refaktoreerimist käitumise muutusest; ja laske ettevõtte konteksti tundval meeskonnal otsustada, milline võlg maksta.
Rakenduse ülesanne
Valige oma koodibaasist funktsioon, mis tundub teile pikk või keeruline. Esmalt prinditakse testid, mis fikseerivad selle praeguse käitumise "turvavõrgu" malli abil ja kontrollivad, kas need kõik läbivad. Seejärel laske funktsioon ühel viisil ümber faktoreerida (nt pooleks jagades) mustriga "üheastmeline käitumist säilitav teisendus" ja käivitage testid uuesti. Kui test läheb katki, uurige välja, miks; Kui see üldse ei purune, lugege erinevust ridade kaupa, et kinnitada, kas käitumine on tõepoolest säilinud.
kontrollnimekiri
- [ ] Tean, et refaktoreerimine ei tohiks käitumist muuta ja selle tõestamiseks on olemas testid.
- [ ] Seadistan turvavõrgu, mis püüab kinni praeguse käitumise enne refaktorit.
- [ ] Ma tahan tehisintellektist väikeseid üheastmelisi teisendusi, mitte suuri ühekordseid.
- [ ] Pärast iga sammu käivitan testid ja loen diff.
- [ ] Ma hoian suhtekorralduse ümberkujundamise lahus käitumise muutmise PR-st.
- [ ] Ma eelistan tehnilist võlga ärikontekstiga, mitte ei ürita pimesi nullida.