Dasturlashda kostil: bu nima, qanday turlari bor va qanday ishlaydi

Dasturlashda kostil nima?

Kostil — bu funksional jihatdan to‘g‘ri, lekin texnik jihatdan optimal bo‘lmagan dasturiy yechimning jargon nomi. Bunday kod ishlaydi, testlardan o‘tadi va hatto produksiyaga chiqadi, lekin uni o‘qish hamma narsani boshidan yozish istagini uyg‘otadi. Ingliz tilidagi muhitda workaround, kludge (kluge), hack yoki quick-and-dirty fix terminlari qo‘llaniladi.

Termin kundalik metaforadan keladi: stulning oyog‘i sinib qolsa, uni lenta bilan bog‘lash mumkin — stul yana turadi, lekin yechim vaqtinchalik va ko‘rimsiz. Dasturlashda ham xuddi shunday: xatolik hardkod bilan, timeout kostili bilan yoki hujjatlashmagan API dan chetlab o‘tish bilan tuzatiladi. Kod kompilyatsiya qilinadi, ilova qulab tushmaydi, lekin yechimni sifatli deb bo‘lmaydi.

Muhim farq: xatolik (bug) — kod ishlamaganda, kostil — kod ishlaganda, lekin noto‘g‘ri loyihalashtirilganda. Kostil har doim dasturchining ongli tanlovidir: “Bilaman, bu ko‘rimsiz, lekin hozir bu muammoni hal qiladi”.

Stripe (2024) baholashiga ko‘ra, dasturchilar texnik qarz va kostillar bilan ishlashga o‘rtacha haftasiga 17 soat sarflaydilar — ish vaqtining deyarli yarmi. Bu jamoaning mahsuldorligining bevosita yo‘qotilishidir.

Kostillar qachon va nima uchun paydo bo‘ladi

Birinchi va asosiy sabab — muddat (deadline). Chiqarilishga bir kun qolganda va kritik xatolik hali tuzatilmagan bo‘lsa, jamoa to‘g‘ri yechim o‘rniga tezkor yechimni tanlaydi. Qiymatni hardkodlash, tekshirishni o‘chirish, sleep() qo‘shish — deadline kostillarining klassik namunalari. Tajribali dasturchi har doim bunday joylarni TODO yoki FIXME bilan belgilaydi.

Ikkinchi sabab — API nomuvofiqligi. Tashqi kutubxona yoki freymvork hujjatlarda ta‘riflanganidek harakat qilmaydi. Freymvork kerakli klassni eksport qilmaydi, metod deprecated deb belgilangan va alternativa yo‘q. Dasturchi refleksiyadan, ichki API dan yoki aylanma yo‘ldan foydalanishga majbur. Java da bu setAccessible(true) orqali kirish, Swift da — @objc va performSelector bo‘lishi mumkin.

Uchinchi sabab — legacy-kod. Dasturchi 5–10 yil oldin eskirgan freymvork versiyasida yozilgan loyihani meros oladi. Butun modulni qayta yozishga vaqt va byudjet yo‘q, shuning uchun yangi funksionallik eski kodga kostillar orqali “yopishtiriladi”. Asta-sekin shuncha qatlam to‘planadiki, modul „big ball of mud” ga aylanadi.

To‘rtinchi sabab — testlarning yo‘qligi. Testlarsiz refaktoring xavfli: arxitektura o‘zgarishi ishlayotgan funksionallikni buzishi mumkin. Testlar bo‘lmaganda, dasturchi barqarorlikni xavf ostiga qo‘ygandan ko‘ra, ishlayotgan kod ustiga kostil qo‘shishni afzal ko‘radi. Google Testing Blog (2024) ma‘lumotlariga ko‘ra, testlari bo‘lmagan jamoalar 3 marta tez-tez workaround yechimlaridan foydalanadilar.

Kostillarning turlari

Kostillarning tasnifi jamoaga qanday turdagi texnik qarz bilan ish olib borayotganini tushunishga va to‘g‘ri bartaraf etish strategiyasini tanlashga yordam beradi. Asosiy turlarni ko‘rib chiqaylik.

Hardkod — eng keng tarqalgan tur. Konfiguratsiya, resurs yoki parametr o‘rniga koddagi qattiq belgilangan qiymat ishlatiladi. Misol: hardkodlashtirilgan server URL, 5 soniyalik timeout, shrift o‘lchami 16pt. Hardkod kodni masshtablanmaydigan qiladi va har bir o‘zgarishda qayta kompilyatsiyani talab qiladi.

Copy-paste — umumiy mantiqni ajratish o‘rniga kod qismini kichik o‘zgarishlar bilan takrorlash. Klassik alomat: loyihada bir satr bilan farq qiluvchi 3 ta o‘xshash metod mavjud. Copy-paste topshiriq vaqtida kod yozishni tezlashtiradi, lekin kelajakda uni qo‘llab-quvvatlashni 10 marta sekinlashtiradi — tuzatish bir o‘rniga 3 joyda kiritilishi kerak.

Bo‘sh try-catch — hech narsa qilmaydigan yoki faqat xatolikni qayd etadigan, lekin uni qayta ishlamaydigan catch bloki. Bunday kostil istisnoni “bostiradi”, lekin uning sababini hal qilmaydi. Ilova ishlashda davom etadi, lekin ma‘lumotlar shikastlanishi mumkin va foydalanuvchi teskari aloqa olmasligi mumkin.

Koddagi sleep — hodisa yoki callback bo‘lishi kerak bo‘lgan joyda kutish uchun Thread.sleep(500) yoki DispatchQueue.main.asyncAfter. Bunday kod ishonchsiz: sekin qurilmada 500 ms yetarli bo‘lmasligi mumkin, tez qurilmada pauza ortiqcha bo‘ladi. To‘g‘ri timinglar bilan CountDownLatch, Semaphore yoki async/await dan foydalaning.

Moslik bayroqlari — OT versiyasini, qurilma modelini yoki funksiya mavjudligini tekshiruvchi if-else kaskadlari. Bayroqlar soni 3–4 dan oshganda, kod spagettiga aylanadi. Yechim — Strategy pattern yoki konfiguratsiya orqali Feature Flags.

Kostil va texnik qarz

Ko‘plab dasturchilar kostilni texnik qarz bilan aralashtirib yuborishadi. Farq — miqyos va onglilikda. Kostil — mahalliy, aniq yechim (bitta metod, bitta klass). Texnik qarz — modul yoki butun ilova arxitekturasiga ta‘sir qiluvchi tizimli muammo.

Ward Cunningham (Technical Debt termini yaratuvchisi) metaforasi: texnik qarz bankdan kredit olishga o‘xshaydi. Hozir pul olasiz, uyni tezroq qurish uchun, keyin foiz to‘laysiz. Kostil — tornavida o‘rniga bolg‘a bilan mix qoqish: ish bajariladi, lekin kamroq samarali.

Bitta kostil texnik qarz yaratmaydi. Lekin bitta modulda 50 ta kostil = arxitektura qarzi. Shuning uchun jamoa qoidasi: har bir kostil code review yoki task tracker da qayd etiladi va jamoa muntazam (har sprintda bir marta) to‘plangan workaround yechimlarini ko‘rib chiqadi.

Spotify Engineering (2023) tajribasiga ko‘ra, koddagi kostillarni (maxsus TODO yorlig‘i yoki custom annotation orqali) hisobga oluvchi jamoalar refaktoring vaqtini 30% qisqartiradi — chunki muammoli joylarni qidirishga soatlab vaqt sarflamaydilar.

Kostillardan qanday qutulish mumkin

Birinchi qadam — inventarizatsiya. Kod bazasida kalit so‘zlarni qidiring: TODO, FIXME, HACK, WORKAROUND, KLUDGE. Zamonaviy IDE lar ularni alohida rang bilan ajratib ko‘rsatadi. GitHub ham Pull Request interfeysida TODO ni ko‘rsatadi. Barcha kostillarning prioritetli ro‘yxatini tuzing.

Ikkinchi qadam — prioritetlashtirish. Hammasi bir vaqtning o‘zida tuzatilishi shart emas. Prioritet = fayldagi o‘zgarish chastotasi × kritiklik. Agar fayl yiliga 2 marta o‘zgarsa, kostil kutishi mumkin. Agar modul har sprintda o‘zgartirilsa — kostil birinchi navbatda tuzatilishi kerak.

Uchinchi qadam — testlar bilan refaktoring. Hech qachon kostilni testsiz refaktoring qilmang. Avval joriy xatti-harakatni (kostil bilan) tekshiruvchi test yozing, keyin refaktoring qiling, keyin testning o‘tishiga ishonch hosil qiling. Busiz kostilni refaktoring qilish u yozilgan funksionallikni buzishi mumkin.

// Oldin: hardkodlashtirilgan URL workaround
fun getApiUrl(): String {
    return "https://api.example.com/v2"
}

// Keyin: BuildConfig orqali konfiguratsiya
fun getApiUrl(): String {
    return BuildConfig.API_BASE_URL
}

To‘rtinchi qadam — avtomatlashtirish. Ma‘lum kostil namunalarini taqiqlovchi linter sozlang. Masalan, Kotlin uchun Detekt produksiya kodida Thread.sleep() yo‘qligini tekshirishi mumkin, ESLint — loyihada console.log ni taqiqlaydi. Bu bir xil turdagi yangi kostillarning paydo bo‘lishining oldini oladi.

Qachon kostil oqlangan

Terminning salbiy ma‘nosiga qaramay, kostil oqlangan yechim bo‘lishi mumkin. Asosiy shart: kostil vaqtinchalik, aniq belgilangan va almashtirish rejasiga ega. Har bir katta loyihaning produksiya kodida yuzlab oqlangan kostillar mavjud.

Vaziyat 1: produksiyadagi hotfix. Kritik xatolik barcha foydalanuvchilarda qulab tushadi. Jamoaga bir soat ichida tuzatish kerak. To‘g‘ri yondashuv: xatolikni istalgan usul bilan tuzatamiz, hotfix ni joylaymiz. Ertasi kuni to‘g‘ri yechimni yozib, topshiriqni yopamiz. Hotfix 48 soatdan ko‘p yashamasa, oqlangan kostildir.

Vaziyat 2: kutubxonaning yangi versiyasini kutish. Freymvork master da tuzatilgan, lekin chiqarilishi 2 haftadan keyin bo‘ladigan xatolikni o‘z ichiga oladi. Murakkab aylanma kod yozish o‘rniga, jamoa “REMOVE after library 3.2” yozuvi bilan workaround qo‘shadi. 3.2 chiqqach, workaround o‘chiriladi.

Vaziyat 3: startap yoki MVP ni ishga tushirish. MVP bosqichida tezlik arxitekturadan muhimroq. Boshida kostillar normal holat. Muammo startap mahsulotga aylanmaganda va kostillar qolganda yuzaga keladi. Tavsiya: moliyalashtirish bosqichidan so‘ng kritik texnik qarzni to‘lash uchun sprint ajrating.

Asosiy prinsip: “Legacy — bu testsiz birovning kodi” (Michael Feathers). Agar kostil test bilan qoplangan va aniq hujjatlashtirilgan bo‘lsa — u boshqariladi. Agar 2 yil unutilgan modulda izohsiz osilgan bo‘lsa — bu endi kostil emas, arxitektura muammosi.