Dobici:
- Sposobnost postavljanja testne sigurnosne mreže koja bilježi trenutno ponašanje prije refaktoriranja
- Sposobnost traženja AI za male transformacije u jednom koraku koje čuvaju ponašanje i potvrđivanje svakog koraka
- Sposobnost identificiranja i određivanja prioriteta tehničkog duga unutar poslovnog konteksta
Refactoring je poboljšanje unutarnje strukture koda bez promjene njegovog vanjskog ponašanja: čineći ga čitljivijim, jednostavnijim, lakšim za održavanje. Tehnički dug, s druge strane, kompromis je dizajna napravljen radi brzog rješenja i vraća se "s kamatama" tijekom vremena — svaki ugao koji danas presječete vratit će se sutra kao usporavanje ili greška. Umjetna inteligencija moćan je pomoćnik koji ubrzava ponavljajuće i mehaničke zadatke refaktoriranja; Ali postoji jedno zlatno pravilo refaktoriranja, a umjetna inteligencija sama to ne može jamčiti: ponašanje se ne smije mijenjati.
U ovoj jedinici učimo kako napraviti sigurno refaktoriranje pomoću umjetne inteligencije: mali i reverzibilni koraci, zaštita testovima, otkrivanje mirisa koda i davanje prioriteta tehničkom dugu. Kritična točka je sljedeća: prolazni testovi, a ne riječ umjetne inteligencije, dokazuje da je ponašanje očuvano.
Zlatno pravilo refaktoriranja: Ponašanje ostaje konstantno
Ono što refaktoring čini opasnim jest nesvjesno mijenjanje ponašanja dok se govori "poboljšavam se". Ispuštanje rubnog slučaja pri pojednostavljenju uvjeta, kršenje redoslijeda pri transformaciji petlje, propuštanje nuspojava pri dijeljenju funkcije—sve to daje kod "čistog izgleda", ali neispravan.
Zato je testiranje preduvjet za refaktoriranje: prije promjene morate imati testove koji hvataju postojeće ponašanje. Ovi testovi su "sigurnosna mreža"; Ako slučajno nešto slomite tijekom refactoringa, oni će se slomiti i upozoriti vas. Ako nemate testove, prvo napišite testove koji popravljaju postojeće ponašanje (kao što smo naučili u jedinici 5) — ovdje umjetna inteligencija dobiva brz početak.
Oprez: refaktoriranje uz pomoć umjetne inteligencije bez testne mreže 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 tijek refaktoriranja
- Postavite sigurnosnu mrežu. Neka postoje testovi koji bilježe trenutno ponašanje koda koji ćete refaktorirati; Ako ne, prvo ih zapišite (i pogledajte da prođu).
- Imenujte miris. Što poboljšavate i zašto? "Ova funkcija radi 3 stvari", "ista se logika ponavlja na 4 mjesta", "imena su lažna".
- Zatražite male korake u jednom koraku. Zamolite AI za jednu transformaciju (npr. samo "podijelite ovu funkciju na pola"), a ne da ponovno napišete cijelu datoteku.
- Pokrenite testove. Nakon svakog koraka. Ako je zeleno, nastavi, ako je crveno, vrati ga.
- Pročitajte Diff. Potvrdite redak po redak da promjena doista održava ponašanje; Možda postoji logička greška kada se kaže da je AI "samo struktura".
- Sjediniti u male komadiće. Veliki jednokratni PR-ovi za refaktoriranje su riskantni i ne mogu se revidirati.
Tri mini kućišta
Slučaj 1 — funkcija od 220 redaka sigurno podijeljena. Jedan tim je imao funkciju obrade naloga od 220 redaka. Napisano je prvih 14 testova (uz pomoć AI) koji su zabilježili trenutno ponašanje, svi su prošli. Zatim je AI korak po korak funkciju podijelio u 5 manjih funkcija; Testovi su provedeni nakon svakog koraka. Dva su testa pokvarena u jednom koraku — AI je propustio povratak u rubnom slučaju. Testovi su to odmah uhvatili i popravili. Bez mreže, pogreška bi mogla ići sve do proizvodnje.
Slučaj 2 — Katastrofa bez testne mreže. Drugi je programer "očistio" modul za izračunavanje datuma koji nije imao testove s AI. Kod je izgledao bolje, ali je netočno izračunavao prijestupnu godinu; Greška se pojavila dva tjedna kasnije uz pritužbu korisnika. Gubitak je daleko nadmašio vrijeme ušteđeno refaktoriranjem. Lekcija: refaktoriranje bez testiranja je kockanje.
Slučaj 3 — Tehničko određivanje prioriteta duga. Jedan tim je AI-u dao zaostatak od 30-ak bodova za "poboljšanje" i svaki je dobio bodove na osi "učestalost promjena × rizik × napor". U dobivenoj tablici, ružan modul koji se rijetko dirao bio je zapravo niskog prioriteta, dok je modul srednje složenosti koji se često mijenjao bio visokog prioriteta. Ekipa je svoju energiju usmjerila na pravo mjesto.
Četiri predloška za kopiranje
Detekcija mirisa koda i određivanje prioriteta:
Kandidat za refaktoriranje popisa "smrdi" u ovom kodu: duga funkcija, ponavljanje (DRYViolation), pogrešno ime, duboko ugniježđeno stanje, skrivena nuspojava, magični broj. Za svaki: mjesto, zašto problem, predloženi mali korak, procijenjeni rizik (nizak/srednji/visok). NEMOJTE MIJENJATI kôd još, samo planirajte.{{code}}
Transformacija u jednom koraku koja čuva ponašanje:
SAMO učinite ovo: {{single conversion, e.g. Podijelite ovu funkciju na 3 manje imenovane funkcije}}. PROMIJENITE vidljivo ponašanje, potpis i povratne vrijednosti. Napiši u 1 rečenici zašto sve što si promijenio zadržava ponašanje.{{code}}
Sigurnosna mreža prije refaktora (testiranje karakterizacije):
Napišite testove koji bilježe TRENUTNO ponašanje ove funkcije (ispravno ili ne); cilj je uhvatiti mijenja li se ponašanje tijekom refaktoriranja. Uključi tipične + rubne unose. Napišite očekivanja na temelju trenutnog izlaza funkcije.{{function}}
Generiranje tehničke evidencije duga (zaostatka):
Stavite sljedeći popis mirisa u tablicu prioriteta: tvar, zahvaćeno područje, učestalost promjene (moje znanje: {{...}}), rizik, procijenjeni napor, preporučeni prioritet. Stavite one s velikim udarcem + one s malim naporom na vrh. {{smell_list}}
Slab upit / Jak upit
Slab: "Očistite ovaj kôd i poboljšajte ga."
Strong: "Podijelite ovu funkciju od 90 redaka u 3 manje funkcije s jednom odgovornošću, bez mijenjanja njenog vanjskog ponašanja i potpisa. Zadržite nuspojave (DB pisanje) u trenutnom redoslijedu. Imam testove, ponašanje bi trebalo ostati isto. Dajte diff i objasnite u jednoj rečenici zašto svako dijeljenje čuva ponašanje. [kod]"
Snažna verzija; Zahtijeva jednu specifičnu transformaciju, eksplicitno nameće ograničenje ponašanja i potpisa i zahtijeva opravdanje. Nejasni zahtjevi poput "učini bolje" dovode do nekontroliranih i riskantnih promjena.
Vrsta refaktoriranja
AI pouzdanost
Preduvjet
preimenovati
visoka
Je li opseg točan?
Podjela funkcija
srednje-visoka
Testnet je obavezan
Dijeljenje ponavljanja
srednji
Razlika u ponašanju može biti skrivena
Promjena algoritma/strukture
nizak
Opsežno testiranje + ljudska provjera
Arhitektonsko preuređenje
nizak
Vođen ljudima, podržan AI
Upravljanje tehničkim dugom, a ne ponovno postavljanje
Tehnički dug nije samo loš; Ponekad je svjesno posuđivanje (kako bi se ispunila isporuka) prava odluka. Cilj nije eliminirati dug, već ga učiniti vidljivim i upravljivim. Umjetna inteligencija je brza u otkrivanju i određivanju prioriteta duga, ali odlučivanje "koji dug treba platiti, a koji treba napustiti" zahtijeva poslovni kontekst: koliko se često ovaj modul mijenja, na koliko ljudi utječe, koji je rizik? Ovu odluku donosi tim koji poznaje bazu koda i proizvod; AI samo pojašnjava mogućnosti.
Savjet: Držite svoj PR za refaktoriranje odvojen od PR-a koji uključuju promjenu ponašanja. Mogućnost reći da je "ovaj PR samo refaktoriranje, ponašanje je isto" olakšava istraživanje i omogućuje vam brzo sužavanje uzroka ako se problem pojavi.
Uobičajene greške
- Refactoring bez testneta. Ne preostaje vam ništa da dokažete da je ponašanje očuvano.
- To znači "očisti cijelu datoteku". Velike, nekontrolirane promjene skrivaju grešku i ne mogu se ispitati.
- Prihvaćanje razlike bez čitanja. AI je možda malo promašio logiku kad je rekao "samo struktura".
- Brkanje refaktoriranja s promjenom ponašanja. Radeći oboje u istom PR-u onemogućuje praćenje uzroka.
- Pokušavajući popraviti svaki miris. Ružan kod koji se rijetko mijenja često je niskog prioriteta; Dodijelite energiju mjestu koje se često mijenja.
Ukratko
Jedino pravilo refactoringa je da ponašanje ostane konstantno, a dokaz za to su testovi. AI je moćan u otkrivanju mirisa koda, transformacijama u jednom koraku i davanju prioriteta tehničkom dugu; ali morate postaviti sigurnosnu mrežu, pokrenuti testove i pročitati diff nakon svakog koraka. Poduzmite male, reverzibilne korake; razlikovati refactoring od promjene ponašanja; i neka tim koji poznaje poslovni kontekst odluči koji će dug platiti.
Zadatak aplikacije
Odaberite funkciju iz svoje baze kodova koja vam se čini duga ili složena. Prvo ispišite testove koji bilježe njegovo trenutno ponašanje s predloškom "sigurnosne mreže" i vidite prolaze li svi. Zatim neka se funkcija refaktorira na jedan način (npr. dijeljenje na pola) s uzorkom "transformacija koja čuva ponašanje u jednom koraku" i ponovno pokrenite testove. Ako test pokvari, saznajte zašto; Ako se uopće ne pokvari, pročitajte razliku red po red kako biste potvrdili da je ponašanje doista očuvano.
popis za provjeru
- [ ] Znam da refaktoriranje ne bi trebalo 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 umjetne inteligencije, a ne velike jednokratne.
- [ ] Nakon svakog koraka pokrećem testove i čitam diff.
- [ ] Držim refactoring PR odvojeno od PR promjene ponašanja.
- [ ] Dajem prednost tehničkom dugu s poslovnim kontekstom, a ne pokušavam slijepo smanjiti ga.