Pag-refactor: ano ito, mga layunin at pamamaraan ng refactoring sa pag-develop

Ano ang ibig sabihin ng mag-refactor sa programming

Mag-refactor — ay ang proseso ng pagbabago ng panloob na istraktura ng code ng programa na may layuning pagbutihin ang mga katangian ng kalidad nito nang hindi binabago ang napapansing pag-uugali. Ang termino ay ipinakilala sa malawakang paggamit ni Martin Fowler noong 1999, at ang kasanayan mismo ay naging isa sa mga pundasyon ng maliksi na pag-develop at extreme programming.

Ang pangunahing katangian ng refactoring — pagpapanatili ng functionality. Pagkatapos ng refactoring, ang programa ay dapat magsagawa ng eksaktong parehong mga aksyon at magbalik ng parehong mga resulta tulad ng bago ang mga pagbabago. Ang garantiya nito ay ang automated na mga test na pinapatakbo pagkatapos ng bawat micro-step ng refactoring. Kung ang mga test ay berde — ang pag-uugali ay napanatili. Kung pula — ang refactoring ay naisagawa nang hindi tama o nagbago ang pag-uugali, na nangangahulugang ito ay hindi na refactoring, kundi pagbabago ng functionality.

Sa industriya mayroong isang matigas na maling akala: ang bawat pagkukumpuni ng code ay tinatawag na refactoring. Sa katotohanan, ang muling pagsulat ng code na may pagbabago ng pag-uugali ay “rewrite” o “rework”, hindi refactoring. Ang pagkakaiba ay pangunahing: ang refactoring ay isang kontrolado, ligtas na proseso, samantalang ang muling pagsulat na may pagbabago ng lohika ay isang ganap na bagong pag-develop na may lahat ng kaakibat na panganib.

Ang kapitalisasyon ng kaalaman tungkol sa refactoring sa kapaligirang nagsasalita ng Filipino ay nangyayari sa pamamagitan ng parehong mekanismo tulad ng para sa iba pang mga IT termino: paghiram sa Ingles na refactor na may pagdaragdag ng panlaping Filipino. Ang mga programang pang-edukasyon sa Software Engineering at mga pagsasalin ng libro ay nagpatibay ng terminong ito sa propesyonal na leksikon.

Refactoring vs Muling Pagsulat

Mahalagang makilala ang refactoring mula sa ganap na muling pagsulat ng code (rewrite). Refactoring — ay isang serye ng maliliit, ligtas na mga pagbabago, na bawat isa ay nagpapanatili ng pag-uugali. Ang muling pagsulat — paglikha ng bagong implementasyon mula sa simula, madalas na may pagbabago ng arkitektura, teknolohiya at pag-uugali. Ang pananaliksik ng Standish Group (2023) ay nagpapakita na ang mga proyektong pumili ng ganap na rewrite ay nabibigo sa 40% ng mga kaso, samantalang ang mga proyektong nagsasagawa ng regular na refactoring ay may 25% na mas mababang antas ng utang teknikal.

Bakit mag-refactor ng code: mga pangunahing layunin

Ang refactoring ay lumulutas ng ilang pangunahing gawain, na bawat isa ay direktang nakakaapekto sa bilis at gastos ng pag-develop. Ang pag-unawa sa mga layuning ito ay tumutulong sa koponan na magtakda ng mga prayoridad nang tama at bigyang-katwiran ang oras na ginugol sa refactoring sa harap ng mga stakeholder.

Pagpapabuti ng pagiging nababasa at nauunawaan

Ang code ay isinulat nang isang beses, ngunit binabasa nang dose-dosenang at daan-daang beses. Kung ang isang developer ay gumugugol ng 30 minuto sa pag-unawa kung ano ang ginagawa ng isang function — iyon ay direktang pagkawala ng produktibidad. Nababasang code ay nagbabawas ng cognitive load at nagpapabilis sa onboarding ng mga bagong miyembro ng koponan. Ang mga pamamaraan tulad ng Rename Method, Extract Variable at Introduce Explaining Variable ay tiyak na nakatuon sa pagtaas ng pagkaunawa ng code. Ayon sa pananaliksik ng Developer Productivity (Microsoft Research, 2023), ang mga developer ay gumugugol ng hanggang 60% ng kanilang oras sa pagbabasa ng code, hindi sa pagsulat nito, na ginagawang ang pagiging nababasa ay isa sa mga pangunahing salik ng produktibidad.

Pag-aalis ng duplikasyon

Ang prinsipyong DRY (Don’t Repeat Yourself) — isa sa mga pundamental sa programming. Ang duplikasyon ng code ay humahantong sa parehong pagbabago na kailangang gawin sa maraming lugar, na nagpapataas ng panganib ng mga pagkakamali at nakalimutang pag-aayos. Ang refactoring gamit ang Extract Method at Pull Up Method ay nagpapahintulot na alisin ang duplikasyon at isentralisa ang lohika.

Pagbawas ng komplikasyon

Ang mga metriko ng cyclomatic complexity at lalim ng pagkakasunod-sunod ay direktang nauugnay sa bilang ng mga depekto sa code. Kung ang isang function ay may cyclomatic complexity na higit sa 10-15, mahirap itong i-test at madaling masira. Ang refactoring gamit ang Replace Conditional with Polymorphism, Decompose Conditional at Extract Method ay nagpapahintulot na bawasan ang komplikasyon sa isang kontroladong antas. Ang pananaliksik ng NIST (2024) ay nagpapakita na ang mga module na may mataas na komplikasyon ay naglalaman ng 2-3 beses na mas maraming depekto bawat libong linya ng code.

Paghahanda para sa mga pagbabago

Isa sa mga pangunahing dahilan ng refactoring — ang pangangailangan na magdagdag ng bagong functionality. Kung ang kasalukuyang istraktura ng code ay hindi pinapayagan ang paggawa ng pagbabago nang hindi sinisira ang umiiral na pag-uugali, ang refactoring ay tumutulong na ihanda ang lupa. Ang “panuntunan ng camping” (iwan ang code na mas malinis kaysa sa iyong natagpuan) — isa sa mga rekomendasyon ni Martin Fowler na nagpapabago sa refactoring mula sa episodikong aktibidad tungo sa patuloy na kasanayan.

Ang datos mula sa pagsusuri ng 500 open-source na proyekto sa GitHub (IEEE Transactions on Software Engineering, 2024) ay nagpapakita na ang mga proyektong may regular na refactoring ay may 30% na mas kaunting “amoy ng code” (code smells) at 15% na mas mababang indicator ng utang teknikal kumpara sa mga proyektong paminsan-minsan lamang nagsasagawa ng refactoring.

Mga pangunahing pamamaraan ng refactoring

Si Martin Fowler sa kanyang aklat ay nag-catalog ng mahigit 70 pamamaraan ng refactoring. Sa praktika, karamihan sa mga koponan ay regular na gumagamit ng 10-15 sa mga ito. Tingnan natin ang mga pangunahing pamamaraan na dapat malaman ng bawat developer.

Extract Method

Ang pinakamadalas na ginagamit na pamamaraan. Kung ang isang piraso ng code ay maaaring i-extract nang may kabuluhan sa isang hiwalay na function — dapat itong gawin. Ang Extract Method ay nagpapabuti sa pagiging nababasa, nagpapahintulot na bigyan ng pangalan ang operasyon at nagpapadali sa pag-test. Patakaran: kung makakita ka ng komentaryo na nagpapaliwanag kung ano ang ginagawa ng isang bloke ng code — ang bloke na iyon ay maaaring i-extract sa isang hiwalay na pamamaraan.

// Bago mag-refactor
double total = amount * price;
double discounted = total * (1 - discountRate);
double tax = discounted * taxRate;

// Pagkatapos mag-refactor
double total = calculateTotal(amount, price);
double finalPrice = applyDiscountAndTax(total);

Rename Variable / Rename Method

Ang pangalan ay dapat sumalamin sa esensya. Kung ang pangalan ng isang variable o pamamaraan ay hindi sumasagot sa tanong na “anong itinatago/ginagawa dito” — dapat itong palitan ng pangalan. Ginagawa ng modernong IDE ang operasyong ito na simple. Malilinis na pangalan — ang pinakamurang at pinakamabisang paraan upang mapabuti ang code.

Replace Conditional with Polymorphism

Kapag ang conditional logic ay lumaki nang sobra at naging magulo, ang polymorphism ay nag-aalok ng mas malinis na alternatibo. Sa halip na switch-case batay sa uri — lumikha ng hierarchy ng klase na may override na pamamaraan. Ang polymorphism ay ginagawang napapalawak ang code: ang pagdaragdag ng bagong uri ay hindi nangangailangan ng pagbabago ng umiiral na mga kondisyon, kundi ang paglikha lamang ng bagong subclass.

// Bago mag-refactor (conditional)
if (type.equals("email")) {
    sendEmail(message);
} else if (type.equals("sms")) {
    sendSms(message);
}

// Pagkatapos mag-refactor (polymorphism)
Notifier notifier = new EmailNotifier();
notifier.send(message);

Introduce Parameter Object

Kapag ang isang function ay tumatanggap ng masyadong maraming parameter (higit sa 3-4), mahirap silang basahin at ipasa. Ang pagpapangkat ng mga kaugnay na parameter sa isang parameter object ay nagpapaikli sa lagda, nagpapabuti sa pagiging nababasa at nagpapadali sa mga susunod na pagbabago.

Kailan dapat at hindi dapat mag-refactor

Ang desisyon na mag-refactor — hindi teknikal, kundi pampamamahala. Nangangailangan ito ng balanse sa pagitan ng kasalukuyang produktibidad at pangmatagalang kalusugan ng codebase. Tingnan natin ang mga tipikal na sitwasyon kung kailan ang refactoring ay makatwiran, at kung kailan mas mainam na umiwas.

Kailan dapat mag-refactor

Unang sitwasyon — hindi mo naiintindihan ang code na kailangan mong baguhin. Kung ang pag-unawa sa umiiral na code ay mas matagal kaysa sa pagpapatupad ng bagong functionality — iyon ay senyales na kailangan munang mag-refactor. Pangalawang sitwasyon — nakakita ka ng duplikasyon na nagpapabagal sa pag-develop at nagpapataas ng panganib ng mga pagkakamali. Pangatlo — ang pagdaragdag ng bagong functionality ay imposible nang hindi lumalabag sa umiiral na istraktura.

Dapat din mag-refactor kapag ang codebase ay naglalaman ng “amoy” (code smells): mahahabang pamamaraan, malalaking klase, labis na komentaryo, kadena ng tawag, parallel hierarchy ng pamana. Ang katalogo ng code smells mula sa aklat ni Fowler ay naglalaman ng mahigit 20 tipikal na indikador ng problema, bawat isa ay may kaukulang pamamaraan ng refactoring.

Kailan hindi dapat mag-refactor

Hindi kailangan ang refactoring kung ang code ay gumagana nang matatag at walang planong baguhin ito. Ang prinsipyong “gumagana — huwag galawin” (if it ain’t broke, don’t fix it) ay partikular na nauugnay para sa code na bihirang baguhin. Ang refactoring para sa refactoring — isa sa mga anyo ng engineering perfectionism na nagdudulot ng higit na pinsala kaysa pakinabang.

Huwag din mag-refactor ng code na ganap na mapapalitan sa malapit na hinaharap. Kung ang koponan ay nagpaplanong muling isulat ang module sa ibang wika o arkitektura, ang refactoring ng kasalukuyang bersyon ay pag-aaksaya ng oras. At sa wakas, ang refactoring nang walang test — pakikipagsapalaran, lalo na kung ang codebase ay malaki at komplikado. Ang pagbubukod — simpleng pagbabago gamit ang IDE na maaaring ibalik.

Paano mag-refactor nang walang panganib para sa proyekto

Ang ligtas na refactoring — ay disiplina. Mayroong ilang mga prinsipyo na ang pagsunod ay nagpapaliit ng mga panganib at ginagawang mahuhulaan ang proseso. Ang una at pinakamahalaga — refactoring lamang sa ilalim ng mga test. Kung wala kang mga test na sumasaklaw sa binabagong code — isulat muna ang mga ito.

Pangalawang prinsipyo — maliliit na hakbang. Bawat operasyon ng refactoring ay dapat minimal: pagpapalit ng pangalan ng isang variable, pag-extract ng isang pamamaraan, paghihiwalay ng isang klase. Pagkatapos ng bawat hakbang — i-compile at patakbuhin ang mga test. Ang paghahati sa micro-step ay nagpapahintulot na agad na matukoy ang pagkakamali at ibalik ang huling pagbabago. Ayon kay Martin Fowler, ang micro-step ay nagpapaligtas ng refactoring nang 3-4 beses kaysa sa malalaking pagbabago.

Pangatlong prinsipyo — paggamit ng mga kasangkapan. Ang modernong IDE (IntelliJ IDEA, VS Code, Eclipse) ay nagbibigay ng automated na refactoring: rename, extract method, extract variable, move class at dose-dosenang iba pa. Ang instrumentong refactoring ay ginagarantiyahan ang kawastuhan ng pagbabago at hindi nangangailangan ng manu-manong paghahanap ng lahat ng lugar kung saan kailangang baguhin ang code.

Pang-apat na prinsipyo — huwag paghaluin ang refactoring sa pagbabago ng functionality. Kung sabay kang nagre-refactor at nagdaragdag ng bagong lohika, imposibleng matukoy kung aling pagbabago ang nagdulot ng pagkakamali. Ang paghihiwalay ng commit sa “refactoring” at “feature” — pamantayan ng industriya na nagpapadali sa code review at pagbabalik ng mga pagbabago. Ang inirerekomendang istraktura: unang commit na may refactoring (structural na pagbabago lamang, napanatili ang pag-uugali), pagkatapos commit na may bagong functionality.

Git-flow para sa refactoring: lumikha ng hiwalay na branch, isagawa ang refactoring, makamit ang berdeng test, gumawa ng commit, pagkatapos sa parehong branch magdagdag ng bagong functionality. Kung may naging mali — ang mga pagbabago sa refactoring ay palaging maaaring ibalik sa pamamagitan ng git revert.

# Micro-step ng refactoring sa Git
git checkout -b refactor/extract-payment
# Hakbang 1: extract method ng kalkulasyon
# ...mga pagbabago... → compile → test
git commit -m "refactor: extract calculatePayment method"
# Hakbang 2: palitan ang pangalan ng variable
# ...mga pagbabago... → compile → test
git commit -m "refactor: rename amount to grossAmount"