Texnoloji zoopark: bu nədir, səbəbləri və metodları

Layihədə texnoloji zoopark nədir

Texnoloji zoopark — bir layihə və ya şirkətdə eyni tapşırığı həll edən həddən artıq müxtəlif alətlərin istifadə edildiyi vəziyyətdir. Məsələn, üç fərqli HTTP klienti (Alamofire, OkHttp, Ktor), iki state menecer (Redux, MobX) və üç verilənlər bazası (Realm, CoreData, SQLite).

Zooparkı müxtəlif tapşırıqlar üçün şüzlə seçilmiş alətlərdən fərqləndirən xüsusiyyət strategiyanın olmamasıdır. Əgər A komandası React Native, B komandası Flutter, C komandası isə Kotlin Multiplatform seçirsə və ortaq qərar yoxdursa — bu zooparkdır. Müxtəliflik özlüyündə zərərli deyil, zərərli olan onun nəzarətsizliyidir.

Layihədəki hər yeni stack proqramçıların idrak yükünü artırır. Effektiv işləmək üçün bütün istifadə olunan texnologiyaların nüanslarını xatırlamaq lazımdır. Google (2024) məlumatlarına görə, müxtəlif stacklər arasında kontekst dəyişməsi vahid texnoloji mühitdə işləməklə müqayisədə proqramçının məhsuldarlığını 23% azaldır.

Texnoloji zooparkın yaranma səbəbləri

Mərkəzləşməmiş qərarlar — əsas səbəb. Hər komanda ümumi strategiyaya fikir vermədən öz layihəsi üçün texnologiyalar seçir. Backend komandası Kotlin, ML komandası Python, mobil komanda Flutter istifadə edir. Ayrılıqda qərarlar düzgündür, lakin birlikdə zoopark yaradırlar.

Birləşmə və satınalmalar — şirkət başqa birini satın aldıqda, texnoloji stacklər birləşir. İki sistem eyni tapşırıqları fərqli şəkildə həll edir. Nümunə: startapı satın aldıqdan sonra böyük şirkət onun Ruby on Rails stackini alır, halbuki daxili standart Java Spring-dir. Sual yaranır: yenidən yazmaq və ya iki stackı paralel saxlamaq?

Dɐb olan texnologiyaların dəyişməsi — hər hype dövrü yeni stack əlavə edir. 2015-ci ildə hamı AngularJS, 2017-də React, 2020-də Svelte yazırdı. İntizam olmadan layihə müxtəlif dövrlərin qatlarını toplayır. İşləyən, lakin dəstəklənməyən legacy modullar tez aradan qaldırılma imkanı olmadan müxtəliflik əlavə edir.

Zoopark komanda və biznes üçün niyə təhlükəlidir

Yeni proqramçıların onboardingi bir əvəzinə 5+ fərqli texnologiyanı öyrənməyə çevrilir. Layihəyə giriş üçün bir həftə əvəzinə yeni başlayan bütün alətləri mənimsəmək üçün bir ay sərf edir. Məhsuldarlığa çatma vaxtı layihədəki stacklərin sayı ilə mütənasib olaraq artır.

Kontekst dəyişməsi — gün ərzində 3+ stackla işləyən proqramçı hər dəyişiklikdən sonra konteksti bərpa etmək üçün 30% vaxt itirir. University of California (2023) məlumatlarına görə, hər dəyişiklikdən sonra ilkin məhsuldarlıq səviyyəsinə qayıtmaq üçün 23 dəqiqə lazımdır. Gündə 5 dəyişiklikdə — demək olar ki, 2 saat itirilir.

Təhlükəsizlik riskləri — hər stack yenilənmələr, zəifliklərin monitorinqi və best practices bilikləri tələb edir. Komanda eyni anda bütün texnologiyalarda ekspert ola bilməz. İstifadə olunan kitabxanaların sayı komandanın onları izləmə və yeniləmə qabiliyyətini aşdıqda asılılıq yorğunluğu məhsulun təhlükəsizliyinə birbaşa təhdiddir.

Infrastrukturun mürəkkəbliyi — CI/CD hər stack üçün konfiqurasiya edilməlidir. Müxtəlif qurma sistemləri (Gradle, CocoaPods, npm, pip), müxtəlif icra mühiti tələbləri. İnfrastruktur komandası müxtəlif pipeline-ları təkmilləşdirmək əvəzinə onları saxlamaq üçün resurslar sərf edir.

Layihədə problemi necə diaqnoz etmək olar

Stack inventarizasiyası — istifadə olunan texnologiyaların tam siyahısını tərtib edin: dillər, frameworklər, verilənlər bazaları, CI/CD, monitorinq sistemləri. Hər texnologiya üçün layihə/modul sayını, dəstək səviyyəsini və peşəkar səviyyədə bilən proqramçıların sayını qeyd edin.

Technology Radar — ThoughtWorks metodudur, texnologiyaları 4 kvadranta ayırır: Adopt, Trial, Assess, Hold. Adopt — tövsiyə olunan stacklər, Trial — eksperimental, Assess — qiymətləndirmədə, Hold — istifadəsi tövsiyə edilmir. Nümunə: Flutter Adopt-də, React Native Hold-da — komandalar nə seçəcəyini bilir.

Dəstək xərci metrikası — hər stackın saxlanması üçün ayda nə qədər mühəndis saatı sərf olunduğunu qiymətləndirin. Stack 10% resursları istehlak edir, lakin modulların 2%-də istifadə olunursa — o, əvəz edilmək namizədidir. Stackın „layihələrin sayı” vs „dəstək mürəkkəbliyi” istilik xəritəsi problemli sahələri göstərir.

Texnoloji stack standartlaşdırma metodları

Architecture Decision Records (ADR) — texnologiya seçimini əsaslandıraraq memarlıq qərarlarının sənədləşdirilməsi. Hər ADR kontekst, nəzərdən keçirilmiş alternativlər və seçim lehinə arqumentlər ehtiva edir. Michael Nygard (2022) bu yanaşmanı populyarlaşdırdı və bu gün ADR texnoloji müxtəlifliyi idarə edən komandalar üçün standartdır.

Texnologiya İcmali Komitəsi — aparıcı proqramçılardan ibarət komissiya, layihədə yeni texnologiyaları təsdiqləyir. Qərar meyarlar əsasında qəbul edilir: mövcud stackla uyğunluq, icma dəstəyi, migrasiya dəyəri, istedadın əlçatanlığı. Spotify 2018-ci ildən bəri bənzər komitədən istifadə edir.

Yeni layihələr üçün qapı — qayda: hər yeni xidmət və ya modul yalnız təsdiqlənmiş stackdan istifadə edir. İstisnalar ADR vasitəsilə əsaslandırma ilə mümkündür. Nümunə: yeni mikroxidməti Kotlin-də yalnız komanda Java-nın bu tapşırıq üçün uyğun olmadığını sübut etdikdə yazmaq olar. Maneəsiz istənilən texnologiyalardan istifadə qadağandır.

Stack müxtəlifliyinin mərhələli azaldılması

Mərhələ 1: Dondurma — dəstəklənməyən stacklərdə yeni layihələr dayandırılır. Hold kvadrantındakı hər stack üçün son dəstək tarixi müəyyən edilir. Yeni funksionallıq yalnız təsdiqlənmiş stacklərdə yazılır. Legacy modullar işləməyə davam edir, lakin inkişaf etdirilmir.

Mərhələ 2: Konsolidasiya — hər tapşırıq üçün bir alət seçilir. Bir HTTP klienti, bir state menecer, bir verilənlər bazası. Alternativ stacklərdəki modullar prioritet üzrə migrasiya üçün planlaşdırılır. Strangler Fig pattern — sistemi dayandırmadan əvəz etmənin əsas metodudur.

Mərhələ 3: Migrasiya — hər sprintdə komanda köhnəlmiş stacklərdən təsdiqlənmişlərə kritik modulları yenidən yazmaq üçün 20% vaxt ayırır. Hədəf memarlıq sənəddə müəyyən edilir və komitənin qərarı olmadan dəyişdirilmir. Proses zooparkın miqyasından asılı olaraq 6 aydan 24 aya qədər davam edir.

Nümunə: HTTP kllientlərinin migrasiyası

// Əvvəl: 3 fərqli HTTP klienti bir layihədə
class HttpClientResolver {
    def resolve(moduleName) {
        switch(moduleName) {
            case "payments": return new OkHttpClient()
            case "chat": return new KtorClient()
            case "analytics": return new RetrofitClient()
        }
    }
}