Proqramlaşdırmada kostil: bu nədir, hansı növləri var və necə işləyir

Proqramlaşdırmada kostil nədir?

Kostil — bu funksional olaraq düzgün, lakin texniki cəhətdən qeyri-optimal olan proqram həllinin jarqon adıdır. Belə kod işləyir, testlərdən keçir və hətta produksiyaya gedir, lakin onu oxumaq hər şeyi sıfırdan yazmaq istəyi yaradır. İngilisdilli mühitdə workaround, kludge (kluge), hack və ya quick-and-dirty fix terminləri istifadə olunur.

Termin məişət metaforasından gəlir: stulun ayağı qırılarsa, onu lentlə baqlamaq olar — stul yenƏ dayanır, lakin həll müvəqqəti və yaraşıqsızdır. Proqramlaşdırmada da eyni şey: xəta hardkodla, timeout kostili ilə və ya sənədləşdirilməmiş API-dən yan keçməklə düzəlir. Kod kompilyasiya olunur, tətbiq çökmür, lakin həlli keyfiyyətli adlandırmaq olmaz.

Əhəmiyyətli fərq: xəta (bug) — kod işləməyəndə, kostil — kod işləyəndə, lakin səhv dizayn ediləndədir. Kostil həmişə proqramçının şüzlı seçimidir: “Bilirəm ki, bu yaraşıqsızdır, amma hazırda bu problemi həll edir”.

Stripe-in (2024) qiymətləndirməsinə görə, proqramçılar texniki borc və kostillərlə işləməyə orta hesabla həftədə 17 saat sərf edirlər — iş vaxtının təxminən yarısı. Bu, komandanın məhsuldarlığının birbaşa itkisidir.

Kostillər nə vaxt və niyə yaranır

Birinci və əsas səbəb — son tarix (deadline). Buraxılışa bir gün qaldıqda və kritik xəta hələ düzəlməyibsə, komanda düzgün həll əvəzinə sürətli həlli seçir. Dəyərin hardkodu, yoxlamanın söndürülməsi, sleep() əlavə edilməsi — deadline kostillərinin klassik nümunələri. Təcrübəli proqramçı həmişə belə yerləri TODO və ya FIXME ilə qeyd edir.

İkinci səbəb — API uyğunsuzluğu. Xarici kitabxana və ya framework sənədlərdə təsvir edildiyi kimi davranmır. Framework lazımi sinfi ixrac etmir, metod deprecated olaraq qeyd edilib və alternativ yoxdur. Proqramçı refleksiyadan, daxili API-dən və ya dolayı yoldan istifadə etməyə məcbur olur. Java-da bu setAccessible(true) vasitəsilə giriş ola bilər, Swift-də — @objc və performSelector.

Üçüncü səbəb — legacy-kod. Proqramçı 5–10 il əvvəl köhnəlmiş framework versiyasında yazılmış layihəni miras alır. Bütün modulu yenidən yazmağa vaxt və büdcə yoxdur, buna görə yeni funksionallıq köhnə kodun üzərinə kostillər vasitəsilə „yapışdırılır”. Tədricən o qədçox qat yığılır ki, modul „big ball of mud”-ə çevrilir.

Dördüncü səbəb — testlərin olmaması. Testlərsiz refaktorinq təhlükəlidir: arxitektura dəyişikliyi işləyən funksionallığı poza bilər. Testlər olmadıqda, proqramçı sabitliyi riskə atmaqdansa, işləyən kodun üzərinə kostil əlavə etməyi üstün tutur. Google Testing Blog-un (2024) məlumatlarına görə, testləri olmayan komandalar 3 dəfə daha tez-tez workaround həllərindən istifadə edirlər.

Kostillərin növləri

Kostillərin təsnifatı komandaya hansı növ texniki borcla üzləşdiyini anlamağa və düzgün aradan qaldırma strategiyası seçməyə kömək edir. Əsas növlərə baxaq.

Hardkod — ən geniş yayılmış növ. Konfiqurasiya, resurs və ya parametr əvəzinə koddakı sərt dəyər istifadə olunur. Nümunə: hardkodlaşdırılmış server URL-i, 5 saniyəlik timeout, şrift ölçüsü 16pt. Hardkod kodu miqyaslana bilməz edir və hər dəyişiklikdə yenidən kompilyasiya tələb edir.

Copy-paste — ümumi məntiqi ayırmaq əvəzinə kod parçasını kiçik dəyişikliklərlə təkrarlamaq. Klassik əlamət: layihədə bir sətri ilə fərqlənən 3 oxşar metod var. Copy-paste tapşırıq anında kod yazmağı sürətləndirir, lakin gələcəkdə onun saxlanmasını 10 dəfə yavaşlatır — düzəliş bir əvəzinə 3 yerdə edilməlidir.

Boş try-catch — heç nə etməyən və ya yalnız xətanı loglayan, lakin emal etməyən catch bloku. Belə kostil istisnanı „boğur”, lakin onun səbəbini həll etmir. Tətbiq işləməyə davam edir, lakin məlumatlar zədələnə bilər və istifadəçi əks əlaqə almaya bilər.

Koddakı sleep — hadisə və ya callback olmalı yerdə gözləmə üçün Thread.sleep(500) və ya DispatchQueue.main.asyncAfter. Belə kod etibarsızdır: yavaş cihazda 500 ms kifayət etməyə bilər, sürətli cihazda pauza lazımsız olar. Düzgün timinglərlə CountDownLatch, Semaphore və ya async/awai t istifadə edin.

Uyğumluq bayraqları — OS versiyasını, cihaz modelini və ya funksiyanın mövcudluğunu yoxlayan if-else kaskadları. Bayraqlar 3–4-dən çox olduqda, kod spagettiyə çevrilir. Həll — Strategy pattern və ya konfiqurasiya vasitəsilə Feature Flags.

Kostil və texniki borc

Bir çox proqramçı kostil ilə texniki borcu qarışdırır. Fərq — miqyas və şüzlülükdə. Kostil — lokal, konkret həlldir (bir metod, bir sinif). Texniki borc — modulun və ya bütün tətbiqin arxitekturasına təsir edən sistem problemidir.

Ward Cunninghamın (Technical Debt termininin yaradıcısı) metaforası: texniki borc bankdan kredit götürmək kimidir. İndi pul götürürsən ki, evi daha tez tikəsən, sonra faiz ödəyirsən. Kostil — tornavida əvəzinə çırtma ilə mıx vurmaqdır: iş yerinə yetirilir, lakin daha az səmərəli.

Bir kostil texniki borc yaratmır. Lakin bir modulda 50 kostil = arxitektura borcu. Buna görə komanda qaydası: hər kostil code review və ya task tracker-də qeyd olunur və komanda mütəmadi olaraq (hər sprintdə bir dəfə) yığılmış workaround həllərini nəzərdən keçirir.

Spotify Engineering təcrübəsinə (2023) görə, koddakı kostilləri (xüsusi TODO etiketi və ya custom annotation vasitəsilə) qeydə alan komandalar refaktorinq vaxtını 30% qısaltır — çünki problemli yerləri axtarmağa saatlar sərf etmirlər.

Kostillərdən necə qurtulmaq olar

İlk addım — inventarlaşdırma. Kod bazasında açar sözləri axtarın: TODO, FIXME, HACK, WORKAROUND, KLUDGE. Müasir IDE-lər onları ayrı rənglə vurğulayır. GitHub da Pull Request interfeysində TODO-nu göstərir. Prioriteli bütün kostillərin siyahısını tərtib edin.

İkinci addım — prioritetləşdirmə. Bütün kostilləri dərhal düzəltmək lazım deyil. Prioritet = fayldakı dəyişiklik tezliyi × kritiklik. Fayl ildə 2 dəfə dəyişirsə, kostil gözləyə bilər. Modul hər sprintdə dəyişdirilirsə — kostil ilk növbədə düzəldilməlidir.

Üçüncü addım — testlərlə refaktorinq. Testlərsiz kostili heç vaxt refaktori etməyin. Əvvəlcə cari davranışı (kostillə) yoxlayan test yazın, sonra refaktori edin, sonra testin keçdiyinə əmin olun. Bu olmadan kostilin refaktorinqi onun yazıldığı funksionallığı poza bilər.

// Əvvəlcə: hardkodlaşdırılmış URL workaround
fun getApiUrl(): String {
    return "https://api.example.com/v2"
}

// Sonra: BuildConfig vasitəsilə konfiqurasiya
fun getApiUrl(): String {
    return BuildConfig.API_BASE_URL
}

Dördüncü addım — avtomatlaşdırma. Müəyyən kostil nümunələrini qadağan edən linter konfiqurasiya edin. Məsələn, Kotlin üçün Detekt produksiya kodunda Thread.sleep() olmamasını yoxlaya bilər, ESLint — layihədə console.log-u qadağan edə bilər. Bu, eyni tipli yeni kostillərin yaranmasının qarşısını alır.

Nə vaxt kostil haqlıdır

Terminin mənfi mənaya malik olmasına baxmayaraq, kostil haqlı həll ola bilər. Əsas şərt: kostil müvəqqətidir, açıq şəkildə qeyd olunub və dəyişdirilmə planı var. Hər böyük layihənin produksiya kodunda yüzlərlə haqlı kostil var.

Vəziyyət 1: produksiyada hotfix. Kritik xəta bütün istifadəçilərdə çökür. Komandaya bir saat ərzində düzəliş lazımdır. Düzgün yanaşma: xətanı istənilən üsulla düzəldirik, hotfix yerləşdiririk. Ertəsi gün düzgün həlli yazıb tapşırığı bağlayırıq. Hotfix 48 saatdan çox yaşamırsa, haqlı kostildir.

Vəziyyət 2: kitabxananın yeni versiyasının buraxılmasını gözləmək. Framework master-da düzəldilmiş, lakin buraxılış 2 həftəyə olacaq xəta ehtiva edir. Mürəkkəb yan keçmə kodu yazmaq əvəzinə, komanda “REMOVE after library 3.2” qeydi ilə workaround əlavə edir. 3.2 buraxıldıqda, workaround silinir.

Vəziyyət 3: startup və ya MVP-nin işə salınması. MVP mərhələsində sürət arxitekturadan daha önəmlidir. Başlanğıcda kostillər normaldır. Problem startup məhsula çevrilmədikdə və kostillər qaldıqda yaranır. Tövsiyə: maliyyələşdirmə mərhələsindən sonra kritik texniki borcun ödənilməsi üçün sprint ayırın.

Əsas prinsip: “Legacy — bu testsiz yad koddur” (Michael Feathers). Kostil testlə əhatə olunmuş və açıq şəkildə sənədləşdirilmişsə — idarə olunandır. 2 il unudulmuş moduldə şərhsiz asılıbsa — bu artıq kostil deyil, arxitektura problemidir.