Mga nadagdag:
- Kakayahang mag-set up ng test safety net na kumukuha ng kasalukuyang gawi bago mag-refactor
- Kakayahang humingi ng AI para sa maliit, isang hakbang, mga pagbabagong pinapanatili ang pag-uugali at patunayan ang bawat hakbang
- Kakayahang kilalanin at unahin ang teknikal na utang sa loob ng konteksto ng negosyo
Ang refactoring ay pagpapabuti ng panloob na istruktura ng isang code nang hindi binabago ang panlabas na gawi nito: ginagawa itong mas nababasa, mas simple, mas mapanatili. Ang teknikal na utang, sa kabilang banda, ay isang kompromiso sa disenyo na ginawa para sa isang mabilis na solusyon at binayaran "nang may interes" sa paglipas ng panahon — bawat sulok na pinutol mo ngayon ay babalik bilang isang paghina o bug bukas. Ang artificial intelligence ay isang makapangyarihang katulong na nagpapabilis ng mga paulit-ulit at mekanikal na refactoring na gawain; Ngunit mayroong isang ginintuang tuntunin ng refactoring, at ang AI lamang ay hindi magagarantiyahan ito: ang pag-uugali ay hindi dapat magbago.
Sa unit na ito, natutunan namin kung paano gumawa ng ligtas na refactoring gamit ang AI: maliliit at nababaligtad na mga hakbang, pagprotekta gamit ang mga pagsubok, pag-detect ng mga amoy ng code at pagbibigay-priyoridad sa teknikal na utang. Ang kritikal na punto ay ito: ito ay ang pagpasa ng mga pagsubok, hindi ang salita ng AI, na nagpapatunay na ang pag-uugali ay napanatili.
Ang Ginintuang Panuntunan ng Refactoring: Ang Pag-uugali ay Nananatiling Hindi nagbabago
Ang dahilan kung bakit mapanganib ang refactoring ay ang hindi sinasadyang pagbabago ng gawi habang sinasabing "Nagpapabuti ako." Ang pag-drop ng isang gilid na case kapag pinasimple ang isang kundisyon, sinira ang pagkakasunud-sunod kapag nag-transform ng loop, walang side effect kapag hinahati ang isang function—lahat ay gumagawa ng "mukhang malinis" ngunit sirang code.
Iyon ang dahilan kung bakit ang pagsubok ay isang kinakailangan para sa refactoring: bago magbago, dapat ay mayroon kang mga pagsubok na kumukuha ng umiiral na gawi. Ang mga pagsusulit na ito ay isang "safety net"; Kung hindi mo sinasadyang masira ang isang bagay sa panahon ng refactoring, masisira ka nila at babalaan ka. Kung wala kang mga pagsubok, sumulat ng mga pagsubok na nag-aayos muna ng kasalukuyang gawi (tulad ng natutunan namin sa unit 5) — dito nagsisimula ang AI.
Mag-ingat: Ang refactoring na tinulungan ng AI na walang testnet ay isa sa mga pinaka mapanlinlang na pinagmumulan ng mga bug. Madaling sabihin na "Pinapanatili ko ang pag-uugali"; Ang patunay ay ang parehong mga pagsubok ay pumasa bago at pagkatapos ng pagbabago.
Hakbang sa Hakbang: Secure Refactoring Daloy
- I-set up ang safety net. Hayaang magkaroon ng mga pagsubok na kumukuha ng kasalukuyang pag-uugali ng code na iyong refactor; Kung hindi, isulat muna ang mga ito (at tingnan ang mga ito na dumaan).
- Pangalanan ang amoy. Ano ang pinagbubuti mo at bakit? "Ang function na ito ay gumagawa ng 3 bagay", "ang parehong lohika ay umuulit sa 4 na lugar", "mga pangalan ay nakaliligaw".
- Humingi ng maliit, isang hakbang na hakbang. Hilingin sa AI ang isang solong pagbabago (hal. "hatiin lamang ang function na ito sa kalahati"), hindi na muling isulat ang buong file.
- Patakbuhin ang mga pagsubok. Pagkatapos ng bawat hakbang. Kung berde, ituloy, kung pula, bawiin mo.
- Basahin ang Diff. Kumpirmahin ang bawat linya na ang pagbabago ay talagang pinapanatili ang pag-uugali; Maaaring may logic slippage kapag sinasabing ang AI ay "istraktura lang".
- Pagsamahin sa maliliit na piraso. Ang malalaking isang beses na refactoring PR ay parehong mapanganib at hindi nasusuri.
Tatlong Mini Case
Case 1 — 220-line function na ligtas na nahati. Ang isang koponan ay may 220-linya na pagpoproseso ng order. Ang unang 14 na pagsubok ay isinulat (sa tulong ng AI) na nakakuha ng kasalukuyang pag-uugali, lahat sila ay pumasa. Pagkatapos ay hinati ang function sa 5 mas maliliit na function step by step by AI; Ang mga pagsubok ay ginawa pagkatapos ng bawat hakbang. Dalawang pagsubok ang nasira sa isang hakbang — napalampas ng AI ang pagbabalik sa isang edge case. Nahuli ito kaagad ng mga pagsubok at naayos ito. Kung wala ang network, ang error ay maaaring napunta sa produksyon.
Kaso 2 — Kalamidad na walang testnet. Ang isa pang developer ay "naglinis" ng isang module ng pagkalkula ng petsa na walang mga pagsubok sa AI. Mas maganda ang hitsura ng code, ngunit mali ang pagkalkula ng leap year; Ang bug ay lumabas pagkalipas ng dalawang linggo na may reklamo ng customer. Ang pagkawala ay higit na lumampas sa oras na na-save mula sa refactoring. Aral: ang refactoring nang walang pagsubok ay isang sugal.
Kaso 3 — Pag-prioritize ng teknikal na utang. Isang team ang nagbigay sa AI ng backlog na 30 o higit pang "improvable" na puntos at ang bawat isa ay naka-score sa "change frequency × risk × effort" axis. Sa resultang talahanayan, ang isang pangit na module na bihirang mahawakan ay talagang isang mababang priyoridad, habang ang isang medium-complexity na module na madalas na nagbabago ay isang mataas na priyoridad. Itinuro ng koponan ang enerhiya nito sa tamang lugar.
Apat na Nakokopyang Template
Pagtukoy sa amoy ng code at pag-prioritize:
Ilista ang mga "amoy" ng kandidato sa refactoring sa code na ito: mahabang function, ulitin (DRYViolation), mapanlinlang na pangalan, malalim na nested na kondisyon, nakatagong side effect, magic number. Para sa bawat: lokasyon, bakit ang problema, iminungkahing maliit na hakbang, tinantyang panganib (mababa/medium/mataas). HUWAG PA BAGUHIN ang code, magplano lang.{{code}}
Isang hakbang, pagbabagong pinapanatili ang pag-uugali:
LANG gawin ito: {{iisang conversion, hal. Hatiin ang function na ito sa 3 mas maliit na pinangalanang function}}. BAGUHIN ang nakikitang gawi, lagda at mga halaga ng pagbabalik. Isulat sa 1 pangungusap kung bakit lahat ng binago mo ay nagpapanatili ng gawi.{{code}}
Safety net bago refactor (pagsusuri ng characterization):
Sumulat ng mga pagsubok na kumukuha ng KASALUKUYANG pag-uugali ng function na ito (tama o hindi); ang layunin ay mahuli kung nagbabago ang pag-uugali sa panahon ng refactoring. Isama ang karaniwang + edge na mga entry. Sumulat ng mga inaasahan batay sa kasalukuyang output ng function.{{function}}
Pagbuo ng talaan ng teknikal na utang (backlog):
Ibuhos ang sumusunod na listahan ng mga amoy sa isang talahanayan ng priyoridad: sangkap, lugar na apektado, dalas ng pagbabago (aking kaalaman: {{...}}), panganib, tinantyang pagsisikap, inirerekomendang priyoridad. Ilagay sa itaas ang mga high impact + low effort. {{smell_list}}
Mahinang prompt / Malakas na prompt
Mahina: "Linisin ang code na ito at gawin itong mas mahusay."
Strong: "Hatiin ang 90-line function na ito sa 3 mas maliliit na function na may iisang responsibilidad, nang hindi binabago ang panlabas na pag-uugali at lagda nito. Panatilihin ang mga side effect (nagsusulat ng DB) sa kasalukuyang pagkakasunud-sunod. Mayroon akong mga pagsubok, dapat manatiling pareho ang pag-uugali. Ibigay ang pagkakaiba at ipaliwanag sa isang pangungusap kung bakit ang bawat hati ay pinapanatili ang pag-uugali. [code]"
Napakahusay na bersyon; Nangangailangan ito ng isang partikular na pagbabago, tahasang nagpapataw ng isang pag-uugali at paghihigpit sa lagda, at humihingi ng katwiran. Ang mga hindi malinaw na kahilingan tulad ng "gumawa ng mas mahusay" ay humahantong sa hindi nakokontrol at mapanganib na mga pagbabago.
Uri ng refactoring
pagiging maaasahan ng AI
Prerequisite
palitan ang pangalan
mataas
Tama ba ang saklaw?
Dibisyon ng function
katamtaman-mataas
Testnet ay isang kinakailangan
Pagbabahagi ng pag-uulit
daluyan
Maaaring itago ang pagkakaiba ng ugali
Algorithm/pagbabago ng istruktura
mababa
Malawak na pagsubok + pagpapatunay ng tao
Pag-aayos ng arkitektura
mababa
Human-led, AI-supported
Pamamahala ng Teknikal na Utang, Hindi Nire-reset Ito
Ang teknikal na utang ay hindi lahat masama; Minsan ang malay na paghiram (upang matugunan ang isang paghahatid) ay ang tamang desisyon. Ang layunin ay hindi alisin ang utang, ngunit gawin itong nakikita at mapapamahalaan. Ang AI ay mabilis sa pag-detect at pag-prioritize ng utang, ngunit ang pagpapasya "kung aling utang ang dapat bayaran at kung alin ang dapat iwanan" ay nangangailangan ng konteksto ng negosyo: gaano kadalas nagbabago ang module na ito, gaano karaming tao ang naaapektuhan nito, ano ang panganib? Ang desisyong ito ay ginawa ng pangkat na nakakaalam ng code base at ng produkto; Nililinaw lang ng AI ang mga opsyon.
Tip: Panatilihing hiwalay ang iyong refactoring PR sa mga PR na may kinalaman sa pagbabago ng gawi. Ang kakayahang sabihin na "ang PR na ito ay isang refactoring lamang, ang pag-uugali ay pareho" ay nagpapadali sa pagsisiyasat at nagbibigay-daan sa iyo upang mabilis na paliitin ang dahilan kung may problema.
Mga karaniwang pagkakamali
- Refactoring nang walang testnet. Wala kang natitira upang patunayan na ang pag-uugali ay napanatili.
- Ang ibig sabihin nito ay "i-clear ang buong file". Itinatago ng malalaking, hindi nakokontrol na mga pagbabago ang error at hindi masusuri.
- Pagtanggap ng Diff nang hindi ito binabasa. Maaaring nadulas ng AI ang ilang lohika kapag sinabi nitong "istraktura lang".
- Nakakalito ang refactoring sa pagbabago ng pag-uugali. Ang paggawa ng pareho sa parehong PR ay ginagawang imposible ang pagsubaybay sa ugat.
- Sinusubukang ayusin ang bawat amoy. Ang pangit na code na bihirang magbago ay kadalasang mababa ang priyoridad; Maglaan ng enerhiya sa lugar na madalas nagbabago.
Sa buod
Ang tanging tuntunin ng refactoring ay ang pag-uugali ay nananatiling pare-pareho, at ang patunay nito ay ang mga pagsubok. Ang AI ay mahusay sa pag-detect ng mga amoy ng code, isang hakbang na pagbabago, at pagbibigay-priyoridad sa teknikal na utang; ngunit kailangan mong i-set up ang safety net, patakbuhin ang mga pagsubok at basahin ang diff pagkatapos ng bawat hakbang. Gumawa ng maliliit, nababaligtad na mga hakbang; makilala ang refactoring mula sa pagbabago ng pag-uugali; at hayaan ang pangkat na nakakaalam ng konteksto ng negosyo na magpasya kung aling utang ang babayaran.
Gawain ng aplikasyon
Pumili ng isang function mula sa iyong code base na mukhang mahaba o kumplikado sa iyo. Unang pag-print ng mga pagsubok na kumukuha ng kasalukuyang gawi nito gamit ang template na "safety net" at tingnan kung pumasa ang lahat. Pagkatapos ay i-refactor ang function sa isang paraan (hal. paghahati sa kalahati) gamit ang pattern na "one-step, behavior-pserving transformation" at patakbuhin muli ang mga pagsubok. Kung masira ang isang pagsubok, alamin kung bakit; Kung hindi man ito masira, basahin ang magkakaibang linya sa bawat linya upang kumpirmahin na ang pag-uugali ay talagang napanatili.
checklist
- [ ] Alam ko na ang refactoring ay hindi dapat magbago ng pag-uugali at may mga pagsubok upang patunayan ito.
- [ ] Nagse-set up ako ng safety net na nakakakuha ng kasalukuyang gawi bago ang refactor.
- [ ] Gusto ko ng maliliit, one-step na pagbabago mula sa AI, hindi malaking one-off.
- [ ] Pagkatapos ng bawat hakbang pinapatakbo ko ang mga pagsubok at binabasa ang diff.
- [ ] Patuloy kong nire-refactor ang PR na hiwalay sa pagbabago ng ugali PR.
- [ ] Inuuna ko ang teknikal na utang sa konteksto ng negosyo, hindi bulag na sinusubukang i-zero out.