Proqramlaşdırmada velosiped: nədir, səbəbləri və necə qarşısını almaq

Proqramlaşdırmada velosiped nədir

Velosiped — proqramçı cəmiyyətindən bir termindir, hazır kitabxana, freymvork və ya xidmət şəklində mövcud olan funksionallığın öz tətbiqini yaratmağı bildirir. İngilis dilli mühitdə reinventing the wheel — təkəri yenidən icad etmək ifadəsi işlədilir. Azərbaycan dilində də «velosiped», «özəl tətbiq», «öz velosipedi» variantlarına rast gəlinir.

Metaforanın mənşəyi onunla bağlıdır ki, təkər bəşəriyyətin ən qədim ixtiralarından biridir. Onu XXI əsrdə yenidən yaratmağa çalışmaq mənasızdır. Proqramlaşdırmada analogiya daha dəqiqdir: hazır kitabxanalar minlərlə mühəndis tərəfindən illərlə optimallaşdırılmış «təkərlərdir». Daha keyfiyyətsiz öz təkərini yaratmaq resurs itkisidir.

RedMonk analitik hesabatında (2023) orta kommersiya tətbiqinin təxminən 500 xarici asılılıq istifadə etdiyini hesabladı. Əgər proqramçılar onların hər birini özləri yazsaydı, layihənin dəyəri dəfələrlə artar, bazara çıxma müddəti isə illər çəkərdi. Paket menecerləri ekosistemi (npm, Maven, PyPI, NuGet) məhz təkəri yenidən icad etməkdən qaçmaq üçün mövcuddur.

Velosipedin əlamətləri

Kod, velosiped olan, bir neçə əlamətlə tanınır: standart tapşırığı qeyri-standart üsulla həll edir, testləri və ya sənədləri yoxdur, hazır kitabxanalarda çoxdan nəzərə alınmış kənar halları dəstəkləmir. Çox vaxt belə kod layihənin «unikal tələbləri» nəzərə alınmaqla yazılır, halbuki əslində bu tələblər tipik olanlardan fərqlənmir.

Velosiped və xüsusi həll arasındakı fərq

Xüsusi həll, hazır kitabxana memarlıq və ya lisenziya məhdudiyyətlərinə görə uyğun olmadıqda əsaslandırılır. Velosiped obyektiv səbəblər olmadan — «oynamaq» istəyi, başqasının koduna güvənməmək və ya mövcud alətləri bilməmək səbəbindən yaradılır. Fərq prinsipialdır: xüsusi həll şüurlu seçimdir, velosiped isə səhvdir.

Proqramçılar niyə velosiped icad edir

Birinci və ən geniş yayılmış səbəb — mövcud həlləri bilməmək. Junior proqramçı JSON-u parselləmək üçün standart kitabxanada daxili funksiyanın olduğunu bilməyə bilər. Bunun əvəzinə o, parseri əl ilə yazacaq. Bu problem xüsusilə dilin ekosisteminə yeni daxil olan başlanğıclar üçün aktualdır.

İkinci səbəb — nəzarət illüziyası. Təcrübəli proqramçılar bəzən populyar kitabxananın müəlliflərindən «daha yaxşı yazacaqlarına» əmindirlər. Statistikalar əksini deyir: milyonlarla layihədə istifadə olunan kitabxanada səhv ehtimalı yeni yazılmış koddan əhəmiyyətli dərəcədə aşağıdır. Synopsys (2024) məlumatına görə, Open Source kodunda hər min sətirdə orta hesabla 0.1 səhv, korporativ koddə isə 1–2 səhv olur.

Üçüncü səbəb — təkrar istifadə mədəniyyətinin olmaması. İşə başlamazdan əvvəl hazır həlləri araşdırmaq adət olmayan şirkətlərdə hər bir proqramçı «öz velosipedini» yaradır. Bu kodun parçalanmasına gətirib çıxarır: bir layihədə müxtəlif işçilər tərəfindən yazılmış üç fərqli HTTP-klient tətbiqi ola bilər.

Psixoloji aspektlər

IKEA effekti — insanın öz yaratdığını obyektiv olaraq daha yaxşı hazır şeylərdən yüksək qiymətləndirdiyi psixoloji fenomendir. Proqramlaşdırmada bu, «öz velosipedinə» görə qürur və aşkar üstünlüklərə baxmayaraq onu hazır kitabxana ilə əvəz etmək istəməmək kimi özünü göstərir.

Layihədə velosiped yaratmağın nəticələri

İqtisadi nəticələr ən aydındır. Stripe (2022) qiymətləndirməsinə görə, proqramçılar iş vaxtının 35%-ə qədərini artıq hazır həllər şəklində mövcud olan kodun yaradılmasına sərf edirlər. 10 nəfərlik komandanın maaşına hesablandıqda bu, velosiped icad etməyə sərf olunan təxminən 200 min dollar illik itkidir.

Texniki nəticələrə kod bazasının böyüməsi, test əhatəsinin azalması (özəl kod adətən daha pis test edilir), səhv və zəifliklərin sayının artması daxildir. Bundan əlavə, hər bir özəl komponent monitorinq və dəstək tələb edən başqa bir uğursuzluq nöqtəsidir.

Google «Why Google Stores Billions of Lines of Code» (2023) araşdırmasında qeyd etdi ki, hətta ən böyük texnologiya şirkətində belə yeni asılılıq əlavə etmək və ya öz tətbiqini yazmaq barədə qərar qəbul etmək üçün ciddi proses mövcuddur. Daxili komandaların əksəriyyəti əvvəlcə vahid kod deposunda hazır həll axtarır.

Komandaya təsir

Velosipedlər informasiya asinxronluğu yaradır: bir proqramçı getdikdə, onun özəl komponenti sənədsiz və dəstəksiz qalır. Komandanın yeni üzvləri qeyri-standart kodu başa düşməli olur, məhsuldar işə sərf edə biləcəkləri vaxtı itirirlər.

Koddakı tez-tez rast gəlinən velosiped nümunələri

Ən geniş yayılmış nümunə — JSON və ya XML-in əl ilə parsellənməsidir, halbuki demək olar ki, bütün müasir dillərdə daxili vasitələr var. Proqramçılar JSON.parse()-in tapşırığı bir sətirdə həll etdiyini bilmədən obyekt ağacını gözdən keçirmək üçün rekursiv funksiyalar yazır.

İkinci nümunə — HTTP-klientin öz tətbiqi. Standart kitabxanalar (fetch, axios, OkHttp, URLSession) keşləmə, yenidən qoşulma, timeout və təhlükəsizliyi dəstəkləyir. Özəl klient adətən bu tələblərdən ən azı birini nəzərə almır, bu da prodakşnda səhvlərə gətirib çıxarır.

Üçüncü nümunə — SLF4J, Winston və ya Log4j istifadə etmək əvəzinə öz loqlama sistemini yazmaqdır. Proqramçı həftələrlə hazır kitabxanaların rotasiya, loqlama səviyyələri, asinxron yazma və monitorinq sistemləri ilə inteqrasiya dəstəyi ilə dərhal etdiyi şeyi yazmağa sərf edir.

# velosiped — manual CSV parselləmə
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# əvəzinə standart kitabxanadan istifadə
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Özəl ORM anti-nümunəsi

Öz ORM (Object-Relational Mapping) yazmaq — yəqin ki, ən bahalı velosipeddir. Hibernate, Entity Framework və ya SQLAlchemy kimi hazır ORM-lər illərlə hazırlanmışdır, keşləmə, gec yükləmə, miqrasiyalar və onlarla DBMS-ni dəstəkləyir. Özəl ORM adətən bir verilənlər bazası ilə məhdudlaşır və qoşulmaların idarə edilməsində kritik səhvlər ehtiva edir.

Velosiped nə vaxt əsaslandırılır

Öyrənmək — velosipedin nəinki əsaslandırıldığı, həm də faydalı olduğu yeganə vəziyyətdir. Tədris məqsədləri üçün öz parserini, HTTP-serverini və ya ORM-ni yazmaq bu alətlərin necə işlədiyini anlamağa kömək edir. Eyni zamanda tədris layihəsi ilə prodakşn kodunu qarışdırmamaq vacibdir: pet-layihə üçün yaxşı olan, kommersiya inkişafında qəbuledilməzdir.

Unikal tələblər həqiqətən öz tətbiqi tələb edə bilər. Heç bir kitabxana xüsusi protokolu, məlumat formatını və ya aparat platformasını dəstəkləmirsə, xüsusi həll yaratmaq əsaslandırılır. Amma əvvəlcə tapşırığın həqiqətən unikal olduğuna əmin olmaq lazımdır, sadəcə zəif öyrənilmədiyinə yox.

Lisenziya məhdudiyyətləri — başqa bir qanuni səbəbdir. Bəzi Open Source lisenziyaları (GPL, AGPL) şirkətin biznes modeli ilə uyğun olmaya bilər. Belə hallarda daha icazəli lisenziya ilə öz tətbiqini hazırlamaq əsaslandırılır.

Üç cəhd qaydası

Praktiki qayda mövcuddur: öz tətbiqini yazmazdan əvvəl üç fərqli hazır həll tapmağa və sınamağa çalışın. Heç biri uyğun gəlmirsə — özünüzü yaradın, lakin mövcud variantların niyə rədd edildiyini sənədləşdirin. Bu, şüursuz velosiped icad etməkdən qoruyur.

Velosiped yaratmaqdan necə qaçınmaq

Birinci addım — hər hansı tipik tapşırıq üzərində işə başlamazdan əvvəl hazır həllər axtarmaq vərdişinin formalaşdırılmasıdır. Paket menecerləri, GitHub, Stack Overflow üzrə axtarışdan istifadə edin. Araşdırmaya sərf olunan vaxt öz kodunu yazmaqdan imtina hesabına dəfələrlə geri qayıdır.

İkinci addım — velosipedlərin aşkarlanmasına diqqət yetirən kod-icmalın tətbiqidir. İcmalda sual verin: «Niyə bu tapşırıq üçün hazır kitabxanadan istifadə etmirik?» Əgər cavab obyektiv səbəblər ehtiva etmirsə — bu velosipeddir. Böyük şirkətlərdə (Google, Meta) kod-icmal məcburi velosiped yoxlamasını əhatə edir.

Üçüncü addım — daxili bilik reyestrinin yaradılmasıdır. Layihədə hansı kitabxana və alətlərin istifadə edildiyini, hansı tapşırıqları həll etdiyini sənədləşdirin. Yeni proqramçılar bu məlumata çıxış əldə etməlidirlər ki, bilməməkdən velosiped yaratmasınlar. Qəbul edilmiş memarlıq qərarlarının (ADR) siyahısını seçim əsaslandırması ilə aparın.

• Araşdırın yeni tapşırığa başlamazdan əvvəl paket menecerini
• Yoxlayın dilin standart kitabxanasını — tipik tapşırıqların 80%-ni əhatə edir
• İstifadə edin kod-icmalı velosipedləri aşkar etmək üçün
• Sənədləşdirin kitabxana seçimi ilə bağlı qərarları
• Yeniləyin ekosistem haqqında bilikləri konfranslarda və bloqlarda

Not Invented Here sindromu

NIH sindromu (Not Invented Here — «bizdə icad edilməyib») — xarici həllərdən istifadəyə qarşı təşkilati qərəzdir. NIH sindromu olan şirkətlər öz inkişaflarından üstün olsalar belə, Open Source kitabxanalarını rədd edərək hər şeyi müstəqil hazırlamağa üstünlük verirlər. Bu sindrom velosipedin korporativ versiyasıdır.

Klassik nümunə — Netscape 1990-cı illərin sonunda, şirkət mövcud kod bazasını inkişaf etdirmək əvəzinə brauzeri sıfırdan yenidən yazmağa illər sərf etdi. Nəticə — bazar payının itirilməsi və AOL tərəfindən satın alınma. Bunun əksinə, Android Linux nüvəsi üzərində qurulub və minlərlə Open Source komponentindən istifadə edir — bu, məhsulu rekord müddətdə bazara çıxarmağa imkan verdi.

Harvard Business Review (2023) araşdırması göstərdi ki, NIH sindromunun aşağı səviyyəsinə malik şirkətlər məhsulları bazara 40% daha sürətli çıxarır və inkişafa 30% daha az xərcləyir. Kodun təkrar istifadəsi mədəniyyəti müasir proqram təminatı inkişafında rəqabət üstünlüyüdür.

// velosiped — özəl sıralama tətbiqi
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// daxili sıralama — standart həll
arr.sort((a, b) => a - b);