Refaktorálás és műszaki adósságkezelés

Nyereség:

• Lehetőség egy tesztbiztonsági háló felállítására, amely rögzíti az aktuális viselkedést az átalakítás előtt
• Képes mesterséges intelligencia kérésére kis, egylépéses, viselkedésmegőrző átalakításokra és minden lépés érvényesítésére
• Képes azonosítani és rangsorolni a technikai adósságot az üzleti környezetben

Az átalakítás a kód belső szerkezetének javítása anélkül, hogy megváltoztatná a külső viselkedését: olvashatóbbá, egyszerűbbé, karbantarthatóbbá teszi. A műszaki adósság ezzel szemben egy olyan tervezési kompromisszum, amelyet a gyors megoldás érdekében kötöttek, és idővel "kamattal" fizetik vissza – minden ma levágott kanyar holnap lassulásként vagy hibaként jelentkezik. A mesterséges intelligencia egy hatékony asszisztens, amely felgyorsítja az ismétlődő és mechanikus refaktorálási feladatokat; De van egy aranyszabály az átalakításnak, és a mesterséges intelligencia önmagában nem tudja garantálni: a viselkedés nem változhat.

Ebben az egységben megtanuljuk, hogyan hajtsunk végre biztonságos refaktorálást mesterséges intelligencia segítségével: kis és visszafordítható lépések, tesztekkel való védelem, kódszagok észlelése és a technikai adósságok prioritása. A kritikus pont a következő: a sikeres tesztek, nem pedig az AI szava bizonyítja, hogy a viselkedés megmarad.

A refaktorálás aranyszabálya: A viselkedés állandó marad

A refaktorálást az teszi veszélyessé, hogy tudatlanul megváltoztatjuk a viselkedést, miközben azt mondjuk, hogy „javulok”. Egy éles kis- és nagybetű eldobása egy feltétel egyszerűsítésekor, a sorrend megtörése a ciklus átalakításakor, a mellékhatás hiánya a függvény felosztásakor – mindez "tiszta megjelenésű", de törött kódot eredményez.

Éppen ezért a tesztelés előfeltétele az átalakításnak: a változtatás előtt olyan tesztekkel kell rendelkeznie, amelyek rögzítik a meglévő viselkedést. Ezek a tesztek „biztonsági hálót” jelentenek; Ha véletlenül eltörsz valamit a refaktorálás során, akkor eltörik és figyelmeztetnek. Ha nincsenek tesztjei, először olyan teszteket írjon, amelyek javítják a meglévő viselkedést (ahogyan az 5. fejezetben megtanultuk) – ez az a hely, ahol az AI ugrásszerűen indul.

Vigyázat: A teszthálózat nélküli mesterséges intelligencia által támogatott refaktorálás a hibaforrások egyik legálomosabb forrása. Könnyű azt mondani, hogy „megőriztem a viselkedést”; A bizonyíték az, hogy ugyanazok a tesztek mennek át a változás előtt és után.

Lépésről lépésre: Biztonságos refaktorálási folyamat

1. Állítsa be a biztonsági hálót. Legyenek olyan tesztek, amelyek rögzítik az átdolgozandó kód jelenlegi viselkedését; Ha nem, először írja le őket (és nézze meg, hogyan mennek át).
2. Nevezze meg az illatot. Mit fejlesztesz és miért? "Ez a funkció 3 dolgot csinál", "ugyanaz a logika ismétlődik 4 helyen", "a nevek félrevezetőek".
3. Kérjen apró, egylépéses lépéseket. Kérjen az AI-tól egyetlen átalakítást (pl. csak „osztja fel ezt a funkciót”), ne pedig a teljes fájl átírását.
4. Futtassa le a teszteket. Minden lépés után. Ha zöld, folytasd, ha piros, vedd vissza.
5. Olvassa el a Diff. Sorról sorra erősítse meg, hogy a változás valóban magatartásmegőrző; Logikai csúszás történhet, ha azt mondjuk, hogy az AI „csak struktúra”.
6. Keverjük össze kis darabokra. A nagy, egyszeri refaktorálási PR-ok kockázatosak és felülvizsgálhatatlanok.

Három mini tok

1. eset – 220 soros funkció biztonságosan felosztva. Az egyik csapatnak 220 soros rendelésfeldolgozási funkciója volt. Az első 14 tesztet írtak (AI segítségével), amelyek rögzítik az aktuális viselkedést, és mindegyik sikeres volt. Ezután a funkciót az AI lépésről lépésre 5 kisebb funkcióra osztotta; A teszteket minden lépés után lefuttatták. Két teszt tönkrement egy lépésben – az AI elmulasztotta a visszatérést egy szélső esetben. A tesztek ezt azonnal észlelték és kijavították. Hálózat nélkül a hiba egészen a termelésig terjedhetett volna.

2. eset – Katasztrófa teszthálózat nélkül. Egy másik fejlesztő "megtisztított" egy dátumszámítási modult, amely nem tesztelte az AI-t. A kód jobban nézett ki, de rosszul számította ki a szökőévet; A hiba két héttel később jelent meg egy ügyfélpanasszal. A veszteség jóval meghaladta az újrahasznosítással megspórolt időt. Tanulság: a refaktorálás tesztelés nélkül szerencsejáték.

3. eset – Technikai adósságok prioritása. Az egyik csapat körülbelül 30 „javítható” pontot adott az MI-nek, és mindegyiket a „váltási gyakoriság × kockázat × erőfeszítés” tengelyen pontozták. Az eredményül kapott táblázatban egy csúnya modul, amelyhez ritkán nyúltak hozzá, valójában alacsony prioritást kapott, míg a közepesen bonyolult, gyakran cserélődő modul magas prioritást kapott. A csapat a megfelelő helyre irányította az energiáját.

Négy másolható sablon

Kódszagérzékelés és prioritás:

Sorolja fel a refaktoráló jelölt "szagát" ebben a kódban: hosszú függvény, ismétlés (DRYViolation), félrevezető név, mély beágyazott állapot, rejtett mellékhatás, mágikus szám. Mindegyiknél: hely, a probléma oka, javasolt kis lépés, becsült kockázat (alacsony/közepes/magas). MÉG NE MÓDOSÍTSA KÓDOT, csak tervezze meg.{{code}}

Egylépcsős, magatartásmegőrző átalakítás:

CSAK ezt tegye: {{egyszeri konverzió, pl. Osszuk ezt a függvényt 3 kisebb nevű függvényre}}. MÓDOSÍTSA MEG a látható viselkedést, az aláírást és a visszatérési értékeket. Írd le 1 mondatban, hogy miért őrzi meg minden, amit megváltoztattál.{{code}}

Biztonsági háló a refaktor előtt (jellemző vizsgálat):

Írjon teszteket, amelyek rögzítik a függvény AKTUÁLIS viselkedését (helyes vagy nem); a cél annak észlelése, ha a viselkedés megváltozik a refaktorálás során. Tartalmazzon tipikus + él bejegyzéseket. Írjon elvárásokat a függvény aktuális kimenete alapján.{{function}}

Műszaki adósságrekord (hátralék) generálása:

Öntse a következő szagok listáját egy prioritási táblázatba: anyag, érintett terület, változás gyakorisága (tudásom: {{...}}), kockázat, becsült erőfeszítés, ajánlott prioritás. Tedd a csúcsra a nagy hatású + alacsony erőfeszítést igénylőket. {{szaglista}}

Gyenge felszólítás / Erős felszólítás

Gyenge: "Tisztítsa meg ezt a kódot, és javítsa."

Erős: "Vasd fel ezt a 90 soros függvényt 3 kisebb függvényre, egyetlen felelősséggel, anélkül, hogy megváltoztatná a külső viselkedését és aláírását. Tartsa a mellékhatásokat (DB írja) az aktuális sorrendben. Vannak tesztjeim, a viselkedésnek változatlannak kell maradnia. Adja meg a különbséget, és magyarázza el egy mondatban, hogy az egyes felosztások miért viselkedésmegőrzőek. [kód]"

Erőteljes változat; Egyetlen konkrét átalakítást igényel, kifejezetten viselkedési és aláírási megszorítást ír elő, és megköveteli az indoklást. Az olyan homályos kérések, mint a „jobban csináld”, ellenőrizetlen és kockázatos változásokhoz vezetnek.

Refaktorálás típusa

AI megbízhatóság

Előfeltétel

átnevezni

magas

A távcső megfelelő?

Funkció felosztás

középmagas

A Testnet kötelező

Ismétlés megosztása

közepes

A viselkedésbeli különbségek rejtve lehetnek

Algoritmus/struktúra változás

alacsony

Kiterjedt tesztelés + emberi validálás

Építészeti átrendeződés

alacsony

Ember által vezetett, mesterséges intelligencia által támogatott

Műszaki adósság kezelése, nem törlesztése

A technikai adósság nem minden rossz; Néha a tudatos hitelfelvétel (a szállítás teljesítése érdekében) a helyes döntés. A cél nem az adósság megszüntetése, hanem annak láthatóvá, kezelhetővé tétele. A mesterséges intelligencia gyorsan észleli és rangsorolja az adósságokat, de annak eldöntéséhez, hogy „melyik adósságot kell kifizetni és melyiket kell elhagyni” üzleti kontextusra van szükség: milyen gyakran változik ez a modul, hány embert érint, mi a kockázat? Ezt a döntést az a csapat hozza meg, amely ismeri a kódbázist és a terméket; Az AI csak tisztázza a lehetőségeket.

Tipp: Tartsa elkülönítve a refaktorálási PR-t azoktól a PR-októl, amelyek viselkedésmódosítással járnak. Ha azt mondhatjuk, hogy "ez a PR csak egy újragondolás, a viselkedés ugyanaz", megkönnyíti a vizsgálatot, és lehetővé teszi, hogy probléma esetén gyorsan leszűkítse az okot.

Gyakori hibák

• Refaktorálás tesztnet nélkül. Semmi sem bizonyítja, hogy a viselkedés megmarad.
• Ez azt jelenti, hogy "a teljes fájl törlése". A nagy, ellenőrizetlen változtatások elrejtik a hibát, és nem vizsgálhatók.
• Diff elfogadása olvasás nélkül. Lehet, hogy a mesterséges intelligencia elrontott némi logikát, amikor azt mondta, hogy "csak szerkezet".
• A refaktorálás összekeverése a viselkedésváltozással. Ha mindkettőt ugyanabban a PR-ban csinálod, lehetetlenné teszi a kiváltó okok nyomon követését.
• Megpróbál minden szagot helyrehozni. A ritkán változó csúnya kód gyakran alacsony prioritású; Osszon energiát arra a helyre, amely gyakran változik.

Összefoglalva

A refaktorálás egyetlen szabálya, hogy a viselkedés állandó marad, és ennek bizonyítéka a tesztek. A mesterséges intelligencia hatékony a kódszagok, az egylépéses átalakítások észlelésében és a technikai adósságok rangsorolásában; de minden lépés után be kell állítani a biztonsági hálót, le kell futtatni a teszteket és ki kell olvasni a különbséget. Tegyen kis, visszafordítható lépéseket; megkülönböztetni a refaktorációt a viselkedésváltozástól; és hagyja, hogy az üzleti környezetet ismerő csapat döntse el, melyik adósságot fizesse ki.

Pályázati feladat

Válasszon egy függvényt a kódbázisból, amely hosszúnak vagy összetettnek tűnik Önnek. Első nyomtatási tesztek, amelyek rögzítik a jelenlegi viselkedést a "biztonsági háló" sablonnal, és megnézik, hogy mindegyik megfelel-e. Ezután a függvényt egyetlen módon (pl. kettéosztva) faktorálja újra az "egylépéses, viselkedést megőrző transzformáció" mintával, és futtassa újra a teszteket. Ha egy teszt megszakad, derítse ki, miért; Ha egyáltalán nem törik, olvassa el a különbséget soronként, hogy megbizonyosodjon arról, hogy a viselkedés valóban megmarad.

ellenőrző lista

• [ ] Tudom, hogy a refaktorálásnak nem szabad megváltoztatnia a viselkedést, és vannak tesztek, amelyek ezt bizonyítják.
• [ ] Biztonsági hálót állítok fel, amely felfogja az aktuális viselkedést a refaktor előtt.
• [ ] Kis, egylépéses átalakításokat szeretnék az AI-ból, nem pedig nagy egyszerieket.
• [ ] Minden lépés után lefuttatom a teszteket és elolvasom a különbséget.
• [ ] A PR refaktorálását külön tartom a viselkedésváltozás PR-tól.
• [ ] A technikai adósságot az üzleti kontextussal helyezem előtérbe, nem próbálom vakon nullázni.