Zibil-kod və qarmaqarşıq mobil layihələrdə — əlamətlər və refaktoring

Proqramlaşdırmada zibil-kod nədir

Zibil-kod (həmçinin spaghetti code, qarmaqarşıq, big ball of mud) — strukturunu itirmiş və qarışıq asılılıqlar topasına çevrilmiş kod bazası üçün metaforadır. Belə koda hər hansı dəyişiklik bir yerdə başqa bir yeri sındırır, yeni funksionallıq əlavə etmək isə riskli bir işə çevrilir.

Mobil inkişafda zibil-kod xüsusilə tənqidi əhəmiyyət daşıyır: "qarmaqarşıq" üzərində qurulmuş tətbiq yavaşlamağa, köhnə cihazlarda çökməyə başlayır və code review-dən çətin keçir. Arxitekturasız iOS layihəsi qeyri-sabitlik səbəbindən App Review-dan keçməyə bilər.

Stripe məlumatına görə, proqramçılar iş vaxtının 42%-ə qədərini mövcud kodu oxumaq və anlamaq üçün sərf edir. Zibil-kod olan layihələrdə bu göstərici 60%-i keçir ki, bu da inkişafı son dərəcə səmərəsiz edir.

Terminlərin mənşəyi

Spaghetti code (spagetti kod) — 1970-ci illərdə yaranan ən qədim termindir. O, nizamsız idarəetmə keçidləri olan, dolaşıq makaronu xatırladan kodu təsvir edir.

Big ball of mud (böyük palçıq topu) — 1997-ci ildə Brian Foot və Joseph Yoder tərəfindən aydın arxitekturasız, xaotik şəkildə "böyüyən" sistemləri təsvir etmək üçün təqdim edilmiş termindir.

Zibil-kod niyə biznes üçün təhlükəlidir

Zibil-kod yeni funksiyaların bazara çıxarılmasını ləngidir. Komanda vaxtını dəyər yaratmağa deyil, mövcud kodun necə işlədiyini anlamağa və heç nəyi sındırmamağa sərf edir.

McKinsey məlumatına görə, aşağı kod keyfiyyəti olan şirkətlər məhsulun saxlanmasına 20-40% daha çox xərcləyir, yeni funksiyaların çıxarılma sürəti isə yüksək kod keyfiyyəti olan şirkətlərlə müqayisədə 2-3 dəfə aşağıdır.

Zibil-kodun əlamətləri və onu necə tanımaq

Tanımaq zibil-kodu bir sıra obyektiv əlamətlər üzrə mümkündür, onların bir hissəsi avtomatik ölçülür. Əlamətlər nə qədər çox uyğun gəlirsə — problem bir o qədər ciddidir.

Sənayedə Halstead Complexity, Maintainability Index və Technical Debt Ratio kimi kod keyfiyyəti metrikaları istifadə olunur. Bu metrikaları bilmək kod bazasının vəziyyətini obyektiv qiymətləndirməyə kömək edir.

Copy-paste (kodun təkrarlanması)

Ən geniş yayılmış əlamət — təkrarlanan kod blokları. Ümumi funksiya ayırmaq əvəzinə proqramçılar kodu minimal dəyişikliklərlə bir yerdən digərinə köçürürlər.

Normal səviyyə 5%-ə qədər təkrarlanma hesab olunur. Əgər təkrarlanma 15%-i keçirsə — bu ciddi siqnaldır. Simian və PMD Copy Paste Detector kimi alətlər copy-paste-i avtomatik aşkar etməyə kömək edir.

Uzun metodlar və siniflər

Metod 100 sətirdən uzundursa — bu zibil-kodun aşkar əlamətidir. Belə metod adətən çox şey edir və tək məsuliyyət prinsipini (Single Responsibility) pozur.

Siniflər 1000 sətirdən çox kodla da problemlidir. Onlar əlaqəsiz funksionallıq ehtiva edir, bu da test etməni, anlamağı və kodu dəyişdirməyi çətinləşdirir.

Yüksək siklotomik mürəkkəblik

Siklotomik mürəkkəblik (Cyclomatic Complexity) — koddakı müstəqil yolların sayını göstərən metrikadır. 15-dən yuxarı dəyər problemli hesab olunur.

Mürəkkəbliyi 30-dan yuxarı olan metodlar — "fəlakət zonası". Onlar çoxlu budaqlanma ehtiva edir, onları test etmək və dərindən analiz olmadan anlamaq mümkün deyil.

Zibil-kodun yaranma səbəbləri

Zibil-kod "öz-özünə" yaranmır — o, həmişə komandadakı müəyyən proseslərin və qərarların nəticəsidir. Səbəbləri anlamaq gələcəkdə onun yaranmasının qarşısını almağa imkan verir.

JetBrains Developer Ecosystem 2024 məlumatına görə, proqramçıların 67%-i vaxt çatışmazlığı səbəbindən bacardıqlarından daha pis kod yazdıqlarını etiraf edir. Bu, texniki borcun yığılmasının əsas səbəbidir.

Tələsmə və deadlinelar

Ən tez-tez rast gəlinən səbəb — sıxılmış müddətlərdir. Komanda "nə alınsa" kodu yazır, əsas odur ki, deadline-a çatsın. Refaktoring, testlər və code review "sonraya" saxlanılır.

Problem ondadır ki, "sonra" heç vaxt gəlmir — növbəti sprintdə yeni deadlinelar yaranır və texniki borc qar topu kimi yığılır.

Kod-rewyun olmaması

Kod-rewyu olmadan hər proqramçı öz üslubunda yazır, öz nümunələrindən istifadə edir və öz "mina"larını qoyur. Zamanla kod bazası vahidliyini itirir.

Hər pull request üçün məcburi kod-rewyu tətbiq edən komandalar SmartBear 2024 araşdırmasına görə istehsalatda 60% daha az defektə malikdir.

Əvvəldən zəif arxitektura

Əgər layihə aydın arxitektura olmadan başlayırsa, zibil-kod qaçılmazdır. İlk "sürətli həllər" sonradan üzərində keyfiyyətli bir şey qurmaq çətin olan təməl qoyur.

Mobil inkişafda arxitektura seçimi (MVC, MVP, MVVM, Clean Architecture) kod yazmağa başlamazdan əvvəl qəbul edilmiş şüurlu qərar olmalıdır, təkamülün nəticəsi deyil.

Zibil-kodla mübarizə üsulları

Zibil-kodla mübarizə sistematik yanaşma və bütün komandanın intizamını tələb edir. Problemi həll edəcək tək bir alət və ya təcrübə yoxdur — tədbirlər kompleksi lazımdır.

Əsas prinsip — zibil-kodu yazma mərhələsində buraxmamaq, sonra düzəltmək deyil. Profilaktika həmişə mövcud "qarmaqarşığın" refaktoringindən daha ucuzdur.

Kodlaşdırma standartları

Vahid kod üslubu — zibil-kodun qarşısını almaq üçün əsasdır. Kodlaşdırma standartları (Code Style) sənədləşdirilməli və linterlər tərəfindən avtomatik yoxlanılmalıdır.

iOS üçün SwiftLint, Android üçün Ktlint və Detekt istifadə olunur. Konfiqurasiya faylında qaydaların qurulması standartları pozan pull requestləri avtomatik rədd etməyə imkan verir.

Müntəzəm refaktoring

Refaktoring — səhvləri düzəltmək deyil, kodun strukturunu onun davranışını dəyişmədən yaxşılaşdırmaqdır. O, inkişaf prosesinin müntəzəm hissəsi olmalıdır, ayrıca layihə deyil.

Hər sprintin 20% vaxtını ayırmaq tövsiyə olunur refaktoringə və texniki borcun ödənilməsinə. Bu, "qarmaqarşığın" yığılmasının qarşısını alır və komandanın sürətini uzunmüddətli perspektivdə qoruyur.

Məcburi kod-rewyu

Hər pull request ən azı bir proqramçı tərəfindən review-dən keçməlidir. Kod-rewyu təkcə səhvləri deyil, həm də arxitektura pozuntularını, üslub problemlərini və potensial zibil-kod mənbələrini aşkar edir.

Yaxşı təcrübə — copy-paste, metodların uzunluğu, siklotomik mürəkkəblik və test əhatəsinin yoxlanılmasını əhatə edən kod-rewyu checklistidir. Checklist olmadan rəyçilər problemlərin 50%-ə qədərini qaçırır.

Kod bazasını təmizləmək üçün alətlər

Müasir kod analizi alətləri zibil-kodu avtomatik aşkar etməyə, texniki borcu ölçməyə və keyfiyyəti nəzarətdə saxlamağa imkan verir. Bu alətlərin CI/CD pipeline-a inteqrasiyası davamlı monitorinq təmin edir.

Ən azı bir statik analizator və bir metrik ölçmə alətindən istifadə tövsiyə olunur. Əlavə olaraq kod keyfiyyəti haqqında məlumatların aqreqasiyası üçün platforma qoşmaq olar.

Statik analizatorlar

• SonarQube — kod keyfiyyətinin aparıcı analiz platforması, 30+ dili dəstəkləyir və Technical Debt Ratio metrikalarını verir
• ESLint — JavaScript və TypeScript üçün standart, konfiqurasiya faylları vasitəsilə qurulur və IDE-ya inteqrasiya olunur
• SwiftLint — iOS layihələri üçün məcburi alət, Swift Style Guide-a uyğunluğu yoxlayır

SonarSource məlumatına görə, statik analizdən istifadə edən komandalar tətbiqdən sonra ilk rübdə istehsalatdakı səhvlərin sayını 30% azaldır.

Metrik ölçmə alətləri

CodeClimate və Codacy — kod keyfiyyəti metrikalarını aqreqasiya edən, dinamikanı izləyən və ən çox texniki borcu olan faylları — "isti nöqtələri" göstərən platformalardır.

Android layihələri üçün Detekt 100-dən çox daxili analiz qaydası təqdim edir, o cümlədən siklotomik mürəkkəblik, metod uzunluğu və kod təkrarlanması yoxlamaları.