Mga krut sa programming — ano ito, mga dahilan at kailan makatwiran

Ano ang “krut” sa programming

Krut (crutch) — isang software solution na gumagana, ngunit ginawa “dali-dali”: nagsasara ng partikular na problema, ngunit hindi inaalis ang sanhi nito, hindi sumusunod sa arkitektura ng proyekto at maaaring masira sa pinakamaliit na pagbabago sa kapaligiran. Tumpak ang metapora — tulad ng tunay na krut, ang ganitong code ay tumutulong sa “pagtakbo” ngunit hindi gumagaling ng “paa”.

Ang mga developer ay “sumasalo ng krut” sa mga bug, hindi pagkakatugma ng bersyon, mga feature ng platform at agarang kahilingan ng kliyente. Isang tipikal na krut — krut-kondisyon: kung iOS 15 magdagdag ng espasyo, kung Huawei — itago ang button. Ang ganitong mga pagsusuri ay dumadami at ginagawang “layered cake” ang code ng mga platform at version branching.

Ang mga krut ay maaaring iba't ibang laki: mula sa isang linya na may krut-kondisyon hanggang sa isang buong module-mediator na “nag-aayos” ng behavior ng library. Mahalagang maunawaan na ang krut ay hindi palaging masama: sa tamang kamay, ito ay isang kasangkapan na nagbibigay-daan upang ilabas ang produkto sa tamang oras. Nagsisimula ang problema kapag ang krut ay nananatili sa code magpakailanman.

Bakit lumilitaw ang mga krut: mga dahilan at konteksto

Pangunahing dahilan ng paglitaw ng mga krut ay ang salungatan sa pagitan ng perpektong solusyon at aktwal na limitasyon ng proyekto. Alam ng developer kung paano gagawin nang tama, ngunit ang oras, pera o teknikal na limitasyon ay hindi pinapayagan ito. Bilang resulta, lumilitaw ang isang kompromiso na solusyon na “gumagana lang”.

Tingnan natin ang apat na pangunahing dahilan kung bakit ang mga developer ay may kamalayang gumagamit ng krut. Ang pag-unawa sa mga dahilang ito ay tumutulong na tingnan ang mga krut hindi bilang pagkakamali, kundi bilang pragmatikong kasangkapan na nangangailangan ng pamamahala.

Deadline

Pinakakaraniwang dahilan. Ang release ay bukas, ang bug ay nagre-reproduce lamang sa isang partikular na modelo, ang arkitektural na pag-aayos ay tumatagal ng dalawang linggo. Ang krut-kondisyon ay tumatagal ng isang oras at nagsasara ng problema. Pagkatapos ng release, nangangako ang team na babalik at muling susulat nang tama. “Walang mas permanente kaysa sa pansamantalang solusyon” — eksaktong tungkol sa mga ganitong krut.

Hindi pagkakatugma ng bersyon

Ang Library A ay nangangailangan ng Android 12, ngunit ang iyong app ay sumusuporta sa Android 10. Ang solusyon — sumulat ng gitnang layer na sumusuri sa bersyon ng OS at pumipili ng execution path. Ito ay isang krut, dahil kapag in-update ang library, ang gitnang layer ay kailangang muling isulat. Ngunit ang alternatibo — pagtigil sa library o suporta sa lumang device — ay maaaring mas masama.

// Krut para sa compatibility ng API 29
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

Panlabas na dependencies na may bug

Ang library na inaasahan ng proyekto ay naglalaman ng bug, ngunit ang pag-update nito ay maaaring tumagal ng mga linggo (kailangan ng PR, code review, publication). Sa halip na maghintay, ang team ay sumulat ng wrapper na nag-patch ng behavior ng library on the fly. Pagkatapos lumabas ng naayos na bersyon ng library, ang wrapper ay tinatanggal. Kung hindi tinanggal — ito ay problema na sa arkitektura.

Hindi kumpletong pag-unawa sa system

Isang bagong developer sa legacy project ay hindi nauunawaan kung bakit gumagana ang code nang ganoon. Sa halip na alamin, nagdadagdag siya ng bagong kondisyon sa ibabaw ng umiiral na. Ito ang pinakamapanganib na uri ng krut, dahil hindi alam ng may-akda na ito ay isang krut. Ang tanging lunas — code review at pair programming para sa mga bagong miyembro ng team.

Kailan makatwiran ang krut: pragmatikong approach

Hindi lahat ng krut ay masama. Sa tunay na development, absolute code purity ay hindi maaabot at madalas hindi nararapat. Ang pragmatikong approach ay kumikilala na ang pansamantalang solusyon ay bahagi ng proseso, ngunit nangangailangan ng kamalayan, dokumentasyon at pagpaplano ng pagtanggal. Ang krut ay makatwiran kapag niresolba nito ang business task nang mas mabilis kaysa sa malinis na arkitektural na solusyon.

Mga pamantayan ng makatwirang krut: nagsasara ng partikular na problema, may may-ari (sino ang responsable sa pagtanggal nito) at may plano ng refactoring. Kung kahit isa sa tatlong kondisyon ay hindi natutugunan — ang krut ay nagiging technical debt. Mga kasangkapan tulad ng TODO-comments na may ticket sa tracker — pinakamababang paraan ng dokumentasyon.

Halimbawa ng makatwirang krut

Isang kritikal na bug sa release branch na kailangang isara bago ang deployment bukas. Ang malinis na solusyon ay nangangailangan ng refactoring ng arkitektura at tatagal ng dalawang linggo. Krut — magdagdag ng nil check at ipadala ang fix bilang hotfix. Mga kondisyon ng pagiging makatwiran: sa tracker ay gumawa ng ticket para sa refactoring, itinalaga ang responsableng tao, ang krut ay minarkahan ng komento. Pagkalipas ng dalawang linggo, babalik ang team sa gawain.

// TODO: IT-1234 — alisin ang krut na ito pagkatapos ng refactoring ng AuthService
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

Paano makilala ang pansamantalang krut mula sa problema sa arkitektura

Ang hangganan sa pagitan ng may malay na krut at problema sa arkitektura (technical debt) ay dumadaan sa dalawang parameter: kamalayan ng desisyon at pagkakaroon ng plano ng pagtanggal. Ang krut ay palaging pansamantalang solusyon na may alam na lifespan. Ang technical debt — resulta ng maraming krut na iniwan nang walang pansin.

Kailan nagiging problema ang krut

Lumalala ang sitwasyon kapag ang bilang ng mga krut ay lumampas sa kritikal na masa. Bawat bagong krut ay nagpapataas ng “kahinaan” ng system: ang pagbabago sa isang lugar ay sumisira sa iba. Bilang resulta, bumagal ang development, dumarami ang bug, at hindi maintindihan ng bagong developer ang code nang walang tulong ng may-akda. Sa puntong ito, ang mga krut ay tumitigil sa pagiging pansamantalang solusyon at nagiging problema sa arkitektura.

Mga senyales ng krisis ng krut

Kung sa code ay may limang nested na pagsusuri para sa bersyon ng OS, gumagawa ng device at pagkakaroon ng partikular na library — ito ay hindi krut, ito ay problema sa arkitektura. Kung ang pagdaragdag ng isang fix ay nagdudulot ng tatlong regression sa katabing module — ang mga krut ay tumigil na sa pagiging lokal. Kung ang code review ay regular na tinatanggihan dahil sa “isa pang krut” — oras na upang magplano ng refactoring.

• Ang parehong krut ay umuulit sa tatlo o higit pang lugar — oras para sa isang solusyon
• Ang krut ay nabubuhay nang higit sa tatlong sprint nang walang plano ng pagtanggal — ito ay technical debt na
• Hindi maintindihan ng bagong developer kung bakit gumagana ang code nang ganoon — hindi dokumentado ang krut
• Ang pagtanggal ng krut ay nagdudulot ng chain reaction ng error — ang dependency sa krut ay naging arkitektural

Refactoring ng mga krut: estratehiya at praktika

Refactoring ng mga krut — proseso ng pagpapalit ng pansamantalang solusyon ng tama sa arkitektura. Ito ay nangangailangan ng oras, kaya kailangan ng estratehiya ng priyoridad: hindi lahat ng krut ay kailangang agad na alisin. Isang magandang estratehiya — suriin ang bawat krut batay sa dalawang parameter: dalas ng pagbabago sa lugar na iyon ng code at epekto sa mga user.

Estratehiya ng priyoridad

Mataas na priyoridad — mga krut sa madalas binabagong module (business logic, general purpose UI) na nagpapabagal ng development at nagdudulot ng regression. Katamtamang priyoridad — mga krut sa bihirang binabagong module, ngunit may potensyal na epekto sa mga user (pagpoproseso ng pagbabayad, awtorisasyon). Mababang priyoridad — mga krut sa legacy code na stable na gumagana at hindi planadong baguhin.

Proseso ng pagtanggal hakbang-hakbang

Hakbang 1: imbentaryo — hanapin lahat ng TODO at FIXME na may kaugnayan sa krut. Hakbang 2: pagsusuri — alamin kung alin ang may kaugnayan pa. Hakbang 3: pagpaplano — italaga ang refactoring ng krut sa isang sprint, simula sa mataas na priyoridad. Hakbang 4: pagpapalit — ipatupad ang malinis na solusyon, alisin ang krut at ang TODO-comment nito. Hakbang 5: beripikasyon — tiyaking pumasa ang mga test at walang regression.

# Hanapin lahat ng TODO-krut sa proyekto
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

Pag-iwas sa bagong krut

Ang pinakamahusay na paraan upang labanan ang mga krut ay huwag gumawa ng mga ito nang hindi kailangan. Bago sumulat ng krut, tanungin ang iyong sarili ng tatlong tanong: maaari bang gumawa ng malinis na solusyon sa makatwirang oras? Mayroon bang alternatibo na hindi krut? Magkakaroon ba ng oras ang team upang bumalik at muling isulat ito? Kung kahit isang tanong ay nasagot ng “hindi” — mag-isip muli bago “sumalo” ng code.