zisky:
- Schopnosť nastaviť testovaciu bezpečnostnú sieť, ktorá zachytí aktuálne správanie pred refaktorizáciou
- Schopnosť požiadať AI o malé, jednokrokové transformácie zachovávajúce správanie a overiť každý krok
- Schopnosť identifikovať a uprednostniť technický dlh v rámci obchodného kontextu
Refaktoring je zlepšenie vnútornej štruktúry kódu bez zmeny jeho vonkajšieho správania: robí ho čitateľnejším, jednoduchším a udržiavateľnejším. Technický dlh je na druhej strane dizajnovým kompromisom vytvoreným v záujme rýchleho riešenia a splácaného „s úrokmi“ v priebehu času – každý roh, ktorý dnes preseknete, sa zajtra vráti ako spomalenie alebo chyba. Umelá inteligencia je výkonný asistent, ktorý urýchľuje opakujúce sa a mechanické refaktoringové úlohy; Existuje však jedno zlaté pravidlo refaktoringu a samotná AI ho nemôže zaručiť: správanie sa nesmie meniť.
V tejto jednotke sa naučíme, ako urobiť bezpečný refaktoring pomocou AI: malé a reverzibilné kroky, ochrana pomocou testov, zisťovanie pachov kódu a uprednostňovanie technického dlhu. Kritický bod je tento: sú to úspešné testy, nie slová AI, ktoré dokazujú, že správanie je zachované.
Zlaté pravidlo refaktoringu: Správanie zostáva konštantné
Čo robí refaktoring nebezpečným, je nevedomá zmena správania, zatiaľ čo hovorím „zlepšujem sa“. Vypustenie okrajového prípadu pri zjednodušovaní podmienky, porušenie poradia pri transformácii slučky, vynechanie vedľajšieho efektu pri rozdelení funkcie – to všetko vytvára „čisto vyzerajúci“, ale nefunkčný kód.
Preto je testovanie nevyhnutným predpokladom pre refaktoring: pred zmenou musíte mať testy, ktoré zachytávajú existujúce správanie. Tieto testy sú „záchrannou sieťou“; Ak pri refaktoringu náhodou niečo rozbijete, rozbijú sa a upozornia vás. Ak nemáte testy, najprv napíšte testy, ktoré opravia existujúce správanie (ako sme sa naučili v 5. kapitole) – tu začína umelá inteligencia.
Pozor: Refaktorovanie pomocou AI bez testovacej siete je jedným z najzákernejších zdrojov chýb. Je ľahké povedať „zachoval som správanie“; Dôkazom je, že rovnaké testy prejdú pred aj po zmene.
Krok za krokom: Bezpečný tok refaktorovania
- Nastavte bezpečnostnú sieť. Nech sú testy, ktoré zachytia aktuálne správanie kódu, ktorý budete refaktorovať; Ak nie, najprv si ich zapíšte (a uvidíte, ako prechádzajú).
- Pomenujte vôňu. Čo zlepšuješ a prečo? „Táto funkcia robí 3 veci“, „rovnaká logika sa opakuje na 4 miestach“, „mená sú zavádzajúce“.
- Požiadajte o malé, jednokrokové kroky. Požiadajte AI o jedinú transformáciu (napríklad len „rozdeľte túto funkciu na polovicu“), aby neprepisovala celý súbor.
- Spustite testy. Po každom kroku. Ak je zelená, pokračujte, ak je červená, vráťte ju späť.
- Prečítajte si Dif. Potvrďte riadok po riadku, že zmena skutočne zachováva správanie; Keď hovoríme, že AI je „len štruktúra“, môže dôjsť k logickému sklzu.
- Spojte na malé kúsky. Veľké jednorazové refaktorové PR sú riskantné a nepreskúmateľné.
Tri mini puzdrá
Prípad 1 — 220-riadková funkcia bezpečne rozdelená. Jeden tím mal funkciu spracovania objednávok s 220 riadkami. Bolo napísaných prvých 14 testov (s pomocou AI), ktoré zachytávali aktuálne správanie, všetky prešli. Potom bola funkcia krok za krokom pomocou AI rozdelená na 5 menších funkcií; Po každom kroku sa uskutočnili testy. Dva testy boli prerušené v jednom kroku - AI zmeškala návrat v prípade okraja. Testy to okamžite zachytili a opravili. Bez siete by sa chyba mohla dostať až do výroby.
Prípad 2 – Katastrofa bez testovacej siete. Ďalší vývojár „upratal“ modul na výpočet dátumu, ktorý nemal žiadne testy s AI. Kód vyzeral lepšie, ale nesprávne vypočítal priestupný rok; Chyba sa objavila o dva týždne neskôr so sťažnosťou zákazníka. Strata ďaleko prevýšila čas ušetrený pri refaktorizácii. Ponaučenie: refaktoring bez testovania je hazard.
Prípad 3 – Technická priorita dlhu. Jeden tím dal AI nevybavených približne 30 „zlepšiteľných“ bodov a každý z nich skóroval na osi „frekvencia zmien × riziko × úsilie“. Vo výslednej tabuľke mal škaredý modul, ktorého sa nikto nedotýkal, v skutočnosti nízku prioritu, zatiaľ čo modul strednej zložitosti, ktorý sa často menil, mal vysokú prioritu. Tým nasmeroval svoju energiu na správne miesto.
Štyri kopírovateľné šablóny
Detekcia vône kódu a stanovenie priorít:
Kandidát na refaktorovanie zoznamu „vonia“ v tomto kóde: dlhá funkcia, opakovanie (DRYViolation), zavádzajúci názov, hlboko vnorený stav, skrytý vedľajší účinok, magické číslo. Pre každú: miesto, prečo problém, navrhovaný malý krok, odhadované riziko (nízke/stredné/vysoké). Kód zatiaľ NEMEŇTE, len plánujte.{{code}}
Jednokroková transformácia zachovávajúca správanie:
STAČÍ urobiť toto: {{jednorazová konverzia, napr. Rozdeľte túto funkciu na 3 menšie pomenované funkcie}}. ZMENIŤ viditeľné správanie, podpis a návratové hodnoty. Jednou vetou napíšte, prečo všetko, čo ste zmenili, zachováva správanie.{{code}}
Bezpečnostná sieť pred refaktorom (testovanie vlastností):
Napíšte testy, ktoré zachytia AKTUÁLNE správanie tejto funkcie (správne alebo nie); cieľom je zachytiť, ak sa správanie zmení počas refaktoringu. Zahrňte typické + okrajové položky. Napíšte očakávania na základe aktuálneho výstupu funkcie.{{funkcia}}
Generovanie technického záznamu dlhu (nevybavených vecí):
Do tabuľky priorít nasypte nasledujúci zoznam pachov: látka, ovplyvnená oblasť, frekvencia zmien (moje znalosti: {{...}}), riziko, odhadované úsilie, odporúčaná priorita. Umiestnite tie s vysokým dopadom a nízkou námahou na vrch. {{smell_list}}
Slabá výzva / Silná výzva
Slabý: "Vyčistite tento kód a vylepšite ho."
Strong: "Rozdeľte túto 90-riadkovú funkciu na 3 menšie funkcie s jedinou zodpovednosťou, bez zmeny jej vonkajšieho správania a podpisu. Vedľajšie účinky (zápisy DB) ponechajte v aktuálnom poradí. Mám testy, správanie by malo zostať rovnaké. Uveďte rozdiel a jednou vetou vysvetlite, prečo každé rozdelenie zachováva správanie. [kód]“
Výkonná verzia; Vyžaduje jedinú špecifickú transformáciu, explicitne ukladá obmedzenie správania a podpisu a vyžaduje odôvodnenie. Nejasné požiadavky ako „urobte lepšie“ vedú k nekontrolovaným a riskantným zmenám.
Typ refaktoringu
Spoľahlivosť AI
Predpoklad
premenovať
vysoká
Je rozsah správny?
Rozdelenie funkcií
stredne vysoká
Testnet je nutnosťou
Opakovanie zdieľania
stredná
Rozdiel v správaní môže byť skrytý
Zmena algoritmu/štruktúry
nízka
Rozsiahle testovanie + overenie na ľuďoch
Architektonické preskupenie
nízka
Riadené ľuďmi, podporované AI
Správa technického dlhu, nie jeho vynulovanie
Technický dlh nie je zlý; Niekedy je vedomé požičiavanie (na splnenie dodávky) tým správnym rozhodnutím. Cieľom nie je eliminovať dlh, ale zviditeľniť ho a zvládnuť ho. Umelá inteligencia je rýchla pri zisťovaní a uprednostňovaní dlhu, ale rozhodovanie o tom, „ktorý dlh by sa mal zaplatiť a ktorý by sa mal vzdať“ si vyžaduje obchodný kontext: ako často sa tento modul mení, koľko ľudí to ovplyvňuje, aké je riziko? Toto rozhodnutie robí tím, ktorý pozná kódovú základňu a produkt; AI len objasňuje možnosti.
Tip: Udržujte svoje refaktoringové PR oddelené od PR, ktoré zahŕňajú zmenu správania. Schopnosť povedať „toto PR je len refaktoring, správanie je rovnaké“ uľahčuje vyšetrovanie a umožňuje vám rýchlo zúžiť príčinu, ak sa vyskytne problém.
Časté chyby
- Refaktorovanie bez testovacej siete. Nezostane vám nič, čo by dokázalo, že správanie je zachované.
- Znamená to „vymazať celý súbor“. Veľké, nekontrolované zmeny skryjú chybu a nedajú sa preskúmať.
- Prijatie rozdielu bez prečítania. AI možno pokĺzla z logiky, keď povedala „iba štruktúra“.
- Zamieňanie refaktoringu so zmenou správania. Robiť oboje v rovnakom PR znemožňuje sledovanie hlavnej príčiny.
- Snažím sa opraviť každý zápach. Škaredý kód, ktorý sa len zriedka mení, má často nízku prioritu; Prideľte energiu miestu, ktoré sa často mení.
V súhrne
Jediným pravidlom refaktoringu je, že správanie zostáva konštantné a dôkazom toho sú testy. Umelá inteligencia je výkonná pri zisťovaní pachov kódu, jednostupňových transformáciách a uprednostňovaní technického dlhu; ale musíte nastaviť bezpečnostnú sieť, spustiť testy a po každom kroku prečítať rozdiel. Urobte malé, vratné kroky; odlíšiť refaktoring od zmeny správania; a nechať tím, ktorý pozná obchodný kontext, rozhodnúť, ktorý dlh zaplatí.
Aplikačná úloha
Vyberte si zo základne kódu funkciu, ktorá sa vám zdá dlhá alebo zložitá. Najprv tlačové testy, ktoré zachytia jeho aktuálne správanie pomocou šablóny „safety net“ a zistite, či všetky prejdú. Potom nechajte funkciu refaktorovať jediným spôsobom (napr. rozdelením na polovicu) pomocou vzoru „jednostupňovej transformácie zachovávajúcej správanie“ a znova spustite testy. Ak sa test pokazí, zistite prečo; Ak sa vôbec nerozbije, prečítajte si rozdiel riadok po riadku, aby ste sa uistili, že správanie je skutočne zachované.
kontrolný zoznam
- [ ] Viem, že refaktoring by nemal zmeniť správanie a existujú testy, ktoré to dokazujú.
- [ ] Nastavujem bezpečnostnú sieť, ktorá zachytáva aktuálne správanie pred refaktorom.
- [ ] Chcem malé, jednokrokové transformácie od AI, nie veľké jednorazovky.
- [ ] Po každom kroku spustím testy a prečítam rozdiel.
- [ ] Stále refaktorujem PR oddelene od PR so zmenou správania.
- [ ] Uprednostňujem technický dlh s obchodným kontextom, nesnažím sa slepo vynulovať.