Proqramlaşdırmada kostıllar — nədir, səbəbləri və nə vaxt haqlıdır

Proqramlaşdırmada “kostıl” nədir

Kostıl (crutch) — işləyən, lakin “ələyrisə” hazırlanmış proqram həllidir: konkret problemi bağlayır, lakin onun səbəbini aradan qaldırmır, layihənin memarlığına uyğun gəlmir və ətraf mühitin ən kiçik dəyişikliklərində sına bilər. Metafora dəqiqdir — real kostıl kimi, belə kod “getməyə” kömək edir, lakin “ayağı” müalicə etmir.

Proqramçılar “kostılla dəstəkləyirlər” bug-ları, versiya uyğunsuzluqlarını, platforma xüsusiyyətlərini və təcili müştəri tələblərini. Tipik kostıl — kostıl-şərt: əgər iOS 15, boşluq əlavə et; əgər Huawei — düyməni gizlət. Bu cür yoxlamalar çoxalır və kodu platforma və versiya budaqlarından ibarət “qatlı tort”-a çevirir.

Kostıllar müxtəlif miqyasda olur: bir sətirlik kostıl-şərtdən tutmuş, kitabxananın davranışını “düzəldən” bütöv modula qədər. Anlamaq vacibdir ki, kostıl həmişə pis deyil: düzgün əllərdə bu, məhsulu vaxtında buraxmağa imkan verən bir alətdir. Problem kostıl koddə əbədi qaldıqda başlayır.

Kostıllar niyə yaranır: səbəblər və kontekst

Əsas səbəb — ideal həll ilə layihənin real məhdudiyyətləri arasında ziddiyyət. Proqramçı necə düzgün etməyi bilir, lakin vaxt, pul və ya texniki məhdudiyyətlər buna imkan vermir. Nəticədə “sadəcə işləyən” kompromis həll yaranır.

Dörd əsas səbəbi nəzərdən keçirək. Bu səbəbləri anlamaq kostıllara səhv kimi deyil, idarəetmə tələb edən praqmatik alət kimi yanaşmağa kömək edir.

Son tarixlər

Ən çox yayılmış səbəb. Buraxılış sabahdır, bug yalnız konkret modeldə təkrarlanır, memarlıq düzəlişi iki həftə çəkir. Kostıl-şərt bir saat çəkir və problemi bağlayır. Buraxılışdan sonra komanda qayıdıb düzgün yazmağa söz verir. “Müvəqqətidən daha daimi heç nə yoxdur” — məhz belə kostıllar haqqında.

Versiya uyğunsuzluğu

Kitabxana A Android 12 tələb edir, lakin tətbiqiniz Android 10-u dəstəkləyir. Həll — aralıq təbəqə yazmaq, ƏS versiyasını yoxlayan və icra yolunu seçən. Bu kostıldır, çünki kitabxana yenilənəndə aralıq təbəqəni yenidən yazmaq lazım olacaq. Lakin alternativ — kitabxanadan və ya köhnə cihazların dəstəyindən imtina — daha pis ola bilər.

// API 29 uyğunluğu üçün kostıl
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

Bug-lu xarici asılılıqlar

Layihənin asılı olduğu kitabxana bug ehtiva edir, lakin onun yenilənməsi həftələr çəkə bilər (PR, kod-icmal, nəşr lazımdır). Gözləmək əvəzinə komanda wrapper yazır, kitabxananın davranışını anında yamalayan. Düzəldilmiş kitabxana versiyası çıxdıqdan sonra wrapper silinir. Silinməzsə — bu artıq memarlıq problemidir.

Sistemin natamam anlaşılması

Legacy-layihədə yeni proqramçı kodun niyə belə işlədiyini anlamır. Bunu anlamaq əvəzinə, mövcud kodun üzərinə yeni şərt əlavə edir. Bu ən təhlükəli kostıl növüdür, çünki müəllif bunun kostıl olduğunu dərk etmir. Yeganə dərman — kod-icmal və komandanın yeni üzvləri üçün cütlük proqramlaşdırmadır.

Kostıl nə vaxt haqlıdır: praqmatik yanaşma

Hər kostıl pis deyil. Real inkişafda mütləq kod təmizliyi əldə edilməz və çox vaxt məqsədəuyğun deyil. Praqmatik yanaşma etiraf edir ki, müvəqqəti həllər prosesin bir hissəsidir, lakin onların şüurlu olmasını, sənədləşdirilməsini və aradan qaldırılmasının planlaşdırılmasını tələb edir. Kostıl biznes tapşırığını təmiz memarlıq həllindən daha sürətli həll etdikdə haqlıdır.

Haqlı kostılın meyarları: konkret problemi bağlayır, sahibi var (kim silinməsinə cavabdehdir) və refaktorinq planı mövcuddur. Üç şərtdən heç olmasa biri yoxdursa — kostıl texniki borca çevrilir. TODO-şərhlər trackerda ticket ilə — sənədləşdirmənin minimal üsuludur.

Haqlı kostıl nümunəsi

Buraxılış budağında kritik bug, sabahkı yerləşdirməyə qədər bağlanmalıdır. Təmiz həll memarlıq refaktorinqi tələb edir və iki həftə çəkəcək. Kostıl — nil yoxlaması əlavə etmək və hotfix kimi göndərmək. Haqlılıq şərtləri: trackerda refaktorinq üçün ticket yaradılıb, məsul şəxs təyin edilib, kostıl şərh ilə qeyd olunub. İki həftədən sonra komanda tapşırığa qayıdır.

// TODO: IT-1234 — remove this crutch after AuthService refactoring
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

Müvəqqəti kostılı memarlıq problemindən necə ayırmaq olar

Şüurlu kostıl ilə memarlıq problemi (texniki borc) arasındakı sərhəd iki parametr üzrə keçir: qərarın şüurlu olması və onun aradan qaldırılması planının mövcudluğu. Kostıl həmişə məlum ömür müddəti olan müvəqqəti həlldir. Texniki borc — diqqətsiz qalmış çoxsaylı kostılların nəticəsidir.

Kostıl nə vaxt problemə çevrilir

Vəziyyət pisləşir, o zaman ki kostılların sayı kritik kütləni keçir. Hər yeni kostıl sistemin “kövrəkliyini” artırır: bir yerdə dəyişiklik digərini sındırır. Nəticədə inkişaf yavaşlayır, bug-lar çoxalır, yeni proqramçı müəllifin köməyi olmadan kodu başa düşə bilmir. Bu anda kostıllar müvəqqəti həll olmaqdan çıxıb memarlıq probleminə çevrilir.

Kostıl böhranının əlamətləri

Koddə ƏS versiyası, cihaz istehsalçısı və konkret kitabxananın mövcudluğu üçün beş iç-içə yoxlama varsa — bu kostıl deyil, memarlıq problemidir. Bir düzəlişin əlavə edilməsi qonşu modullarda üç reqressiyaya səbəb olursa — kostıllar lokal olmaqdan çıxıb. Kod-icmal “daha bir kostıla” görə mütəmadi olaraq rədd edilirsə — refaktorinq planlaşdırmaq vaxtıdır.

• Eyni kostıl üç və daha çox yerdə təkrarlanırsa — vahid həll etmək vaxtıdır
• Kostıl aradan qaldırma planı olmadan üç sprintdən çox yaşayırsa — bu artıq texniki borcdur
• Yeni proqramçı kodun niyə belə işlədiyini başa düşmürsə — kostıl sənədləşdirilməyib
• Kostılın silinməsi zəncirvari reaksiya səhvlərinə səbəb olursa — kostıldan asılılıq memarlıq halına gəlib

Kostılların refaktorinqi: strategiya və praktika

Kostılların refaktorinqi — müvəqqəti həllərin memarlıq cəhətdən düzgün olanlarla əvəz edilməsi prosesi. Bu vaxt tələb edir, buna görə prioritetləşdirmə strategiyası lazımdır: bütün kostılları dərhal aradan qaldırmaq lazım deyil. Yaxşı strategiya — hər kostılı iki parametr üzrə qiymətləndirmək: kodun bu sahəsində dəyişiklik tezliyi və istifadəçilərə təsir.

Prioritetləşdirmə strategiyası

Yüksək prioritet — tez-tez dəyişən modullardakı kostıllar (biznes məntiqi, ümumi təyinatlı UI), inkişafı yavaşladan və reqressiyalara səbəb olan. Orta prioritet — nadir dəyişən modullardakı, lakin istifadəçilərə potensial təsiri olan kostıllar (ödəniş emalı, avtorizasiya). Aşağı prioritet — stabil işləyən və dəyişdirilməsi planlaşdırılmayan legacy-koddakı kostıllar.

Addım-addım aradan qaldırma prosesi

Addım 1: inventarlaşdırma — kostıllarla əlaqəli bütün TODO və FIXME-ləri tapın. Addım 2: qiymətləndirmə — hansının hələ də aktual olduğunu müəyyən edin. Addım 3: planlaşdırma — yüksək prioritetdən başlayaraq kostılların refaktorinqini sprinta təyin edin. Addım 4: əvəz etmə — təmiz həll tətbiq edin, kostılı və onun TODO-şərhini silin. Addım 5: yoxlama — testlərin keçdiyinə və reqressiyaların olmadığına əmin olun.

# Find all TODO-crutches in the project
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

Yeni kostılların qarşısının alınması

Kostıllarla mübarizənin ən yaxşı yolu onları lazımsız yerə yaratmamaqdır. Kostıl yazmazdan əvvəl özünüzə üç sual verin: ağlabatan vaxtda təmiz həll etmək olarmı? Kostıl olmayan alternativ varmı? Komandanın qayıdıb bunu yenidən yazmağa vaxtı olacaq? Heç olmasa bir suala cavab “xeyr”-dirsə — kodu “dəstəkləməzdən” əvvəl bir daha düşünün.