Dobici:
- Sposobnost postavljanja testne sigurnosne mreže koja bilježi trenutno ponašanje prije refaktoriranja
- Sposobnost da od AI zatražite male transformacije u jednom koraku koje čuvaju ponašanje i potvrdite svaki korak
- Sposobnost identifikovanja i određivanja prioriteta tehničkog duga u poslovnom kontekstu
Refaktoriranje je poboljšanje unutrašnje strukture koda bez promjene njegovog vanjskog ponašanja: čini ga čitljivijim, jednostavnijim, lakšim za održavanje. Tehnički dug je, s druge strane, kompromis u dizajnu napravljen radi brzog rješenja i koji se vraća "sa kamatama" tokom vremena - svaki kut koji presječete danas će se vratiti kao usporavanje ili greška sutra. Umjetna inteligencija je moćan pomoćnik koji ubrzava zadatke koji se ponavljaju i mehaničkog prepravljanja; Ali postoji jedno zlatno pravilo refaktoriranja, a AI sama to ne može garantirati: ponašanje se ne smije promijeniti.
U ovoj jedinici učimo kako napraviti siguran refaktoring pomoću AI: mali i reverzibilni koraci, zaštita testovima, otkrivanje mirisa koda i određivanje prioriteta tehničkog duga. Kritična tačka je sledeća: prolazni testovi, a ne reč veštačke inteligencije, dokazuje da je ponašanje očuvano.
Zlatno pravilo refaktoringa: Ponašanje ostaje konstantno
Ono što refaktoring čini opasnim je nesvjesno mijenjanje ponašanja dok se govori "Ja se poboljšavam". Ispuštanje rubnog slučaja prilikom pojednostavljivanja uvjeta, kršenje redoslijeda prilikom transformacije petlje, propuštanje nuspojave prilikom cijepanja funkcije—sve to proizvodi "čist", ali pokvaren kod.
Zato je testiranje preduslov za refaktoring: prije promjene morate imati testove koji bilježe postojeće ponašanje. Ovi testovi su “sigurnosna mreža”; Ako slučajno nešto razbijete tokom refaktoriranja, oni će pokvariti i upozoriti vas. Ako nemate testove, prvo napišite testove koji popravljaju postojeće ponašanje (kao što smo naučili u jedinici 5) — tu AI dobija brz početak.
Oprez: Refaktoriranje uz pomoć umjetne inteligencije bez testneta jedan je od najpodmuklijih izvora grešaka. Lako je reći "sačuvao sam ponašanje"; Dokaz je da isti testovi prolaze prije i poslije promjene.
Korak po korak: siguran tok refaktoriranja
- Postavite zaštitnu mrežu. Neka postoje testovi koji hvataju trenutno ponašanje koda koji ćete refaktorirati; Ako ne, prvo ih zapišite (i pogledajte kako prolaze).
- Imenujte miris. Šta poboljšavate i zašto? "Ova funkcija radi 3 stvari", "ista logika se ponavlja na 4 mjesta", "imena su obmanjujuća".
- Zatražite male korake u jednom koraku. Zatražite od AI-a jednu transformaciju (npr. samo "podijelite ovu funkciju na pola"), a ne da prepisuje cijeli fajl.
- Pokreni testove. Nakon svakog koraka. Ako je zeleno, nastavi, ako je crveno, vrati ga.
- Pročitajte Diff. Potvrdite red po red da promjena zaista održava ponašanje; Može doći do logičkog klizanja kada se kaže da je AI "samo struktura".
- Sjedinite na male komadiće. Veliki jednokratni refaktorski PR-ovi su i rizični i ne mogu se pregledati.
Tri mini futrole
Slučaj 1 — 220-linijska funkcija sigurno podijeljena. Jedan tim je imao funkciju obrade narudžbi od 220 redova. Napisano je prvih 14 testova (uz pomoć AI) koji su zabilježili trenutno ponašanje, svi su prošli. Zatim je funkcija podijeljena na 5 manjih funkcija korak po korak pomoću AI; Testovi su vođeni nakon svakog koraka. Dva testa su prekinuta u jednom koraku — AI je propustio povratak u ivičnom slučaju. Testovi su to odmah uhvatili i popravili. Bez mreže, greška bi mogla ići sve do proizvodnje.
Slučaj 2 — Katastrofa bez testneta. Drugi programer je "počistio" modul za izračunavanje datuma koji nije imao testove sa AI. Kod je izgledao bolje, ali je pogrešno računao prijestupnu godinu; Greška je izašla dvije sedmice kasnije uz žalbu korisnika. Gubitak je daleko nadmašio vrijeme ušteđeno od preuređivanja. Lekcija: refaktorisanje bez testiranja je kockanje.
Slučaj 3 — Tehnički prioritet duga. Jedan tim je AI-u dao zaostatak od 30-ak „popravljivih“ bodova i svaki je postigao na osi „frekvencija promjene × rizik × napor“. U rezultujućoj tabeli, ružni modul koji se retko dodirivao bio je zapravo niskog prioriteta, dok je modul srednje složenosti koji se često menjao bio visokog prioriteta. Tim je svoju energiju usmerio na pravo mesto.
Četiri predloška koji se mogu kopirati
Detekcija mirisa koda i određivanje prioriteta:
Kandidat za refaktoriranje liste "miriše" u ovom kodu: duga funkcija, ponavljanje (DRYViolation), pogrešno ime, duboko ugniježđeno stanje, skriveni nuspojava, magični broj. Za svaki: lokacija, zašto je problem, predloženi mali korak, procijenjeni rizik (nizak/srednji/visok). NEMOJTE još MIJENJATI kod, samo planirajte.{{code}}
Transformacija koja čuva ponašanje u jednom koraku:
SAMO uradite ovo: {{pojedinačna konverzija, npr. Podijelite ovu funkciju na 3 manje imenovane funkcije}}. PROMIJENITE vidljivo ponašanje, potpis i povratne vrijednosti. Napišite u jednoj rečenici zašto sve što ste promijenili zadržava ponašanje.{{code}}
Sigurnosna mreža prije refaktora (testiranje karakteristika):
Napišite testove koji bilježe TRENUTNO ponašanje ove funkcije (ispravno ili ne); cilj je uhvatiti ako se ponašanje promijeni tokom refaktoriranja. Uključuje tipične + rubne unose. Napišite očekivanja na osnovu trenutnog izlaza funkcije.{{function}}
Generiranje tehničke evidencije duga (zaostataka):
Izlijte sljedeću listu mirisa u tabelu prioriteta: supstanca, područje zahvaćeno, učestalost promjena (moje znanje: {{...}}), rizik, procijenjeni napor, preporučeni prioritet. Stavite one sa visokim udarcem + malim naporom na vrh. {{smell_list}}
Slaba prompt / Jaka prompt
Slabo: "Očistite ovaj kod i učinite ga boljim."
Snažno: "Podijelite ovu funkciju od 90 redova na 3 manje funkcije s jednom odgovornošću, bez promjene njenog vanjskog ponašanja i potpisa. Zadržite nuspojave (DB piše) u trenutnom redoslijedu. Imam testove, ponašanje bi trebalo ostati isto. Dajte diff i objasnite u jednoj rečenici zašto svaka podjela čuva ponašanje. [kod]"
Moćna verzija; Zahtijeva jednu specifičnu transformaciju, eksplicitno nameće ponašanje i ograničenje potpisa i zahtijeva opravdanje. Nejasni zahtjevi poput "uradi bolje" dovode do nekontroliranih i rizičnih promjena.
Refaktoring tip
AI pouzdanost
Preduvjet
preimenovati
visoko
Da li je opseg ispravan?
Podjela funkcija
srednje visok
Testnet je obavezan
Dijeljenje ponavljanja
srednje
Razlika u ponašanju može biti skrivena
Promjena algoritma/strukture
nisko
Opsežno testiranje + ljudska validacija
Arhitektonsko preuređenje
nisko
Predvođeni ljudima, podržani umjetnom inteligencijom
Upravljanje tehničkim dugom, a ne njegovo resetiranje
Tehnički dug nije loš; Ponekad je svjesno zaduživanje (da bi se ispunila isporuka) prava odluka. Cilj nije eliminirati dug, već učiniti ga vidljivim i upravljivim. AI je brz u otkrivanju i određivanju prioriteta duga, ali odluka „koji dug treba platiti, a koji treba napustiti“ zahtijeva poslovni kontekst: koliko često se mijenja ovaj modul, na koliko ljudi utiče, koji je rizik? Ovu odluku donosi tim koji poznaje bazu koda i proizvod; AI samo pojašnjava opcije.
Savjet: Držite svoj refaktorski PR odvojen od PR-a koji uključuju promjenu ponašanja. Mogućnost da kažete "ovaj PR je samo refaktoring, ponašanje je isto" olakšava istraživanje i omogućava vam da brzo suzite uzrok ako se pojavi problem.
Uobičajene greške
- Refaktoring bez testneta. Nemate ništa da dokažete da je ponašanje očuvano.
- To znači "obrisati cijeli fajl". Velike, nekontrolirane promjene skrivaju grešku i ne mogu se ispitati.
- Prihvatanje razlike bez čitanja. AI je možda promašio logiku kada je rekao "samo struktura".
- Brkanje refaktoringa sa promjenom ponašanja. Raditi oboje u istom PR-u onemogućava praćenje uzroka.
- Pokušavam da popravim svaki miris. Ružan kod koji se rijetko mijenja često je niskog prioriteta; Dodijelite energiju mjestu koje se često mijenja.
Ukratko
Jedino pravilo refaktoriranja je da ponašanje ostaje konstantno, a dokaz tome su testovi. AI je moćan u otkrivanju mirisa kodova, transformacijama u jednom koraku i određivanju prioriteta tehničkog duga; ali morate postaviti sigurnosnu mrežu, pokrenuti testove i pročitati diff nakon svakog koraka. Pravite male, reverzibilne korake; razlikovati refaktoring od promjene ponašanja; i neka tim koji poznaje poslovni kontekst odluči koji dug će platiti.
Zadatak aplikacije
Odaberite funkciju iz baze koda koja vam izgleda dugačka ili složena. Prvo ispišite testove koji bilježe njegovo trenutno ponašanje sa šablonom "sigurnosne mreže" i vidite da li su svi prošli. Zatim izvršite refaktoriranje funkcije na jedan način (npr. dijeljenje na pola) uz obrazac "transformacije u jednom koraku, očuvanja ponašanja" i ponovo pokrenite testove. Ako se test pokvari, saznajte zašto; Ako se uopće ne pokvari, pročitajte diff red po red kako biste potvrdili da je ponašanje zaista očuvano.
kontrolna lista
- [ ] Znam da refaktoring ne bi trebao promijeniti ponašanje i postoje testovi koji to dokazuju.
- [ ] Postavljam sigurnosnu mrežu koja hvata trenutno ponašanje prije refaktora.
- [ ] Želim male transformacije u jednom koraku od AI, a ne velike jednokratne.
- [ ] Nakon svakog koraka pokrećem testove i čitam diff.
- [ ] Držim refaktoring PR-a odvojeno od PR-a promjene ponašanja.
- [ ] Prioritet dajem tehničkim dugovima s poslovnim kontekstom, a ne slijepo pokušavam nulirati.