Fitimet:
- Aftësia për të ngritur një rrjet sigurie testimi që kap sjelljen aktuale përpara rifaktorimit
- Aftësia për të kërkuar AI për transformime të vogla, me një hap, që ruajnë sjelljen dhe për të vërtetuar çdo hap
- Aftësia për të identifikuar dhe prioritizuar borxhin teknik brenda kontekstit të biznesit
Rifaktorimi është përmirësimi i strukturës së brendshme të një kodi pa ndryshuar sjelljen e tij të jashtme: duke e bërë atë më të lexueshëm, më të thjeshtë, më të mirëmbajtur. Borxhi teknik, nga ana tjetër, është një kompromis i projektimit i bërë për hir të një zgjidhjeje të shpejtë dhe i paguar "me interes" me kalimin e kohës - çdo cep që shkurtoni sot do të kthehet si një ngadalësim ose defekt nesër. Inteligjenca artificiale është një asistent i fuqishëm që përshpejton detyrat e përsëritura dhe mekanike të rifaktorimit; Por ekziston një rregull i artë i rifaktorimit dhe AI vetëm nuk mund ta garantojë atë: sjellja nuk duhet të ndryshojë.
Në këtë njësi, ne mësojmë se si të bëjmë rifaktorim të sigurt me AI: hapa të vegjël dhe të kthyeshëm, mbrojtja me teste, zbulimi i erërave të kodit dhe prioritizimi i borxhit teknik. Pika kritike është kjo: janë kalueshmëria e testeve, jo fjala e AI, ajo që dëshmon se sjellja është ruajtur.
Rregulli i Artë i Rifaktorimit: Sjellja mbetet e qëndrueshme
Ajo që e bën rifaktorimin të rrezikshëm është ndryshimi i sjelljes në mënyrë të pavetëdijshme duke thënë "Unë jam duke u përmirësuar". Heqja e një korteze kur thjeshtohet një kusht, prishja e rendit kur transformohet një lak, humbja e një efekti anësor kur ndahet një funksion - të gjitha prodhojnë kod "me pamje të pastër", por të thyer.
Kjo është arsyeja pse testimi është një parakusht për rifaktorim: përpara se të ndryshoni, duhet të keni teste që kapin sjelljen ekzistuese. Këto teste janë një “rrjet sigurie”; Nëse aksidentalisht thyeni diçka gjatë rifaktorimit, ata do t'ju thyejnë dhe do t'ju paralajmërojnë. Nëse nuk keni teste, shkruani fillimisht teste që rregullojnë sjelljen ekzistuese (siç mësuam në kapitullin 5) - këtu fillon AI.
Kujdes: Rifaktorimi i ndihmuar nga AI pa një rrjet testues është një nga burimet më tinëzare të gabimeve. Është e lehtë të thuash "Kam ruajtur sjelljen"; Prova është se të njëjtat teste kalojnë para dhe pas ndryshimit.
Hap pas hapi: Siguroni rrjedhën e rifaktorimit
- Vendosni rrjetën e sigurisë. Le të ketë teste që kapin sjelljen aktuale të kodit që do të rifaktoroni; Nëse jo, shkruajini ato së pari (dhe shikoni që të kalojnë).
- Emërtoni erën. Çfarë po përmirësoni dhe pse? "Ky funksion bën 3 gjëra", "e njëjta logjikë përsëritet në 4 vende", "emrat janë mashtrues".
- Kërkoni hapa të vegjël me një hap. Kërkoni nga AI një transformim të vetëm (p.sh. thjesht "ndani këtë funksion në gjysmë"), për të mos rishkruar të gjithë skedarin.
- Kryeni testet. Pas çdo hapi. Nëse është jeshile, vazhdoni, nëse është e kuqe, merrni përsëri.
- Lexoni Diff. Konfirmoni rresht pas rreshti se ndryshimi është vërtet ruajtës i sjelljes; Mund të ketë një rrëshqitje logjike kur thuhet se AI është "thjesht strukturë".
- Përziejini në copa të vogla. PR-të e mëdha të rifaktorimit një herë janë të rrezikshme dhe të pakontrollueshme.
Tre Mini Rastet
Rasti 1 — Funksioni me 220 rreshta ndahet në mënyrë të sigurt. Një ekip kishte një funksion të përpunimit të porosive me 220 rreshta. U shkruan 14 testet e para (me ndihmën e AI) që kapën sjelljen aktuale, të gjitha kaluan. Më pas funksioni u nda në 5 funksione më të vogla hap pas hapi nga AI; Testet u kryen pas çdo hapi. Dy teste u prishën në një hap - AI kishte humbur kthimin në një rast skajor. Testet e kapën këtë menjëherë dhe e rregulluan. Pa rrjetin, gabimi mund të kishte shkuar deri në prodhim.
Rasti 2 - Fatkeqësi pa rrjetë testuese. Një tjetër zhvillues "pastroi" një modul të llogaritjes së datës që nuk kishte teste me AI. Kodi dukej më i mirë, por po llogaritte gabimisht vitin e brishtë; Defekti doli dy javë më vonë me një ankesë të klientit. Humbja e tejkaloi shumë kohën e kursyer nga rifaktorimi. Mësimi: rifaktorimi pa testim është një kumar.
Rasti 3 — Prioriteti teknik i borxhit. Një ekip i dha AI një grumbull prej 30 pikësh të "përmirësueshme" dhe secili prej tyre kishte shënuar në një bosht "ndryshimi i frekuencës × rrezikut × përpjekjes". Në tabelën që rezulton, një modul i shëmtuar që prekej rrallë ishte në fakt një prioritet i ulët, ndërsa një modul me kompleksitet të mesëm që ndryshonte shpesh ishte një prioritet i lartë. Ekipi e drejtoi energjinë e tij në vendin e duhur.
Katër modele të kopjueshme
Zbulimi dhe prioritizimi i erës së kodit:
Kandidati i rifaktorimit të listës "ndjen erë" në këtë kod: funksioni i gjatë, përsëritja (DRYShkelje), emër mashtrues, gjendje e thellë e mbivendosur, efekt anësor i fshehur, numër magjik. Për secilin: vendndodhja, pse problemi, hapi i sugjeruar i vogël, rreziku i vlerësuar (i ulët/mesatar/i lartë). MOS NDRYSHO kodin ende, thjesht planifiko.{{code}}
Transformimi me një hap, që ruan sjelljen:
THJESHT bëni këtë: {{ konvertim i vetëm, p.sh. Ndajeni këtë funksion në 3 funksione më të vogla me emër}}. NDRYSHO sjelljen e dukshme, nënshkrimin dhe vlerat e kthimit. Shkruani me 1 fjali pse gjithçka që keni ndryshuar ruan sjelljen.{{kodi}}
Rrjeta e sigurisë përpara refaktorit (testimi i karakteristikave):
Shkruani teste që kapin sjelljen AKTUALE të këtij funksioni (e saktë ose jo); qëllimi është të kapet nëse sjellja ndryshon gjatë rifaktorimit. Përfshini hyrjet tipike + buzë. Shkruani pritjet bazuar në daljen aktuale të funksionit.{{funksion}}
Gjenerimi i të dhënave teknike të borxhit (të prapambetura):
Hidhni listën e mëposhtme të aromave në një tabelë prioritizimi: substanca, zona e prekur, frekuenca e ndryshimit (dija ime: {{...}}), rreziku, përpjekjet e vlerësuara, përparësia e rekomanduar. Vendosni ato me ndikim të lartë + përpjekje të ulët në krye. {{lista_smell}}
Prompt i dobët / Prompt i fortë
E dobët: "Pastro këtë kod dhe përmirësoje".
Strong: "Ndajeni këtë funksion me 90 rreshta në 3 funksione më të vogla me përgjegjësi të vetme, pa ndryshuar sjelljen dhe nënshkrimin e tij të jashtëm. Mbani efektet anësore (shkruan DB) në rendin aktual. Unë kam teste, sjellja duhet të mbetet e njëjtë. Jepni ndryshimin dhe shpjegoni me një fjali pse çdo ndarje ruan sjelljen. [kodi]."
Version i fuqishëm; Ai kërkon një transformim të vetëm specifik, imponon në mënyrë eksplicite një kufizim sjelljeje dhe nënshkrimi dhe kërkon justifikim. Kërkesat e paqarta si "bëj më mirë" çojnë në ndryshime të pakontrolluara dhe të rrezikshme.
Lloji i rifaktorimit
Besueshmëria e AI
Kusht paraprak
riemërto
lartë
A është shtrirja e saktë?
Ndarja e funksionit
mesatar-i lartë
Testnet është një domosdoshmëri
Ndarja e përsëritjes
e mesme
Ndryshimi i sjelljes mund të jetë i fshehur
Ndryshimi i algoritmit/strukturës
të ulëta
Testim i gjerë + vërtetim njerëzor
Rirregullim arkitektonik
të ulëta
Të udhëhequr nga njerëzit, të mbështetur nga AI
Menaxhimi i borxhit teknik, jo rivendosja e tij
Borxhi teknik nuk është i keq; Ndonjëherë huamarrja e vetëdijshme (për të përmbushur një dorëzim) është vendimi i duhur. Qëllimi nuk është të eliminojmë borxhin, por ta bëjmë atë të dukshëm dhe të menaxhueshëm. AI është i shpejtë në zbulimin dhe prioritizimin e borxhit, por vendosja "cili borxh duhet paguar dhe cili duhet braktisur" kërkon kontekstin e biznesit: sa shpesh ndryshon ky modul, sa njerëz ndikon, cili është rreziku? Ky vendim merret nga ekipi që njeh bazën e kodit dhe produktin; AI thjesht sqaron opsionet.
Këshillë: Mbani PR-në tuaj të rifaktorimit të ndarë nga PR-të që përfshijnë ndryshimin e sjelljes. Të jesh në gjendje të thuash "ky PR është vetëm një rifaktorim, sjellja është e njëjtë" e bën më të lehtë hetimin dhe të lejon të kufizosh shpejt shkakun nëse lind një problem.
Gabimet e zakonshme
- Rifaktorimi pa një rrjet testues. Nuk ju ka mbetur asgjë për të vërtetuar se sjellja është ruajtur.
- Do të thotë "pastroni të gjithë skedarin". Ndryshimet e mëdha dhe të pakontrolluara fshehin gabimin dhe nuk mund të ekzaminohen.
- Pranimi i Diff pa e lexuar atë. AI mund të ketë rrëshqitur njëfarë logjike kur tha "vetëm strukturë".
- Ngatërrimi i rifaktorimit me ndryshimin e sjelljes. Bërja e të dyjave në të njëjtën PR e bën të pamundur ndjekjen e shkakut rrënjësor.
- Duke u përpjekur të rregulloni çdo erë. Kodi i shëmtuar që ndryshon rrallë është shpesh me prioritet të ulët; Shpërndani energjinë në vendin që ndryshon shpesh.
Në përmbledhje
Rregulli i vetëm i rifaktorimit është që sjellja të mbetet konstante, dhe prova për këtë janë testet. Inteligjenca artificiale është e fuqishme në zbulimin e aromave të kodit, transformimet me një hap dhe prioritizimin e borxhit teknik; por duhet të vendosni rrjetën e sigurisë, të kryeni testet dhe të lexoni ndryshimin pas çdo hapi. Merrni hapa të vegjël, të kthyeshëm; të dallojë rifaktorimin nga ndryshimi i sjelljes; dhe le ekipin që njeh kontekstin e biznesit të vendosë se cilin borxh të paguajë.
Detyra e aplikimit
Zgjidhni një funksion nga baza juaj e kodit që ju duket i gjatë ose kompleks. Fillimisht printoni teste që kapin sjelljen e tij aktuale me shabllonin "rrjeta e sigurisë" dhe shikoni nëse të gjitha kalojnë. Pastaj rifaktoroni funksionin në një mënyrë të vetme (p.sh. ndarja në gjysmë) me modelin "transformimi me një hap, që ruan sjelljen" dhe ekzekutoni përsëri testet. Nëse një test prishet, zbuloni pse; Nëse nuk prishet fare, lexoni ndryshimin rresht pas rreshti për të konfirmuar se sjellja është ruajtur vërtet.
listë kontrolli
- [ ] E di që rifaktorimi nuk duhet të ndryshojë sjelljen dhe ka teste për ta vërtetuar atë.
- [ ] Unë jam duke ngritur një rrjet sigurie që kap sjelljen aktuale përpara refaktorit.
- [ ] Unë dua transformime të vogla, me një hap nga AI, jo të mëdha të vetme.
- [ ] Pas çdo hapi kryej testet dhe lexoj ndryshimin.
- [ ] Unë vazhdoj të rifaktoroj PR-në e ndarë nga PR e ndryshimit të sjelljes.
- [ ] Unë i jap prioritet borxhit teknik me kontekstin e biznesit, jo verbërisht duke u përpjekur të zero.