Dobički:
- Sposobnost nastavitve testne varnostne mreže, ki zajame trenutno vedenje pred refaktoriranjem
- Sposobnost zahtevati od umetne inteligence majhne transformacije v enem koraku, ki ohranjajo vedenje, in potrditi vsak korak
- Sposobnost prepoznavanja in razvrščanja tehničnega dolga v poslovnem kontekstu
Preoblikovanje je izboljšanje notranje strukture kode brez spreminjanja njenega zunanjega obnašanja: naredi jo bolj berljivo, enostavnejšo in bolj vzdržljivo. Po drugi strani pa je tehnični dolg oblikovni kompromis, narejen zaradi hitre rešitve in povrnjen "z obrestmi" čez čas - vsak ovinek, ki ga presekate danes, se bo jutri vrnil kot upočasnitev ali hrošč. Umetna inteligenca je močan pomočnik, ki pospeši ponavljajoče se in mehanske naloge refaktoriranja; Vendar obstaja eno zlato pravilo refaktoriranja in umetna inteligenca sama ne more zagotoviti tega: vedenje se ne sme spremeniti.
V tej enoti se naučimo, kako izvajati varno preoblikovanje z AI: majhni in reverzibilni koraki, zaščita s testi, zaznavanje vonjav kode in dajanje prednosti tehničnim dolgom. Kritična točka je naslednja: opravljeni testi, ne beseda AI, dokazuje, da je vedenje ohranjeno.
Zlato pravilo refaktoriranja: Vedenje ostaja konstantno
Zaradi česar je preoblikovanje nevarno, je nevede spreminjanje vedenja, medtem ko pravite: "Izboljšujem se." Opustitev robnega primera pri poenostavitvi pogoja, kršitev vrstnega reda pri preoblikovanju zanke, izostanek stranskega učinka pri razdelitvi funkcije – vse to povzroči "na videz čisto", a pokvarjeno kodo.
Zato je testiranje predpogoj za preoblikovanje: pred spremembo morate imeti teste, ki zajemajo obstoječe vedenje. Ti testi so "varnostna mreža"; Če slučajno nekaj pokvarite med refactoringom, se bodo pokvarili in vas opozorili. Če nimate testov, najprej napišite teste, ki popravijo obstoječe vedenje (kot smo se naučili v 5. enoti) – tu dobi AI hiter začetek.
Pozor: refaktoriranje s pomočjo umetne inteligence brez testnega omrežja je eden najbolj zahrbtnih virov hroščev. Lahko je reči "vedenje sem ohranil"; Dokaz je, da enaki testi opravijo pred in po spremembi.
Korak za korakom: Varen tok preoblikovanja
- Postavite varnostno mrežo. Naj bodo testi, ki zajemajo trenutno vedenje kode, ki jo boste preoblikovali; Če ne, jih najprej zapišite (in poglejte, da gredo skozi).
- Poimenuj vonj. Kaj izboljšujete in zakaj? "Ta funkcija naredi 3 stvari", "ista logika se ponovi na 4 mestih", "imena so zavajajoča".
- Prosite za majhne korake v enem koraku. Prosite AI za eno samo transformacijo (npr. samo »razdelite to funkcijo na pol«), da ne prepiše celotne datoteke.
- Izvedite teste. Po vsakem koraku. Če je zelena, nadaljujte, če je rdeča, jo vzemite nazaj.
- Preberite razl. Vrsto za vrstico potrdite, da sprememba res ohranja vedenje; Če rečemo, da je AI "samo struktura", lahko pride do logičnega zdrsa.
- Združite na majhne koščke. Veliki enkratni PR-ji za preoblikovanje so tvegani in jih ni mogoče pregledati.
Trije mini kovčki
Primer 1 — 220-vrstična funkcija varno razdeljena. Ena ekipa je imela funkcijo obdelave naročil z 220 vrsticami. Napisanih je bilo prvih 14 testov (s pomočjo AI), ki so zajeli trenutno vedenje, vsi so bili uspešni. Nato je bila funkcija korak za korakom razdeljena na 5 manjših funkcij z AI; Po vsakem koraku so bili izvedeni testi. Dva testa sta bila pokvarjena v enem koraku - umetna inteligenca je zgrešila vrnitev v robnem primeru. Testi so to takoj ujeli in popravili. Brez omrežja bi lahko šla napaka vse do proizvodnje.
Primer 2 – Katastrofa brez testne mreže. Drugi razvijalec je "očistil" modul za izračun datuma, ki ni imel testov z AI. Koda je bila videti boljša, vendar je prestopno leto izračunala napačno; Napaka se je pojavila dva tedna kasneje s pritožbo stranke. Izguba je daleč odtehtala čas, prihranjen zaradi refaktoriranja. Nauk: preoblikovanje brez testiranja je igra na srečo.
Primer 3 – Tehnična prednostna razvrstitev dolga. Ena ekipa je umetni inteligenci dala zaostanek 30 ali tako "izboljšljivih" točk in vsako od njih ocenila na osi "pogostost sprememb × tveganje × napor". V dobljeni tabeli je bil grdi modul, ki se ga je redko dotaknil, dejansko nizka prioriteta, medtem ko je imel srednje zapleten modul, ki se je pogosto spreminjal, visoko prioriteto. Ekipa je svojo energijo usmerila na pravo mesto.
Štiri kopirane predloge
Zaznavanje vonja kode in določanje prednosti:
Kandidati za preoblikovanje seznama "smrdijo" v tej kodi: dolga funkcija, ponavljanje (DRYViolation), zavajajoče ime, globoko ugnezdeno stanje, skriti stranski učinek, čarobno število. Za vsako: lokacija, zakaj je prišlo do težave, predlagan majhen korak, ocenjeno tveganje (nizko/srednje/visoko). NE SPREMINJAJTE kode še, samo načrtujte.{{code}}
Preobrazba v enem koraku, ki ohranja vedenje:
SAMO naredite to: {{enotna pretvorba, npr. To funkcijo razdelite na 3 manjše poimenovane funkcije}}. SPREMENI vidno vedenje, podpis in vrnjene vrednosti. V enem stavku napišite, zakaj vse, kar ste spremenili, ohrani vedenje.{{code}}
Varnostna mreža pred refaktorjem (karakterizacijsko testiranje):
Napišite teste, ki zajemajo TRENUTNO vedenje te funkcije (pravilno ali ne); cilj je ujeti, če se vedenje spremeni med refaktoriranjem. Vključite tipične vnose + robove. Zapišite pričakovanja na podlagi trenutnega rezultata funkcije.{{function}}
Ustvarjanje evidence tehničnega dolga (zaostanki):
Naslednji seznam vonjav vnesite v prednostno tabelo: snov, prizadeto območje, pogostost spremembe (moje znanje: {{...}}), tveganje, ocenjen trud, priporočena prioriteta. Na vrh postavite tiste z visokim udarcem in majhnim naporom. {{smell_list}}
Šibek poziv/močan poziv
Šibko: "Počisti to kodo in jo izboljšaj."
Strong: "Razdelite to 90-vrstično funkcijo na 3 manjše funkcije z eno samo odgovornostjo, ne da bi spremenili njeno zunanje vedenje in podpis. Ohranite stranske učinke (zapisovanje DB) v trenutnem vrstnem redu. Imam teste, vedenje bi moralo ostati enako. Podajte razliko in v enem stavku razložite, zakaj vsaka delitev ohranja vedenje. [koda]"
Zmogljiva različica; Zahteva eno samo specifično transformacijo, izrecno nalaga omejitev vedenja in podpisa ter zahteva utemeljitev. Nejasne zahteve, kot je "stori bolje", vodijo v nenadzorovane in tvegane spremembe.
Vrsta refaktoriranja
Zanesljivost AI
Predpogoj
preimenovati
visoka
Ali je obseg pravilen?
Delitev funkcij
srednje visoka
Testnet je obvezen
Delitev ponavljanja
srednje
Razlika v vedenju je lahko skrita
Sprememba algoritma/strukture
nizka
Obsežno testiranje + človeška validacija
Arhitekturna preureditev
nizka
Vodi ga človek, podpira AI
Upravljanje tehničnega dolga, ne ponastavitev
Tehnični dolg ni le slab; Včasih je zavestno izposojanje (za izpolnjevanje dostave) prava odločitev. Cilj ni odpraviti dolga, ampak ga narediti vidnega in obvladljivega. Umetna inteligenca je hitra pri odkrivanju in določanju prednosti dolga, vendar odločanje o tem, »katerega dolga je treba plačati in katerega opustiti«, zahteva poslovni kontekst: kako pogosto se spreminja ta modul, na koliko ljudi vpliva, kakšno je tveganje? To odločitev sprejme ekipa, ki pozna kodno bazo in izdelek; AI samo razjasni možnosti.
Namig: PR naj bo ločen od PR, ki vključujejo spremembo vedenja. Če lahko rečete, da je "ta PR samo preoblikovanje, vedenje je enako", je lažje raziskati in vam omogoča, da hitro zožite vzrok, če se pojavi težava.
Pogoste napake
- Refactoring brez testne mreže. Ničesar ne morete dokazati, da je vedenje ohranjeno.
- Pomeni "počisti celotno datoteko". Velike, nenadzorovane spremembe skrijejo napako in jih ni mogoče pregledati.
- Sprejemanje razlike brez branja. AI se je morda zmotil nekaj logike, ko je rekel "samo struktura".
- Mešanje refaktoriranja s spremembo vedenja. Če izvajate oboje v istem PR-ju, onemogočite sledenje temeljnim vzrokom.
- Poskuša popraviti vsak vonj. Grda koda, ki se redko spreminja, ima pogosto nizko prioriteto; Dodelite energijo mestu, ki se pogosto spreminja.
Če povzamem
Edino pravilo refaktoriranja je, da vedenje ostane konstantno, dokaz za to pa so testi. Umetna inteligenca je zmogljiva pri zaznavanju vonjav kode, transformacijah v enem koraku in določanju prednosti tehničnega dolga; vendar morate nastaviti varnostno mrežo, zagnati teste in prebrati diff po vsakem koraku. Delajte majhne, obrnljive korake; razlikovati preoblikovanje od spremembe vedenja; in naj ekipa, ki pozna poslovni kontekst, odloči, kateri dolg bo plačal.
Aplikacijska naloga
Izberite funkcijo iz svoje baze kode, ki se vam zdi dolga ali zapletena. Preskusi prvega tiskanja, ki zajamejo njegovo trenutno vedenje s predlogo "varnostna mreža", in preverijo, ali so vsi uspešni. Nato dajte funkcijo refaktorirati na en sam način (npr. razdelitev na pol) z vzorcem "enostopenjske transformacije, ki ohranja vedenje" in znova zaženite teste. Če se test pokvari, ugotovite zakaj; Če se sploh ne pokvari, preberite diff vrstico za vrstico, da potrdite, da je vedenje res ohranjeno.
kontrolni seznam
- [ ] Vem, da preoblikovanje ne bi smelo spremeniti vedenja in obstajajo testi, ki to dokazujejo.
- [ ] Postavljam varnostno mrežo, ki ujame trenutno vedenje pred refaktorjem.
- [ ] Želim majhne transformacije v enem koraku iz umetne inteligence, ne velikih enkratnih.
- [ ] Po vsakem koraku izvedem teste in preberem razl.
- [ ] Preoblikovanje odnosov z javnostmi ločujem od odnosov s spremembami vedenja.
- [ ] Tehničnemu dolgu dajem prednost s poslovnim kontekstom, ne poskušam ga slepo izničiti.