Vienība 4 / 12

Kodu pārskatīšana, pārstrukturēšana un tehniskais parāds

Ieguvumi:

  • Spēja izmantot AI kā otro aci koda pārskatīšanā lasāmības, loģikas un drošības nolūkos
  • Iespēja plānot pārstrukturēšanas darbības ar AI atbalstu, neizjaucot sarežģītu koda darbību
  • Iespēja pārbaudīt AI pārskatu un rediģēt ieteikumus, izmantojot testēšanu un versiju kontroles salīdzinājumu

Programmatūras inženierijā kods tiek lasīts daudz vairāk, nekā tas tiek rakstīts. Koda rindiņa tiek uzrakstīta vienreiz, bet tiek lasīta, pārveidota un izveidota desmitiem reižu mēnešu laikā. Tāpēc koda pārskatīšana (cita vai sava koda pārskatīšana loģikai, lasāmībai un drošībai) un pārstrukturēšana (koda struktūras uzlabošana, nemainot tā uzvedību) ir inženierijas pamatā. AI kļūst par spēcīgu “otro aci” šiem diviem uzdevumiem: tas ātri ierosina lasāmību, norāda uz aizmirstajām loģikas un drošības problēmām un sadala lielu pārveidi mazākos drošos soļos. Bet ir svarīgs noteikums: pārstrukturēšanai nevajadzētu mainīt uzvedību, un vienīgais, kas to garantē, ir testēšana.

Šajā nodaļā mēs redzēsim, kā strukturētā veidā izmantot AI koda pārskatīšanai, kā salabot sarežģītu kodu, nepārkāpjot tā darbību, un kā pārvaldīt tehniskos parādus (ātrus, bet dārgus koda lēmumus).

Jēdzieni: Tehniskais parāds: šodien pieņemtie koda lēmumi ātrumam, kas apgrūtina apkopi nākotnē. Koda smarža: raksti, kas paši par sevi nav kļūdas, bet norāda uz problēmām (pārāk garas funkcijas, atkārtots kods). Regresija: kad izmaiņas izjauc kaut ko, kas iepriekš darbojās.

AI izmantošana strukturētā koda pārskatā

Kad laiks ir ierobežots, ir jākoncentrējas uz visaugstākā riska jautājumiem. Automātiskais formatētājs apstrādā formatēšanas problēmas, piemēram, atkāpes un atstarpes; Jums ir jāvelta cilvēka uzmanība loģikai, drošībai un ārkārtējai uzvedībai. Veicot AI pārskatīšanu, pieprasiet prioritāšu sarakstu, nevis vienkāršu atsauksmju gūzmu.

  1. Piešķiriet darbības jomu. Kāds kods, ko darīt, kādā kontekstā tas darbojas.
  2. Norādiet prioritātes asi. Pirmkārt, precizitāte un drošība, otrajā vietā lasāmība.
  3. Lūdziet konkrētu labojumu. “Kāpēc problēma” un “ieteicamais labojums” katram atradumam.
  4. Jūs pārbaudāt atklājumus. AI rada arī viltus pozitīvus rezultātus; Pārbaudiet katru atradumu, salīdzinot ar kodu un testēšanu.

Strukturētās pārskatīšanas uzvedne: "Pārbaudiet šo funkciju kā vecākais inženieris. Uzskaitiet konstatējumus svarīguma secībā un atzīmējiet tos ar šiem tagiem: [KRITISKA] loģika/drošība, [VIDĒJS] malas gadījums/veiktspēja, [Zema] lasāmība/nosaukums. Katram atradumam: kāpēc jautāt, konkrēts labošanas ieteikums. NEIZLAIDIET koda problēmas, tas apstrādās formatēšanas/kodēšanas rīku].

Uz drošību vērsta pārskatīšanas uzvedne: "Pārskatiet šo kodu tikai drošības nolūkos: ievades validācijas trūkums, injekcijas risks, autorizācijas kontroles trūkums, konfidenciālas informācijas noplūde, nedroši noklusējuma iestatījumi. Katram konstatējumam pievienojiet uzbrukuma scenārija piemēru. Ja nav drošības problēmu, skaidri norādiet "Es neatradu nekādas būtiskas drošības problēmas". Kods: [kods]."

Uzmanību: tas, ka mākslīgais intelekts saka "nav problēmu", nav pierādījums tam, ka problēmas nav. AI var radīt viltus negatīvus rezultātus; var apiet reālu drošības problēmu. AI pārskatīšana papildina, nevis aizstāj, cilvēka pārbaude un drošības pārbaude. Drošībai kritiskā kodā galīgais vārds ir kompetentajam inženierim.

Pārbaudes konservēta pārstrukturēšana

Refaktorēšanas zelta likums: vispirms pārbaudi, vēlāk maini. Pirms koda labošanas ir jāveic testi, kas bloķē pašreizējo darbību, lai jūs nekavējoties zinātu, vai izmaiņas kaut ko sabojā. Veicot mākslīgā intelekta pārveidošanu, nepārkāpjiet kārtību.

  1. Pārbaudi pašreizējo uzvedību. Pretējā gadījumā palūdziet AI izveidot “raksturošanas testu” (testu, kas fiksē pašreizējo uzvedību tādu, kāda tā ir).
  2. Labojiet to ar maziem soļiem. Pārbaudei katrā solī jāpaliek zaļai.
  3. Palaidiet to pēc katras darbības. Uztveriet regresiju agri.

Droša pārstrukturēšanas plāna uzvedne: "Šā 60 rindu funkcija dara pārāk daudz, un to ir grūti nolasīt. Es vēlos to pārveidot, nemainot tās darbību. Pirmkārt: uzskaitiet, kādi testa gadījumi ir nepieciešami, lai bloķētu pašreizējo darbību. Pēc tam: sadaliet pārstrukturēšanu mazos posmos, no kuriem katru var izpildīt, kamēr testi ir zaļā krāsā. Vēl nerakstiet kodu. Kods: vispirms iedodiet plānu].

Vāja uzvedne / spēcīga uzvedne

VĀJS: "Padariet šo kodu labāku." (Rezultāts: nav skaidrs, ko uzlabot; mākslīgais intelekts veic patvaļīgas izmaiņas, var klusi mainīt uzvedību.) STRONG: "Refaktorējiet šo maksājumu aprēķināšanas funkciju, lai nodrošinātu lasāmību. IEROBEŽOJUMS: uzvedībai ir jāpaliek tieši tādai pašai, atgriežamās vērtības nedrīkst mainīties. Sadaliet garo funkciju jēgpilnās lietderības funkcijās, palielinot maģiskos skaitļus līdz nosauktajām konstantēm. Uzskaitiet izmaiņas pēc vienumiem un paskaidrojiet, ka kods mainās.

Spēcīgā uzvedne skaidri norāda, ka "uzvedībai ir jāpaliek tieši tādai pašai" un kas ir jāuzlabo. Bez šī ierobežojuma AI var mainīt loģiku “uzlabošanas” vārdā un radīt klusu regresiju.

Tehnisko parādu pārvaldīšana

Pieeja

Īstermiņā

ilgtermiņā

ignorējot parādu

straujš progress

Apkopes paralīze, komandas bremzēšana

visu pārrakstīt

Stāvfunkciju attīstība

Nenoteikta atdeve, augsts risks

Izmērīta, ar testiem aizsargāta pārstrukturēšana

neliels palēninājums

Ilgtspējīgs ātrums

Veselīgākais ir trešais veids: padariet parādu redzamu (izsekojiet tam sarakstā), sāciet no vietas, kur tas sāp visvairāk, un pārbaudiet katru labojumu. AI ir labs palīgs parāda posteņu identificēšanā un prioritāšu noteikšanā, taču tas, kurš parāds jāmaksā, ir biznesa lēmums.

Mini futrāļi

1. gadījums — klusā regresija. Izstrādātājs liek AI “vienkāršot šo funkciju”; AI nepareizi pārtulko nosacījumu, un atdeves aprēķins ir bojāts. Tā kā testēšana nenotiek, kļūda rodas pēc 3 nedēļām ar klienta sūdzību. Komanda veic to pašu darbu, vispirms uzrakstot raksturojuma testu, un pirmajā piegājienā konstatē kļūdu ar sarkano testu.

2. gadījums — noderīga otrā acs. Pārskatot kodu, AI saprot, ka lietotāja autorizācija tiek pārbaudīta tikai saskarnē, nevis serverī. Šī ir nesankcionētas piekļuves ievainojamība. Inženieris pievieno servera puses autorizācijas pārbaudi; AI pārbaude novērš faktisku drošības incidentu.

3. gadījums — kļūdaini pozitīvs. AI saka: "šis mainīgais nekad netiek izmantots, izdzēsiet to"; Tomēr to izmanto netieši, izmantojot mainīgu refleksijas mehānismu. Ja inženieris nepārbauda ieteikumu attiecībā pret testu, tas tiks dzēsts un radīsies izpildlaika kļūda. Katrs AI atradums ir jāapstiprina pirms ieviešanas.

Biežas kļūdas

  • Pārveidošana bez pārbaudes. Nekas neatliek, lai nodrošinātu, ka uzvedība tiek saglabāta.
  • AI atklājumu pielietošana, tos neapstiprinot. Gadās gan viltus pozitīvi, gan viltus negatīvi.
  • Cilvēka laika tērēšana formāta problēmām. Koncentrēšanās uz uzdevumiem, kurus var atrisināt ar automatizētiem rīkiem, aizēno reālos riskus.
  • Atbildi "Nav problēmu" pieņemot kā garantiju. AI var apiet ievainojamību; nepieciešama cilvēka pārbaude.
  • Cenšas atmaksāt visu parādu uzreiz. Lielas pārrakstīšanas ir riskanta; Priekšroka tiek dota soļiem, kas tiek mērīti un aizsargāti ar testēšanu.

Rezumējot

Koda pārskatīšana un pārstrukturēšana nosaka koda ilgmūžību. AI ir jaudīgs otrās acs un plānu ģenerators: nodrošina prioritārus konstatējumus, drošības scenārijus un maza soļa pārstrukturēšanas plānus. Taču pārstrukturēšanai nevajadzētu mainīt uzvedību, un to garantē tikai testēšana. Apstipriniet katru AI konstatējumu, salīdzinot ar kodu un testēšanu; Neuztveriet atbildi "nav problēmu" kā pierādījumu. Padariet tehnisko parādu redzamu un nomaksājiet to izmērītā, pārbaudītā veidā.

Lietojumprogrammas uzdevums

Paņemiet 40–70 rindu, nedaudz sarežģītu funkciju (vai arī AI ģenerē). Vispirms izpildiet strukturētā pārskata uzvedni un sakārtojiet konstatējumus kā [KRITISKI]/[VIDĒJI]/[ZEMI]; Manuāli pārbaudiet vismaz vienu atradumu attiecībā pret kodu. Pēc tam, izmantojot drošas pārveidošanas plāna uzvedni, vispirms ģenerējiet un palaidiet raksturojuma testus, pēc tam veiciet pārstrukturēšanu mazos posmos un pārbaudiet, vai katrā darbībā testi paliek zaļi.

kontrolsaraksts

  • [ ] Es strukturēju pārskatu ar prioritārajiem tagiem (kritisks/vidējs/zems).
  • [ ] Esmu pārbaudījis vismaz vienu AI konstatējumu, salīdzinot ar kodu/testu.
  • [ ] Es pārbaudīju pašreizējo darbību pirms pārveidošanas.
  • [ ] Izmaiņas veicu mazos soļos un katrā solī veicu testus.
  • [ ] Uzvednē norādīju ierobežojumu “Uzvedībai ir jāpaliek nemainīgai”.
  • [ ] Esmu apstiprinājis, ka drošības konstatējumiem ir nepieciešams cilvēka apstiprinājums.