Ang gównokod sa programming: ano ito, mga palatandaan at paano sumulat ng mas malinis

Ano ang gównokod sa programming

Gównokod — ay isang subjective ngunit malawak na tinatanggap na katangian ng code na hindi nakakatugon sa mga minimum na pamantayan ng kalidad. Robert Martin sa kanyang aklat na „Clean Code” (2008) ay tinutukoy ang masamang code bilang code na „pumipigil sa pag-unawa sa ginagawa nito”. Ang gównokod ay maaaring syntactically tama at kahit na gumagana, ngunit ang pagpapanatili nito ay nagiging isang bangungot para sa team.

Ang terminong gównokod ay laganap sa komunidad na nagsasalita ng Ruso. Sa Ingles, ginagamit ang mas pormal na mga termino: spaghetti code, dirty code, technical debt code. Gayunpaman, ang emosyonal na kulay ng „gównokod” ay mas tumpak na naghahatid ng saloobin ng mga developer sa naturang code — isang halo ng pagkairita, pagkasuklam, at propesyonal na pagkagalit.

Ayon sa pananaliksik ng McKinsey (2023), ang mga kumpanyang may mataas na antas ng technical debt — at ang gównokod ang pangunahing bahagi nito — ay gumagastos ng 20–40% na mas maraming resources sa pag-develop ng mga bagong feature. Ang kalidad ng code ay direktang nakakaapekto sa mga business indicator at ito ay hindi isang metapora, kundi isang kumpirmadong katotohanan.

Ang hangganan sa pagitan ng gównokod at normal na code

Walang mga objective metrics, ngunit may mga praktikal na criteria: kung ang isang developer ay gumugugol ng higit sa 5 minuto upang maunawaan ang isang function na 20 linya — ito ay gównokod. Kung ang pagbabago ng isang linya ay sumisira ng tatlong hindi magkakaugnay na module — ito ay gównokod. Kung ang code ay hindi maaaring saklawin ng mga pagsusulit nang walang kumpletong muling pagsulat — ito ay gównokod.

Mga pangunahing palatandaan ng gównokod

Copy-paste (copy-paste programming) — isa sa mga pinaka-kapansin-pansin at madaling matukoy na palatandaan. Kapag ang parehong bloke ng code ay inuulit sa maraming lugar na may kaunting pagbabago, ito ay hindi lamang gównokod, kundi pati na rin isang pinagmumulan ng mga susunod na bug. Pag-aayos sa isang lugar at paglaktaw sa iba — isang tipikal na sitwasyon.

Walang kabuluhang pangalan ng variable — klasiko. Ang mga variable na may mga pangalan tulad ng `a`, `b`, `x`, `data`, `temp`, `tmp`, `result`, `list`, `obj` ay walang anumang impormasyon tungkol sa kanilang layunin. Ang nagbabasa ng code ay kailangang suriin ang buong function upang maunawaan kung ano ang nakaimbak sa variable. Tinatawag ito ni Robert Martin na „kasinungalingan sa pangalan” — ang pangalan ay nangangako ng impormasyon, ngunit hindi ito ibinibigay.

Malalim na nesting — kapag ang mga kondisyon, loops, at paghawak ng error ay lumilikha ng isang konstruksyon na may 5+ antas ng indentation. Ang ganitong code ay hindi mababasa nang walang side scrolling o mental na pagsubaybay sa lahat ng antas. Ito ay isang direktang daan patungo sa mga pagkakamali: ang mga logical operator ay madaling malito, at ang mga pansarang bracket ay maaaring hindi mapansin.

Mga nakatagong palatandaan

Dead code — mga function, variable, klase na hindi ginagamit kahit saan. Pinapataas nito ang volume ng code, nakakaabala sa developer, at lumilikha ng maling impresyon tungkol sa mga kakayahan ng system. Magic numbers — mga numero nang walang konteksto. God-classes — mga klase na ginagawa ang lahat nang sabay-sabay, lumalabag sa prinsipyo ng solong responsibilidad (SOLID: S).

Bakit lumilitaw ang gównokod

Kakulangan ng oras — ang pinakakaraniwang dahilan. Kapag papalapit ang mga deadline, isinasakripisyo ng mga developer ang kalidad para sa bilis. Tactically ito ay maaaring makatwiran, ngunit strategically — ito ay pag-iipon ng technical debt. Ang problema ay ang „pansamantalang” gównokod ay bihirang balikan upang ayusin.

Kawalan ng code review — ang pangalawang pinakamahalagang dahilan. Kapag ang code ay isinulat nang mag-isa nang walang pagsusuri ng mga kasamahan, ang mga masasamang pattern ay nagpapatatag at dumadami. Ang code review ay hindi lamang kontrol sa kalidad, kundi pati na rin paglilipat ng kaalaman sa loob ng team. Ang mga proyektong walang review ay hindi maiiwasang mahulog sa gównokod.

Mababang kwalipikasyon ng developer o kawalan ng mentoring. Ang mga junior developer na naiwan nang walang pangangasiwa ay natural na sumusulat ng gównokod — ito ay bahagi ng proseso ng pag-aaral. Ang problema ay lumilitaw kapag ang code na ito ay napupunta sa produksyon nang walang review at refactoring.

Mga kultural na kadahilanan

Sa mga team kung saan ang motto ay „gumagana — at ayos na”, ang gównokod ay yumayabong. Ang kawalan ng mga coding standards, mga kinakailangan sa pagsubok, at mga proseso ng review ay lumilikha ng kapaligiran kung saan walang nagmamalasakit sa kalidad ng code. Ang mga ganitong proyekto ay mabilis na nagiging „legacy” — code na kinatatakutang galawin.

Mga kahihinatnan ng masamang code para sa proyekto

Ang pangunahing kahihinatnan ng gównokod ay ang pagbagal ng pag-develop. Ang kabalintunaan ng masamang code ay pinapayagan nito ang mabilis na pagsulat ng unang bersyon, ngunit ang bawat kasunod na pagbabago ay nangangailangan ng mas maraming oras. Ang graph ng dependence ng bilis ng pag-develop sa kalidad ng code ay exponential — pagkatapos ng isang tiyak na threshold, ang pagdaragdag ng mga bagong feature ay nagiging praktikal na imposible.

Pag-alis ng empleyado — isang hindi direkta ngunit malubhang kahihinatnan. Ang mga developer, lalo na ang mga may karanasan, ay ayaw magtrabaho sa gównokod. Ayon sa Stack Overflow Developer Survey 2024, 47% ng mga developer ay tinatawag ang kalidad ng codebase bilang isa sa mga pangunahing kadahilanan sa pagpili ng lugar ng trabaho. Ang mga proyektong may masamang code ay nawawalan ng kanilang pinakamahuhusay na empleyado.

Seguridad — isa pang biktima ng gównokod. Ang hindi magandang pagkakasulat na code ay naglalaman ng mas maraming kahinaan: hindi nahahawakang exceptions, SQL-injection, XSS, pagtagas ng memorya. Ang de-kalidad na code na may unit test at code review ay nakakahuli ng karamihan sa mga problemang ito bago ang produksyon.

Technical debt bilang metrik

SonarQube at mga katulad na kasangkapan ay maaaring masuri ang technical debt sa oras ng tao o araw. Halimbawa, 500 babala tungkol sa copy-paste, 200 tungkol sa magic numbers, at 50 tungkol sa malalim na nesting ay nagbibigay ng tantiya na 30 araw ng technical debt. Ang mga numerong ito ay maaari at dapat ipakita sa pamamahala upang bigyang-katwiran ang refactoring.

Paano sumulat ng malinis na code sa halip na gównokod

Ang prinsipyong DRY (Don't Repeat Yourself) — ang unang dapat ipatupad. Bawat piraso ng lohika ay dapat umiral sa isang kopya. Sa halip na copy-paste — ilipat ang paulit-ulit na code sa isang hiwalay na function, klase, o module. Sa halip na magic numbers — mga pinangalanang constant. Sa halip na mahabang function — ilang maliliit na function.

Ang prinsipyong KISS (Keep It Simple, Stupid) ay nagpoprotekta laban sa labis na pagiging kumplikado. Kung ang isang gawain ay malulutas sa 10 linya — huwag sumulat ng 50. Kung ang loop ay mas simple kaysa sa stream — gamitin ang loop. Kung ang ordinaryong function ay mas naiintindihan kaysa sa dekorador — sumulat ng function. Ang pagiging simple ay ang pangunahing kalidad ng madaling mapanatili na code.

Ang prinsipyong Boy Scout Rule — „iwan ang code na mas mahusay kaysa sa iyong natagpuan”. Kahit ang maliliit na pagpapabuti sa bawat pagbabago sa paglipas ng panahon ay nagpapabago ng gównokod sa disenteng code. Pagpapalit ng pangalan ng variable, paghahati ng malaking function, pagdaragdag ng pagsusulit — bawat pagpapabuti ay mahalaga.

// masamang code — copy-paste, magic numbers, masamang pangalan
function calc(a, b, c) {
  let x = a * 0.85;
  if (b > 1000) { x = x * 0.9; }
  let y = c * 0.85;
  if (b > 1000) { y = y * 0.9; }
  return x + y;
}

// malinis na code — malinaw na pangalan, DRY, constants
const DISCOUNT_RATE = 0.85;
const BULK_THRESHOLD = 1000;
const BULK_DISCOUNT = 0.9;

function applyDiscount(amount, quantity) {
  let price = amount * DISCOUNT_RATE;
  if (quantity > BULK_THRESHOLD) {
    price = price * BULK_DISCOUNT;
  }
  return price;
}

function calculateTotal(items, quantity) {
  return items.reduce((sum, item) => {
    return sum + applyDiscount(item, quantity);
  }, 0);
}

Mga halimbawa ng refactoring ng gównokod

Tingnan natin ang isang tipikal na halimbawa sa Python. Pinoproseso ng function ang mga order, ngunit ginagawa ito nang hindi maganda: 80 linya, malalim na nesting, magic numbers, pagdodoble. Pagkatapos ng refactoring, ang code ay nagiging nababasa, masusubok, at madaling mapanatili.

# masamang code — isang function gumagawa lahat
def process_order(order):
    if order.get("type") == "premium":
        if order["amount"] > 100:
            discount = 0.8
        else:
            discount = 0.9
    else:
        discount = 1.0
    total = order["amount"] * discount
    return total

# malinis na code — hiwalay na function at constants
class OrderProcessor:
    PREMIUM_DISCOUNT_HIGH = 0.8
    PREMIUM_DISCOUNT_LOW = 0.9
    PREMIUM_THRESHOLD = 100

    def get_discount(self, order):
        if order.type == "premium" and order.amount > self.PREMIUM_THRESHOLD:
            return self.PREMIUM_DISCOUNT_HIGH
        return self.PREMIUM_DISCOUNT_LOW

    def calculate_total(self, order):
        return order.amount * self.get_discount(order)

Ang tatlong-linya na panuntunan para sa mga function

Ang mabuting function ay gumagawa ng isang bagay at ginagawa ito nang maayos. Kung ang isang function ay gumagawa ng tatlong magkakaibang aksyon — hatiin ito. Kung ang isang function ay naglalaman ng higit sa 20 linya — malamang na maaari itong hatiin. Kung sa isang function ay may higit sa dalawang antas ng indentation — kailangan ang refactoring.

Mga kasangkapan para sa pag-detect ng gównokod

Static code analyzer — unang linya ng depensa laban sa gównokod. ESLint (JavaScript), Pylint (Python), SonarQube (multilingual), Checkstyle (Java) ay awtomatikong nakakatuklas ng copy-paste, magic numbers, walang laman na catch block, masyadong mahabang function, at daan-daang iba pang anti-pattern.

Code style at mga formatte — ikalawang antas ng proteksyon. Prettier, Black, gofmt ay awtomatikong nagfo-format ng code, tinatanggal ang mga problema sa puwang, indentation, at bracket. Isang pare-parehong estilo sa team ay ginagawang nababasa ang code kahit sino pa ang sumulat nito. Ang mga pagtatalo tungkol sa pag-format ay dapat awtomatiko.

Code review — ikatlo at pinakamahalagang antas. Walang analyzer ang makakapalit sa isang tao na nakakakita na mali ang arkitektura ng solusyon o na ang developer ay pumili ng maling approach. Ang mabisang review ay nangangailangan ng oras, ngunit nagbabayad ito sa pamamagitan ng pagbawas ng dami ng gównokod nang maraming beses.

• ESLint — para sa JavaScript at TypeScript na may mga patakarang complexity, max-lines, max-nested-callbacks
• Pylint — para sa Python na may code metrics at quality rating (mula -10 hanggang 10)
• SonarQube — para sa pagsubaybay ng technical debt sa dinamika
• CodeClimate — para sa pagtatasa ng maintainability index ng bawat file
• Better Code Hub — para sa pagsusuri ng pagsunod sa 10 prinsipyo ng malinis na code