Kostil sa programming: ano ito, anu-ano ang mga uri at kung paano ito gumagana

Ano ang kostil sa programming?

Kostil — ay slang na tawag para sa isang software solution na functional na tama, ngunit teknikal na hindi optimal. Ang ganitong code ay gumagana, pumasa sa mga test, at napupunta pa sa production, ngunit ang pagbabasa nito ay nagdudulot ng pagnanais na muling isulat ang lahat mula sa simula. Sa kapaligirang nagsasalita ng Ingles, ginagamit ang mga terminong workaround, kludge (kluge), hack, o quick-and-dirty fix.

Ang termino ay nagmula sa isang pang-araw-araw na metapora: kung nabali ang paa ng upuan, maaari itong itali ng tape — ang upuan ay tatayo muli, ngunit ang solusyon ay pansamantala at hindi maganda. Sa programming, ganito rin: ang bug ay inaayos gamit ang hardcode, isang timeout kostil, o pag-iwas sa pamamagitan ng hindi dokumentadong API. Nagko-compile ang code, hindi nag-crash ang aplikasyon, ngunit hindi matawag na kalidad ang solusyon.

Mahalagang pagkakaiba: bug — kapag hindi gumagana ang code, kostil — kapag gumagana ang code ngunit hindi maganda ang pagkakadisenyo. Ang kostil ay palaging may kamalayang pagpili ng developer: “Alam kong hindi ito maganda, ngunit sa ngayon nalulutas nito ang problema”.

Ayon sa pagtantiya ng Stripe (2024), ang mga developer ay gumugugol ng average na 17 oras bawat linggo sa pagtatrabaho sa teknikal na utang at mga kostil — halos kalahati ng oras ng trabaho. Ito ay direktang pagkawala ng produktibidad ng koponan.

Kailan at bakit lumilitaw ang mga kostil

Ang una at pangunahing dahilan — deadline. Kapag may isang araw na lang bago ang release at hindi pa naaayos ang kritikal na bug, pinipili ng koponan ang mabilis na solusyon sa halip na tama. Pag-hardcode ng halaga, pag-disable ng tseke, pagdagdag ng sleep() — mga klasikong halimbawa ng deadline kostil. Ang isang bihasang developer ay laging minamarkahan ang mga lugar na ito ng TODO o FIXME.

Pangalawang dahilan — hindi pagkakatugma ng API. Ang panlabas na library o framework ay kumikilos nang iba kaysa sa inilarawan sa dokumentasyon. Ang framework ay hindi nag-e-export ng kinakailangang klase, ang metodo ay minarkahan bilang deprecated, at walang alternatibo. Napipilitan ang developer na gumamit ng reflection, internal API, o paligiran. Sa Java, ito ay maaaring access sa pamamagitan ng setAccessible(true), sa Swift — @objc at performSelector.

Pangatlong dahilan — legacy-code. Namamana ng developer ang proyektong isinulat 5–10 taon na ang nakaraan sa lumang bersyon ng framework. Walang oras at budget para muling isulat ang buong modyul, kaya ang bagong functionality ay —dinidikit” sa lumang code sa pamamagitan ng mga kostil. Paunti-unti, napakaraming patong ang naipon na ang modyul ay nagiging „big ball of mud”.

Pang-apat na dahilan — kawalan ng mga test. Mapanganib ang refactoring nang walang test: ang pagbabago ng arkitektura ay maaaring makasira ng gumaganang functionality. Kapag walang test, mas gusto ng developer na magdagdag ng kostil sa ibabaw ng gumaganang code kaysa ipagsapalaran ang katatagan. Ayon sa Google Testing Blog (2024), ang mga koponan na walang test ay 3 beses na mas madalas gumagamit ng workaround solution.

Mga uri ng kostil

Ang klasipikasyon ng mga kostil ay tumutulong sa koponan na maunawaan kung anong uri ng teknikal na utang ang kanilang kinakaharap at pumili ng tamang estratehiya sa pag-alis. Tingnan natin ang mga pangunahing uri.

Hardcode — ang pinakakaraniwang uri. Sa halip na configuration, resource, o parameter, ginagamit ang isang nakapirming halaga sa code. Halimbawa: naka-hardcode na URL ng server, timeout na 5 segundo, laki ng font na 16pt. Ginagawang hindi scalable ng hardcode ang code at nangangailangan ng recompilation sa bawat pagbabago.

Copy-paste — pagdodoble ng fragment ng code na may maliit na pagbabago sa halip na i-extract ang karaniwang lohika. Klasikong sintomas: sa proyekto ay may 3 magkakatulad na metodo na nagkakaiba sa isang linya. Pinapabilis ng copy-paste ang pagsulat ng code sa oras ng gawain, ngunit pinapabagal ang pagpapanatili nito sa hinaharap ng 10 beses — ang pagwawasto ay kailangang gawin sa 3 lugar sa halip na isa.

Walang laman na try-catch — catch block na walang ginagawa o nagla-log lang ng error nang walang paghawak. Ang ganitong kostil ay “pinapatahimik” ang exception, ngunit hindi nito nilulutas ang sanhi nito. Ang aplikasyon ay patuloy na gumagana, ngunit ang data ay maaaring masira at ang user ay maaaring hindi makatanggap ng feedback.

Sleep sa code — Thread.sleep(500) o DispatchQueue.main.asyncAfter para maghintay kapag dapat ay may event o callback. Ang ganitong code ay hindi maaasahan: sa mabagal na device, ang 500 ms ay maaaring hindi sapat, sa mabilis na device, ang pause ay magiging sobra. Gamitin ang CountDownLatch, Semaphore, o async/await na may tamang timing.

Mga flag ng compatibility — mga if-else cascade na sumusuri sa bersyon ng OS, modelo ng device, o pagkakaroon ng feature. Kapag ang mga flag ay lumampas sa 3–4, ang code ay nagiging spaghetti. Solution — Strategy pattern o Feature Flags sa pamamagitan ng configuration.

Kostil kumpara sa teknikal na utang

Maraming developer ang napagkakamalan ang kostil sa teknikal na utang. Ang pagkakaiba ay nasa sukat at kamalayan. Kostil — ay lokal, kongkretong solusyon (isang metodo, isang klase). Teknikal na utang — ay isang sistemikong problema na nakakaapekto sa arkitektura ng modyul o buong aplikasyon.

Ang metapora ni Ward Cunningham (tagalikha ng terminong Technical Debt): ang teknikal na utang ay parang pagkuha ng loan sa bangko. Kumuha ka ng pera ngayon para mas mabilis na maitayo ang bahay, ngunit magbabayad ka ng interes mamaya. Ang kostil — ay parang pagpukpok ng pako gamit ang martilyo sa halip na distornilyador: ang trabaho ay nagagawa, ngunit hindi gaanong episyente.

Ang isang kostil ay hindi lumilikha ng teknikal na utang. Ngunit 50 kostil sa isang modyul = utang sa arkitektura. Kaya naman patakaran ng koponan: bawat kostil ay itinatala sa code review o task tracker, at regular na sinusuri ng koponan (isang beses bawat sprint) ang mga naipon na workaround solution.

Ayon sa karanasan ng Spotify Engineering (2023), ang mga koponan na nagtatala ng mga kostil sa code (sa pamamagitan ng espesyal na TODO label o custom annotation) ay nagbabawas ng oras ng refactoring ng 30% — dahil hindi sila nag-aaksaya ng maraming oras sa paghahanap ng mga problematikong lugar.

Paano maalis ang mga kostil

Unang hakbang — inventory. Hanapin sa codebase ang mga keyword: TODO, FIXME, HACK, WORKAROUND, KLUDGE. Hinahighlight sila ng mga modernong IDE sa magkahiwalay na kulay. Ipinapakita rin ng GitHub ang TODO sa interface ng Pull Request. Gumawa ng listahan ng lahat ng kostil na may priyoridad.

Ikalawang hakbang — pag-prioritize. Hindi lahat ng kostil ay kailangan ayusin kaagad. Priyoridad = dalas ng pagbabago sa file × kritikalidad. Kung ang file ay nagbabago ng 2 beses sa isang taon, ang kostil ay maaaring maghintay. Kung ang modyul ay binabago sa bawat sprint — ang kostil ay dapat ayusin muna.

Ikatlong hakbang — refactoring na may mga test. Huwag kailanman i-refactor ang kostil nang walang test. Sumulat muna ng test na sumusuri sa kasalukuyang pag-uugali (na may kostil), pagkatapos ay mag-refactor, pagkatapos ay tiyaking pumasa ang test. Kung wala ito, ang refactoring ng kostil ay maaaring makasira ng functionality kung saan ito isinulat.

// Bago: hardcode na URL workaround
fun getApiUrl(): String {
    return "https://api.example.com/v2"
}

// Pagkatapos: configuration sa pamamagitan ng BuildConfig
fun getApiUrl(): String {
    return BuildConfig.API_BASE_URL
}

Ikaapat na hakbang — awtomatisasyon. I-configure ang linter na nagbabawal sa ilang partikular na pattern ng kostil. Halimbawa, ang Detekt para sa Kotlin ay maaaring suriin ang kawalan ng Thread.sleep() sa production code, ang ESLint — ay magbawal ng console.log sa proyekto. Ito ay pumipigil sa paglitaw ng mga bagong kostil ng parehong uri.

Kailan makatwiran ang kostil

Sa kabila ng negatibong konotasyon ng termino, ang kostil ay maaaring maging makatwirang solusyon. Pangunahing kondisyon: ang kostil ay pansamantala, malinaw na minarkahan, at may plano ng pagpapalit. Sa production code ng bawat malaking proyekto ay may daan-daang makatwirang kostil.

Sitwasyon 1: hotfix sa production. Ang kritikal na bug ay bumabagsak sa lahat ng user. Ang koponan ay nangangailangan ng pag-aayos sa loob ng isang oras. Tamang diskarte: ayusin ang bug sa anumang paraan, i-deploy ang hotfix. Kinabukasan, isulat ang tamang solusyon at isara ang gawain. Ang hotfix ay isang makatwirang kostil kung ito ay nabubuhay nang hindi hihigit sa 48 oras.

Sitwasyon 2: paghihintay sa bagong bersyon ng library. Ang framework ay naglalaman ng bug na naayos sa master, ngunit ang release ay lalabas sa loob ng 2 linggo. Sa halip na sumulat ng kumplikadong paligirang code, ang koponan ay nagdadagdag ng workaround na may tala na “REMOVE after library 3.2”. Kapag lumabas ang 3.2, ang workaround ay tinatanggal.

Sitwasyon 3: paglulunsad ng startup o MVP. Sa yugto ng MVP, mas mahalaga ang bilis kaysa arkitektura. Normal ang mga kostil sa simula. Lumilitaw ang problema kapag ang startup ay hindi nagiging produkto at nananatili ang mga kostil. Rekomendasyon: pagkatapos ng funding round, maglaan ng sprint para bayaran ang kritikal na teknikal na utang.

Pangunahing prinsipyo: “Ang legacy ay code ng ibang tao na walang test” (Michael Feathers). Kung ang kostil ay sakop ng test at malinaw na dokumentado — ito ay mapapamahalaan. Kung ito ay nakabitin nang walang komento sa loob ng 2 taon sa isang nalimutang modyul — hindi na ito kostil, kundi problemang arkitektural.