“Gumagana — huwag galawin” — ano ito, diwa ng prinsipyo at mga panganib

Ano ang prinsipyong “gumagana — huwag galawin”?

Prinsipyong “Gumagana — huwag galawin” (Ingles: “If it ain't broke, don't fix it”) — ito ay isang empirikal na patakaran na nagbababala sa mga programmer laban sa paggawa ng mga pagbabago sa gumaganang code nang walang sapat na dahilan. Sa base ng prinsipyo ay namamalagi ang simpleng estadistika: ang malaking mayorya ng mga depekto ay naipapasok mismo sa proseso ng pagbabago ng umiiral na code.

Ang prinsipyo ay hindi dogma — ito ay isang heuristiko na tumutulong sa paggawa ng desisyon sa mga kondisyon ng kawalan ng katiyakan. Kung mas komplikado at magulo ang codebase, mas mataas ang posibilidad na ang isang “walang-sala” na pagbabago ay makakasira ng isang bagay na walang inaasahang masisira.

Ayon sa pananaliksik ng Microsoft Corporation (2024), humigit-kumulang 60% ng lahat ng kritikal na insidente sa produksyon ay nauugnay sa mga kamakailang pagbabago sa code na ginawa nang may mabuting intensyon ngunit hindi sapat na nasubok sa ilalim ng tunay na karga.

Kasaysayan at pinagmulan ng prinsipyo

Idyoma “If it ain't broke, don't fix it” ay nagmula sa kulturang pang-engineer ng Amerika noong kalagitnaan ng ika-20 siglo. Ang pinakamaagang dokumentadong paggamit ay iniuugnay kay Bert Lance (1977), na nagtrabaho sa Senate Finance Committee ng US at sumalungat sa labis na regulasyon.

Sa programming, ang prinsipyo ay nagmula sa hardware engineering, kung saan ang pagpapalit ng gumaganang chip ng bago ay maaaring magdulot ng hindi inaasahang kahihinatnan. Sa konteksto ng software, ang prinsipyong ito ay naging partikular na laganap sa pagtaas ng komplikasyon ng mga software system at paglitaw ng legacy code.

Kapansin-pansin, sa programming ang prinsipyo ay mayroong ibang panig — “gumagana, pero mas mabuting huwag galawin” ay madalas nagiging dahilan para tumanggi sa refactoring, na sa pangmatagalan ay humahantong sa kritikal na pag-iipon ng technical debt. Ayon sa konsulting kompanyang Thoughtworks (2023), humigit-kumulang 40% ng mga proyekto ay nakakaranas ng malubhang problema dahil sa labis na konserbatismo sa pagbabago.

Kailan gagamitin ang prinsipyo

Prinsipyong “Gumagana — huwag galawin” ay partikular na nauugnay sa ilang sitwasyon kung saan ang halaga ng pagkakamali ay lumalampas sa potensyal na benepisyo ng pagbabago.

Legacy projects na walang test

Sa legacy code na hindi nasasakop ng mga test, anumang pagbabago ay isang larong Russian roulette. Kung hindi masuri ng programmer na hindi sinira ng pagbabago ang mga katabing modyul, ang pinakamahusay na estratehiya ay huwag galawin ang gumaganang code. Eksepsyon — tanging kritikal na bug o pangangailangan sa seguridad.

Kritikal na sistema

Sa mga sistema kung saan ang downtime ay hindi katanggap-tanggap o ang halaga ng pagkakamali ay napakalaki — medikal na software, avionics, pinansyal na transaksyon — ang prinsipyong “gumagana — huwag galawin” ay de facto standard. Anumang pagbabago ay dumadaan sa maraming yugto ng pag-apruba at pagsubok.

Mahigpit na deadlines

Kung ang release ay bukas at gumagana ang code — huwag subukang pagbutihin ang arkitektura nito. Baguhin lamang kung ano ang direktang nakakaapekto sa functionality ng release. Ipagpaliban ang refactoring sa susunod na sprint (ngunit huwag kalimutan ito).

Mga panganib ng pagsunod sa prinsipyo

Ang bulag na pagsunod sa prinsipyong “gumagana — huwag galawin” ay may dala ring mga panganib na hindi bababa sa walang katapusang refactoring. Tingnan natin ang mga pangunahing panganib.

Pag-iipon ng technical debt

Kung ang bawat programmer ay ginagabayan ng prinsipyong ito, ang codebase ay mabilis na magiging isang “layer cake” ng mga lumang solusyon, saklay at hindi optimal na algorithm. Maaga o huli ang technical debt ay nagiging hindi mabata — anumang pagbabago ay nangangailangan ng mga linggo ng pagsusuri.

Nawawalang optimisasyon

Minsan ang pagbabagong tila mapanganib ay talagang makabuluhang nagpapabuti sa pagganap o seguridad. Ang prinsipyong “gumagana — huwag galawin” ay hindi dapat humarang sa mga pagbabagong nagdudulot ng nasusukat na benepisyo — pagbabawas ng gastos sa server, pagpapabilis ng pag-load ng pahina, pagtaas ng seguridad.

Pagkawala ng kakayahan

Kapag ang team ay hindi nagalaw ang ilang bahagi ng code sa loob ng maraming taon, nawawalan ito ng pag-unawa kung paano gumagana ang mga ito. Umalis ang pangunahing programmer — at ang code ay nagiging legacy na walang posibilidad ng maintenance. Ang prinsipyo ay dapat gamitin nang isinasaalang-alang ang pangmatagalang maintenance ng proyekto.

Gitnang daan: refactoring nang walang panatismo

Ang optimal na estratehiya — huwag sundin nang bulag ang prinsipyo, kundi gamitin ito nang may kamalayan, isinasaalang-alang ang konteksto. Kailangan ang refactoring, ngunit dapat itong maging ligtas.

Patakaran ng scout

Patakaran ng scout sa programming: “Iwan ang code na mas malinis kaysa sa pagkakita mo rito”. Kung ang programmer ay gumagawa ng pagbabago sa isang modyul, dapat niyang pagbutihin ang istraktura nito, ngunit sa makatwirang hangganan. Hindi isulat muli ang lahat mula sa simula, ngunit kahit man lang palitan ang pangalan ng hindi mabasang mga variable at magdagdag ng komento.

Refactoring sa ilalim ng proteksyon ng test

Test — ang tanging paraan upang ligtas na gamitin ang prinsipyong “gumagana — huwag galawin”. Kung ang code ay sakop ng test, anumang refactoring ay nagiging predictable: binabago ng programmer ang code, pinapatakbo ang mga test at nakikita kung may nasira. Walang test — huwag galawin. May test — mag-refactor nang may kumpiyansa.

// Halimbawa: ligtas na refactoring sa ilalim ng test coverage
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Luma ngunit gumaganang code
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Test na nagpoprotekta laban sa regression
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Ang halimbawang ito ay nagpapakita ng tamang paglapit: una ang test, pagkatapos ang refactoring. Kung pumasa ang test — ligtas ang pagbabago. Ang prinsipyong “gumagana — huwag galawin” ay nagiging “gumagana sa ilalim ng test — mag-refactor nang buong tapang”.

Tunay na mga halimbawa mula sa praktika

Tingnan natin ang mga tunay na sitwasyon kung saan ang prinsipyong “gumagana — huwag galawin” ay napatunayang parehong nakapagligtas at nakasira.

Nakapagligtas na kaso: problemang parang Y2K

Isang programmer natuklasan na sa code ng pagproseso ng petsa ay ginagamit ang format na DD/MM/YY sa halip na YYYY. Gumana nang tama ang code mula 2000 hanggang 2025. Sa kabila ng pagnanais na “ayusin” — iniwan niya ang code kung ano ito, nilimitahan ang sarili sa isang komento. Noong 2026, in-update ng kumpanya ang sistema, at ang bagong solusyon ay tama nang nagproseso ng mga siglo. Ang maagang pagbabago ay makakasira lamang sa gumaganang lohika.

Nakasirang kaso: pagkawala ng datos dahil sa “pagpapabuti”

Isang engineer nagpasya na “pagbutihin” ang luma ngunit gumaganang code ng pag-import ng datos sa pamamagitan ng pagpapalit nito ng modernong library. Hindi niya isinaalang-alang na ang lumang library ay humahawak ng isang specific na edge case na hindi dokumentado. Pagkatapos ng release — malawakang pagkawala ng datos. Ang prinsipyong “gumagana — huwag galawin” ay nilabag, at ang halaga ng pagkakamali ay dalawang linggo ng trabaho ng team para sa pagbawi.