zisky:
- Schopnost nastavit testovací bezpečnostní síť, která zachytí aktuální chování před refaktorizací
- Schopnost požádat AI o malé, jednokrokové transformace zachovávající chování a ověřit každý krok
- Schopnost identifikovat a upřednostňovat technický dluh v rámci obchodního kontextu
Refaktoring vylepšuje vnitřní strukturu kódu, aniž by měnil jeho vnější chování: činí jej čitelnějším, jednodušším a udržitelnějším. Technický dluh je na druhé straně konstrukčním kompromisem vytvořeným v zájmu rychlého řešení a splácený časem „s úroky“ – každý roh, který dnes uříznete, se zítra vrátí jako zpomalení nebo chyba. Umělá inteligence je výkonný asistent, který urychluje opakující se a mechanické refaktoringové úlohy; Existuje však jedno zlaté pravidlo refaktoringu a samotná AI ho nemůže zaručit: chování se nesmí změnit.
V této jednotce se naučíme, jak provádět bezpečný refaktoring pomocí AI: malé a vratné kroky, ochrana pomocí testů, zjišťování pachů kódu a upřednostňování technického dluhu. Kritický bod je tento: jsou to úspěšné testy, nikoli slovo AI, co dokazuje, že chování je zachováno.
Zlaté pravidlo refaktoringu: Chování zůstává konstantní
To, co dělá refaktoring nebezpečným, je nevědomá změna chování, když říkáte „zlepšuju se“. Vypuštění okrajového případu při zjednodušování podmínky, porušení pořadí při transformaci smyčky, vynechání vedlejšího efektu při rozdělování funkce – to vše vytváří „čistý“, ale nefunkční kód.
Proto je testování nezbytným předpokladem pro refaktoring: před změnou musíte mít testy, které zachycují stávající chování. Tyto testy jsou „záchrannou sítí“; Pokud při refaktorování něco náhodou rozbijete, rozbijí se a varují vás. Pokud nemáte testy, napište nejprve testy, které opraví stávající chování (jak jsme se naučili v lekci 5) – zde začíná umělá inteligence.
Upozornění: Refaktorování pomocí AI bez testovací sítě je jedním z nejzákeřnějších zdrojů chyb. Je snadné říci „zachoval jsem chování“; Důkazem je, že stejné testy projdou před změnou i po ní.
Krok za krokem: Zabezpečte tok refaktoringu
- Nastavte ochrannou síť. Nechť existují testy, které zachytí aktuální chování kódu, který budete refaktorovat; Pokud ne, nejprve si je zapište (a uvidíte, jak procházejí).
- Pojmenujte vůni. Co zlepšujete a proč? "Tato funkce dělá 3 věci", "stejná logika se opakuje na 4 místech", "jména jsou zavádějící".
- Požádejte o malé, jednokrokové kroky. Požádejte AI o jedinou transformaci (např. pouze „rozdělte tuto funkci na polovinu“), aby nepřepisovala celý soubor.
- Spusťte testy. Po každém kroku. Pokud je zelená, pokračujte, pokud je červená, vezměte ji zpět.
- Přečtěte si Rozdíl. Potvrďte řádek po řádku, že změna skutečně zachovává chování; Když říkáte, že AI je „jen struktura“, může dojít k logickému skluzu.
- Spojte na malé kousky. Velká jednorázová refaktoringová PR jsou riskantní a nepřezkoumatelná.
Tři mini pouzdra
Případ 1 — Funkce 220 řádků bezpečně rozdělena. Jeden tým měl funkci zpracování objednávek o 220 řádcích. Bylo napsáno prvních 14 testů (s pomocí AI), které zachytily aktuální chování, všechny prošly. Poté byla funkce rozdělena na 5 menších funkcí krok za krokem pomocí AI; Po každém kroku byly provedeny testy. Dva testy byly přerušeny v jednom kroku - AI minula návrat v okrajovém případě. Testy to okamžitě zachytily a opravily. Bez sítě by se chyba mohla dostat až do výroby.
Případ 2 – Katastrofa bez testovací sítě. Jiný vývojář „vyčistil“ modul pro výpočet data, který neměl žádné testy s AI. Kód vypadal lépe, ale špatně počítal přestupný rok; Chyba se objevila o dva týdny později se stížností zákazníka. Ztráta daleko převážila čas ušetřený refaktorizací. Poučení: refaktoring bez testování je hazard.
Případ 3 – Stanovení priority technického dluhu. Jeden tým dal AI nevyřízených asi 30 „zlepšitelných“ bodů a každý z nich skóroval na ose „frekvence změny × riziko × úsilí“. Ve výsledné tabulce měl ošklivý modul, kterého se nikdo nedotýkal, ve skutečnosti nízkou prioritu, zatímco modul se střední složitostí, který se často měnil, měl vysokou prioritu. Tým nasměroval svou energii na správné místo.
Čtyři kopírovatelné šablony
Detekce pachu kódu a stanovení priorit:
Kandidát na refaktorování seznamu „zapáchá“ v tomto kódu: dlouhá funkce, opakování (DRYViolation), zavádějící název, hluboko vnořený stav, skrytý vedlejší efekt, magické číslo. U každého: místo, proč problém, navrhovaný malý krok, odhadované riziko (nízké/střední/vysoké). Kód zatím NEMĚŇTE, jen plánujte.{{code}}
Jednokroková transformace zachovávající chování:
STAČÍ udělat toto: {{jednotlivá konverze, např. Rozdělte tuto funkci na 3 menší pojmenované funkce}}. ZMĚŇTE viditelné chování, podpis a návratové hodnoty. Napište jednou větou, proč vše, co jste změnili, zachovává dané chování.{{code}}
Bezpečnostní síť před refaktorem (testování vlastností):
Napište testy, které zachytí AKTUÁLNÍ chování této funkce (správné nebo ne); cílem je zachytit, pokud se chování změní během refaktoringu. Zahrňte typické + okrajové položky. Napište očekávání na základě aktuálního výstupu funkce.{{funkce}}
Generování technického záznamu o dluhu (nevyřízené položky):
Do tabulky priorit nasypte následující seznam pachů: látka, postižená oblast, frekvence změn (moje znalosti: {{...}}), riziko, odhadovaná námaha, doporučená priorita. Nahoře umístěte ty s vysokým dopadem a nízkou námahou. {{smell_list}}
Slabá výzva / Silná výzva
Slabý: "Vyčistěte tento kód a vylepšete jej."
Strong: "Rozdělte tuto 90řádkovou funkci na 3 menší funkce s jedinou odpovědností, aniž byste změnili její vnější chování a podpis. Udržujte vedlejší účinky (zápisy DB) v aktuálním pořadí. Mám testy, chování by mělo zůstat stejné. Uveďte rozdíl a jednou větou vysvětlete, proč každé rozdělení zachovává chování. [kód]"
Výkonná verze; Vyžaduje jedinou specifickou transformaci, výslovně ukládá omezení chování a podpisu a vyžaduje zdůvodnění. Vágní požadavky jako „udělej lépe“ vedou k nekontrolovaným a riskantním změnám.
Typ refaktoringu
Spolehlivost AI
Předpoklad
přejmenovat
vysoká
Je rozsah správný?
Rozdělení funkcí
středně vysoká
Testnet je nutností
Sdílení opakování
střední
Rozdíl v chování může být skrytý
Změna algoritmu/struktury
nízká
Rozsáhlé testování + ověření na lidech
Architektonické přeskupení
nízká
Lidmi vedené, AI podporované
Správa technického dluhu, nikoli jeho resetování
Technický dluh není špatný; Někdy je vědomé půjčování (pro splnění dodávky) správným rozhodnutím. Cílem není dluh odstranit, ale zviditelnit a zvládnout. Umělá inteligence je rychlá v odhalování a upřednostňování dluhů, ale rozhodování o tom, „který dluh by měl být zaplacen a který by měl být opuštěn“ vyžaduje obchodní kontext: jak často se tento modul mění, na kolik lidí se to týká, jaké je riziko? Toto rozhodnutí činí tým, který zná základnu kódu a produkt; AI jen upřesňuje možnosti.
Tip: Udržujte své refaktoringové PR oddělené od PR, které zahrnují změnu chování. Schopnost říci „toto PR je jen refaktoring, chování je stejné“ usnadňuje vyšetřování a umožňuje rychle zúžit příčinu, pokud se objeví problém.
Časté chyby
- Refaktoring bez testovací sítě. Nezbývá vám nic dokazovat, že chování je zachováno.
- Znamená to "vymazat celý soubor". Velké, nekontrolované změny skryjí chybu a nelze je prozkoumat.
- Přijímání rozdílu bez čtení. Umělá inteligence možná vyklouzla z logiky, když řekla „jen struktura“.
- Záměna refaktoringu se změnou chování. Dělat obojí ve stejném PR znemožňuje sledování hlavní příčiny.
- Snaží se opravit každý zápach. Ošklivý kód, který se jen zřídka mění, má často nízkou prioritu; Přidělte energii místu, které se často mění.
V souhrnu
Jediným pravidlem refaktoringu je, že chování zůstává konstantní a důkazem toho jsou testy. Umělá inteligence je výkonná při zjišťování pachů kódu, jednokrokových transformací a upřednostňování technického dluhu; ale musíte nastavit záchrannou síť, spustit testy a přečíst rozdíl po každém kroku. Dělejte malé, vratné kroky; odlišit refaktoring od změny chování; a nechat tým, který zná obchodní kontext, rozhodnout, jaký dluh zaplatí.
Aplikační úkol
Vyberte si ze své kódové základny funkci, která se vám zdá dlouhá nebo složitá. Nejprve vytiskněte testy, které zachycují jeho aktuální chování pomocí šablony „safety net“ a zjistěte, zda všechny projdou. Poté nechte funkci refaktorovat jediným způsobem (např. rozdělením na polovinu) pomocí vzoru „jednokroková transformace zachovávající chování“ a spusťte testy znovu. Pokud se test pokazí, zjistěte proč; Pokud se vůbec nerozbije, přečtěte si rozdíl řádek po řádku, abyste potvrdili, že chování je skutečně zachováno.
kontrolní seznam
- [ ] Vím, že refaktoring by neměl změnit chování a existují testy, které to dokazují.
- [ ] Nastavuji záchrannou síť, která zachytí aktuální chování před refaktorem.
- [ ] Chci malé, jednokrokové transformace od AI, ne velké jednorázové.
- [ ] Po každém kroku spustím testy a přečtu rozdíl.
- [ ] Stále refaktoruji PR odděleně od PR změn chování.
- [ ] Upřednostňuji technický dluh s obchodním kontextem, nesnažím se slepě vynulovat.