Ieguvumi:
- Iespēja iestatīt testa drošības tīklu, kas fiksē pašreizējo uzvedību pirms pārveidošanas
- Spēja lūgt AI veikt nelielas, vienpakāpes, uzvedību saglabājošas transformācijas un apstiprināt katru soli
- Spēja identificēt un noteikt prioritāti tehnisko parādu uzņēmējdarbības kontekstā
Refaktorings ir koda iekšējās struktūras uzlabošana, nemainot tā ārējo darbību: padarot to lasāmāku, vienkāršāku, labāk uzturējamu. No otras puses, tehniskais parāds ir dizaina kompromiss, kas pieņemts ātra risinājuma labad un laika gaitā atmaksājās "ar procentiem" — katrs stūris, ko jūs šodien nogriezīsit, rīt atgriezīsies kā palēninājums vai kļūda. Mākslīgais intelekts ir spēcīgs palīgs, kas paātrina atkārtotus un mehāniskus pārstrukturēšanas uzdevumus; Taču ir viens zelta pārstrukturēšanas likums, un AI vien to nevar garantēt: uzvedība nedrīkst mainīties.
Šajā nodaļā mēs uzzinām, kā veikt drošu pārstrukturēšanu ar AI: mazas un atgriezeniskas darbības, aizsardzība ar testiem, koda smaku noteikšana un tehniskā parāda prioritātes noteikšana. Kritiskais punkts ir šāds: nokārtotie testi, nevis AI vārds, pierāda, ka uzvedība ir saglabāta.
Refaktoringa zelta likums: uzvedība paliek nemainīga
Tas, kas padara pārstrukturēšanu bīstamu, neapzināti maina uzvedību, vienlaikus sakot: "Es pilnveidojos". Atteikšanās no malas reģistra, vienkāršojot nosacījumu, izjaukt secību, pārveidojot cilpu, neizmantojot blakusefektu, sadalot funkciju — tas viss rada "tīru izskatu", bet bojātu kodu.
Tāpēc testēšana ir priekšnoteikums pārstrukturēšanai: pirms maiņas jums ir jābūt testiem, kas atspoguļo esošo uzvedību. Šie testi ir "drošības tīkls"; Ja jūs nejauši kaut ko salauzīsit pārstrukturēšanas laikā, viņi salauzīs un jūs brīdinās. Ja jums nav pārbaužu, vispirms uzrakstiet testus, kas nosaka esošo uzvedību (kā mēs uzzinājām 5. nodaļā) — šeit mākslīgais intelekts tiek iedarbināts.
Uzmanību: mākslīgā intelekta atbalstīta pārstrukturēšana bez testtīkla ir viens no mānīgākajiem kļūdu avotiem. Ir viegli pateikt "es saglabāju uzvedību"; Pierādījums ir tāds, ka pirms un pēc izmaiņām iziet tās pašas pārbaudes.
Soli pa solim: droša atjaunošanas plūsma
- Uzstādiet drošības tīklu. Lai ir testi, kas atspoguļo tā koda pašreizējo uzvedību, kuru refaktorēsit; Ja nē, vispirms pierakstiet tos (un skatieties, kā tie tiek izpildīti).
- Nosauc smaržu. Ko jūs uzlabojat un kāpēc? "Šī funkcija veic 3 lietas", "tā pati loģika atkārtojas 4 vietās", "nosaukumi ir maldinoši".
- Lūdziet veikt nelielus, vienpakāpes soļus. Lūdziet AI veikt vienu transformāciju (piemēram, vienkārši “sadaliet šo funkciju uz pusēm”), nevis pārrakstīt visu failu.
- Palaidiet testus. Pēc katra soļa. Ja tas ir zaļš, turpiniet, ja tas ir sarkans, paņemiet to atpakaļ.
- Lasīt Diff. Vienu pēc rindiņas apstipriniet, ka izmaiņas patiešām saglabā uzvedību; Sakot, ka AI ir "tikai struktūra", var rasties loģikas novirze.
- Sajauc mazos gabaliņos. Lieli vienreizēji pārstrukturēšanas PR ir gan riskanti, gan nepārskatāmi.
Trīs mini futrāļi
1. gadījums — 220 līniju funkcija droši sadalīta. Vienai komandai bija 220 rindu pasūtījumu apstrādes funkcija. Tika uzrakstīti pirmie 14 testi (ar AI palīdzību), kas fiksēja pašreizējo uzvedību, un tie visi izturēja. Pēc tam AI soli pa solim funkciju sadalīja 5 mazākās funkcijās; Testi tika veikti pēc katra soļa. Vienā solī tika izjaukti divi testi — AI bija nokavējis atgriešanos malas korpusā. Pārbaudes to nekavējoties konstatēja un laboja. Ja nebūtu tīkla, kļūda varētu būt nonākusi līdz pat ražošanai.
2. gadījums — katastrofa bez testtīkla. Cits izstrādātājs "iztīrīja" datuma aprēķināšanas moduli, kuram nebija testu ar AI. Kods izskatījās labāk, taču tas nepareizi aprēķināja garo gadu; Kļūda parādījās divas nedēļas vēlāk ar klienta sūdzību. Zaudējums ievērojami pārsniedza pārstrukturēšanas ietaupīto laiku. Nodarbība: refaktorings bez pārbaudes ir azarts.
3. gadījums — Tehniskā parāda prioritāšu noteikšana. Viena komanda AI piešķīra aptuveni 30 “uzlabojamus” punktus, un katra no tām ieguva punktu “maiņu biežums × risks × piepūle”. Iegūtajā tabulā neglīts modulis, kuram tika pieskarties reti, faktiski bija zema prioritāte, savukārt vidējas sarežģītības modulis, kas bieži tika mainīts, bija augsta prioritāte. Komanda savu enerģiju novirzīja pareizajā vietā.
Četras kopējamas veidnes
Koda smaržas noteikšana un prioritāšu noteikšana:
Saraksta pārstrukturēšanas kandidāts "smaržo" šajā kodā: gara funkcija, atkārtojums (DRYViolation), maldinošs nosaukums, dziļi ligzdots stāvoklis, slēpta blakusparādība, maģisks skaitlis. Katram: atrašanās vieta, problēmas iemesls, ieteiktais mazais solis, aprēķinātais risks (zems/vidējs/augsts). Vēl NEMAINIET kodu, vienkārši plānojiet.{{code}}
Vienpakāpes, uzvedību saglabājoša transformācija:
TIKAI rīkojieties šādi: {{viena konversija, piem. Sadaliet šo funkciju 3 mazākās funkcijās ar nosaukumu}}. MAINĪT redzamo uzvedību, parakstu un atgriešanas vērtības. Vienā teikumā uzrakstiet, kāpēc viss, ko mainījāt, saglabā darbību.{{code}}
Drošības tīkls pirms reaktora (raksturojuma pārbaude):
Uzrakstiet testus, kas atspoguļo šīs funkcijas PAŠREIZĒJO uzvedību (pareizi vai nē); mērķis ir uztvert, vai uzvedība mainās pārstrukturēšanas laikā. Iekļaut tipiskus + malas ierakstus. Uzrakstiet cerības, pamatojoties uz funkcijas pašreizējo izvadi.{{function}}
Tehnisko parādu ierakstu (nepaveikto) ģenerēšana:
Ievietojiet šādu smaku sarakstu prioritāšu tabulā: viela, ietekmētā zona, izmaiņu biežums (manas zināšanas: {{...}}), risks, paredzamās pūles, ieteicamā prioritāte. Novietojiet augšpusē spēcīgu triecienu + zemu piepūli. {{smell_list}}
Vāja uzvedne / spēcīga uzvedne
Vāji: "Iztīriet šo kodu un uzlabojiet to."
Spēcīgs: "Sadaliet šo 90 rindu funkciju 3 mazākās funkcijās ar vienu atbildību, nemainot tās ārējo uzvedību un parakstu. Saglabājiet blakusefektus (DB raksta) pašreizējā secībā. Man ir testi, uzvedībai vajadzētu palikt nemainīgai. Norādiet atšķirību un vienā teikumā paskaidrojiet, kāpēc katrs sadalījums ir uzvedību saglabājošs. [kods]"
Jaudīga versija; Tas prasa vienu konkrētu transformāciju, skaidri uzliek uzvedības un paraksta ierobežojumu un prasa pamatojumu. Neskaidri pieprasījumi, piemēram, "darīt labāk", noved pie nekontrolētām un riskantām izmaiņām.
Refaktoringa veids
AI uzticamība
Priekšnoteikums
pārdēvēt
augsts
Vai tvērums ir pareizs?
Funkciju iedalījums
vidēji augsts
Testnet ir obligāts
Dalīšanās atkārtojumā
vidējs
Uzvedības atšķirības var būt paslēptas
Algoritma/struktūras maiņa
zems
Plaša pārbaude + cilvēka validācija
Arhitektūras pārkārtošana
zems
Cilvēka vadīts, mākslīgais intelekts atbalstīts
Tehniskā parāda pārvaldīšana, nevis tā dzēšana
Tehniskais parāds nav slikts; Dažreiz apzināta aizņemšanās (lai izpildītu piegādi) ir pareizais lēmums. Mērķis nav likvidēt parādu, bet gan padarīt to redzamu un pārvaldāmu. AI ātri atklāj parādus un nosaka to prioritātes, taču, lai izlemtu, “kurš parāds ir jāmaksā un no kura jāatsakās”, ir nepieciešams biznesa konteksts: cik bieži šis modulis mainās, cik cilvēku tas ietekmē, kāds ir risks? Šo lēmumu pieņem komanda, kas zina koda bāzi un produktu; AI tikai precizē iespējas.
Padoms. Saglabājiet savu pārstrukturēšanas PR atsevišķi no PR, kas ietver uzvedības izmaiņas. Spēja teikt: "šis PR ir tikai pārveidojums, uzvedība ir tāda pati", atvieglo izmeklēšanu un ļauj ātri sašaurināt cēloni, ja rodas problēma.
Biežas kļūdas
- Refaktorings bez testneta. Jums nav nekas, kas pierādītu, ka uzvedība ir saglabāta.
- Tas nozīmē "notīrīt visu failu". Lielas, nekontrolētas izmaiņas slēpj kļūdu, un tās nevar pārbaudīt.
- Diff pieņemšana, to neizlasot. AI, iespējams, ir noslīdējusi loģiku, sakot "tikai struktūra".
- Mulsinoša refaktorēšana ar uzvedības izmaiņām. Veicot abus vienā PR, nav iespējams izsekot pamatcēloņiem.
- Cenšas salabot katru smaku. Neglīts kods, kas reti mainās, bieži ir zemas prioritātes; Piešķiriet enerģiju vietai, kas bieži mainās.
Rezumējot
Vienīgais pārstrukturēšanas noteikums ir tāds, ka uzvedība paliek nemainīga, un pierādījums tam ir testi. AI spēj noteikt koda smakas, vienpakāpju transformācijas un noteikt tehniskā parāda prioritāti; bet jums ir jāiestata drošības tīkls, jāveic testi un jāizlasa atšķirība pēc katras darbības. Veiciet mazus, atgriezeniskus soļus; atšķirt refaktororu no uzvedības izmaiņām; un ļaujiet komandai, kas zina uzņēmējdarbības kontekstu, izlemt, kuru parādu maksāt.
Lietojumprogrammas uzdevums
Izvēlieties funkciju no savas koda bāzes, kas jums šķiet gara vai sarežģīta. Pirmās drukas pārbaudes, kurās tiek fiksēta tā pašreizējā darbība, izmantojot "drošības tīkla" veidni, un pārbaudīt, vai tie visi ir izturējuši. Pēc tam iestatiet funkciju vienā veidā (piemēram, sadalot uz pusēm) ar "vienpakāpju, uzvedību saglabājošu transformāciju" modeli un palaidiet testus vēlreiz. Ja tests sabojājas, uzziniet, kāpēc; Ja tas nemaz neplīst, izlasiet atšķirību rindiņu pa rindiņai, lai pārliecinātos, ka darbība patiešām ir saglabāta.
kontrolsaraksts
- [ ] Es zinu, ka pārstrukturēšanai nevajadzētu mainīt uzvedību, un ir testi, lai to pierādītu.
- [ ] Es izveidoju drošības tīklu, kas uztver pašreizējo uzvedību pirms faktora.
- [ ] Es gribu nelielas, vienpakāpes transformācijas no AI, nevis lielas vienreizējas.
- [ ] Pēc katras darbības es izpildu testus un nolasu atšķirības.
- [ ] Es turēju PR pārstrukturēšanu atsevišķi no uzvedības maiņas PR.
- [ ] Tehniskajam parādam prioritāti piešķiru biznesa kontekstu, nevis akli cenšos atkāpties no nulles.