Tətbiq inkişafında YAGNI: bu nədir, prinsipin mahiyyəti və praktik faydası

YAGNI nədir?

YAGNI (You Aren't Gonna Need It) — ekstremal proqramlaşdırma (XP) prinsipi olub “sənə bu lazım olmayacaq” mənasını verir. Qayda deyir: heç vaxt cari istifadəçi hekayələri tərəfindən tələb olunmayan funksionallığı tətbiq etməyin. Əgər funksiya bu gün lazım deyilsə — onu “hər ehtimala qarşı” belə etməyin.

Termin Ron Jeffries tərəfindən, XP metodologiyasının həmmüəlliflərindən biri (Kent Bek ilə) tərəfindən təqdim edilmişdir. Jeffries iddia edirdi: “İşləyən ən sadə şeyi həyata keçirin və ehtiyac olana qədər heç nə əlavə etməyin”. YAGNI — bu planlaşdırma qadağası deyil, vaxtından əvvəl tətbiqetmə qadağasıdır.

Standish Group CHAOS Report (2023) məlumatlarına görə, orta statistik proqram məhsulunda funksiyaların 64%-ı nadir hallarda və ya heç istifadə edilmir. Bunu mobil tətbiqə şərh etsək — yazılan kodun yarısından çoxu istifadəçiyə dəyər vermir. YAGNI bu resurs itkisinin qarşısını alır.

YAGNI-ni ciddi filtr kimi tətbiq edin: hər bir funksiya “bir konkret istifadəçinin hansı problemini elə indi həll edir?” sualına cavab verməlidir. Cavab yoxdursa — funksiya lazım deyil.

YAGNI-nin tənbəllikdən və küncləri kəsməkdən fərqi

YAGNI — keyfiyyətli arxitekturadan imtina deyil. YAGNI əlavə kod yazmağı qadağan edir, lakin düzgün kod yazmağı qadağan etmir. Əgər cari funksiya üçün təmiz abstraksiya qatı lazımdırsa — onu yaradın. Qat lazım deyilsə — yaratmayın. Əsas fərq: YAGNI funksionallıqla bağlıdır, keyfiyyətlə yox.

Proqramçılar tez-tez YAGNI-ni şürurlı texniki borc yığılması ilə qarışdırırlar (texniki borc həmişə kompromisdir, YAGNI isə səmərəlilik prinsipidir). Fərq ondadır ki, texniki borc şürurlı və sənədləşdirilmişdir, YAGNI-nin pozulması isə sadəcə əlavə işdir.

Özünüzə sual verin: “Əgər bu abstraksiyanı indi etməsəm, lazım olanda refaktoring nə qədər vaxt aparacaq?” Əgər refaktoring vaxtı indi yazmaq vaxtından azdırsa — təxirə salın.

Nə üçün YAGNI mobil layihələr üçün kritikdir?

Mobil tətbiq inkişafı YAGNI-nin pozulmasına üç səbəbdən xüsusilə həssasdır: APK/IPA ölçüsü birbaşa quraşdırma konversiyasına təsir edir, mobil layihələrin kompilyasiya müddəti kod həcmi ilə xətti artır və hər əlavə funksiya nasazlıq nöqtələri əlavə edir. YAGNI — tənbəllik yox, diqqət mərkəzidir.

Google Play Console Data (2023) tədqiqatı göstərdi: hər 10 MB APK ölçüsü quraşdırma ehtimalını 1.2% azaldır. İstifadə olunmayan kod ancaq depoda zibil deyil, bu birbaşa maliyyə itkisidir. Əlavə kitabxanalar (bəlkə sonra əlavə edərik deyə funksionallıq üçün) — APK-nın şişməsinin ən geniş yayılmış mənbəyidir.

Gradle Build Performance Report (2024)-ə görə, Android layihəsində hər əlavə modul tam qurma müddətini 3–7 saniyə artırır. 5 modulu “gələcək üçün” əlavə etsəniz — hər qurmada 15–35 saniyə əlavə vaxt olacaq. İl ərzində 5 proqramçıdan ibarət komanda kompilyasiyanı gözləmək üçün 200 adam-saat itirir.

CI-da binar fayl ölçüsünü izləyin: xəbərdarlıq limiti təyin edin (məs. commit başına +500 KB). Əgər ölçü yeni funksiya olmadan artıbsa — bu YAGNI pozuntusudur və code review-də müzakirə edilməlidir.

YAGNI gold-plating-ə qarşı: praktik nümunələr

Gold-plating: vaxtından əvvəl animasiya

Gold-plating — məhsulu “yaxşılaşdırmaq” cəhdi ilə tələblərdən artıq funksionallıq əlavə etməkdir. Tipik nümunə: dizaynda sadə fade göstərilsə də, proqramçı ekranlar arasında mürəkkəb keçid animasiyası əlavə edir. Animasiyaya 2 gün sərf olunur, istifadəçi onu görmür, müxtəlif cihazlardakı səhvlər isə layihəni illərlə təqib edir.

UX Collective Annual Report (2023) məlumatlarına görə, istifadəçilərin 78%-ı tətbiqi sürət və sabitliyə görə qiymətləndirir, animasiyalara görə yox. YAGNI deyir: əgər animasiya tələblərdə göstərilməyibsə — onu tətbiq etməyin. Dizayner UX problemini həll etmək üçün həqiqətən lazım olanda animasiya əlavə edəcək.

Yalnız maketlərdə olanı tətbiq edin. Əgər dizayner animasiya çəkməyibsə — deməli, olmamalıdır. Maketdən hər bir sapma YAGNI pozuntusudur.

20 dilə vaxtından əvvəl lokallaşdırma

Startapların tez-tez etdiyi səhv: “gələcəkdə beynəlxalq bazara çıxmaq üçün” dərhal 20+ dil dəstəyi qoymaq. YAGNI tövsiyə edir: yalnız cari bazarın dilində lokallaşdırın. Hər yeni dil tərcüməçilərin vaxtını, sətrlərin kəsilmə testini və RTL düzünün sazlanmasını tələb edir.

Deloitte Digital Globalization Survey (2022) tədqiqatı göstərdi: mobil tətbiqlərin 60%-ı heç vaxt ilk bazarın hüdudlarını aşmır. Əgər bu sizin halınızdırsa — çoxdilliliyə sərf olunan resurslar boş çıxıb. YAGNI yanaşması: ingilis (əsas) + hədəf bazarın dili. Qalanları — regiona real çıxış olduqca.

Prioritetləşdirmə üçün YAGNI-dən istifadə edin: əgər funksiya qarşıdakı iki rüblükdə roadmap-də yoxdursa — başlamayın. Roadmap sənədli şəkildə product menecer tərəfindən təsdiqlənməlidir.

Android və iOS-da YAGNI necə tətbiq edilməli?

Android-də YAGNI: əlavə kitabxanalar əlavə etməyin

Android layihələri kitabxana inflyasiyasından əziyyət çəkir. Proqramçılar ilk biznes məntiq sətri yazılmamış Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore — hamısını qoşurlar. YAGNI tövsiyə edir: kitabxanaları qabaqlayıcı yox, real ehtiyac olduqca qoşun.

// YAGNI-nin pozulması: kitabxanaların qabaqlayıcı qoşulması
// build.gradle (module)
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("androidx.room:room-runtime:2.6.0")

// Tətbiq isə hələlik sadəcə "Hello World" göstərir

Kitabxanalar öz mürəkkəbliyi olan asılılıqlardır. Hər biri versiya yenilənməsi, breaking changes zamanı miqrasiya və APK ölçüsünün artmasını tələb edir. Kitabxananı o vaxt qoşun ki, həmin kitabxana ilə həll edilən konkret tapşırıq yaranıb. OkHttp ilə başlayın (minimal HTTP kliyent), REST kliyent lazım olanda Retrofit əlavə edin və s.

iOS-da YAGNI: SwiftUI-ni məcbur etməyin

SwiftUI — güclü freymvorkdur, lakin onun tətbiqi real ehtiyaclarla əsaslandırılmalıdır. Layihə iOS 14+ ilə başlayırsa və xüsusi UI komponentlərinə tələblər minimaldırsa — SwiftUI yaxşı seçimdir. Layihə iOS 13-ü dəstəkləməli və ya mürəkkəb xüsusi jestlər tələb edirsə — UIKit düzgün həll yolu olaraq qalır. YAGNI “moda olduğu üçün” SwiftUI-yə miqrasiyanın əleyhinədir.

// YAGNI: SwiftUI-dən real fayda olmayana qədər UIKit istifadə edin
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Profil"
    }
}

// SwiftUI lazımdırsa — UIHostingController vasitəsilə tətbiq edin
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Point-Free: “SwiftUI vs UIKit Decision Guide” (2024) təhlili tövsiyə edir: mövcud UIKit ekranlarını aydın biznes səbəbi olmadan SwiftUI-yə keçirməyin (məs. dizayner üçün Live Preview ehtiyacı). İşləyən kodu yenidən yazmaq birbaşa YAGNI pozuntusudur. SwiftUI — yeni ekranlar üçün, UIKit — mövcudlar üçün.

YAGNI-yə əməl edərkən tipik səhvlər

YAGNI-nin pis arxitektura üçün bəhanə kimi istifadəsi

Ən təhlükəli səhv — YAGNI-dən pis arxitektura üçün bəhanə kimi istifadə etmək. “Repozitoriya qatını ayırmayacağıq, çünki YAGNI — sorğunu birbaşa ViewModel-də yazacağıq”. Bu YAGNI deyil, texniki borc yığılmasıdır. YAGNI əlavə funksionallığı qadağan edir, arxitektura bütövlüyünü yox.

Arxitektura davamlılığa investisiyadır. 3 ekrandan çox yazırsınızsa — əsas arxitektura qatı (MVVM, repozitoriya) artıq əsaslandırılıb. 1 ekrandırsa — sadə yanaşma ilə kifayətlənə bilərsiniz. Açar: cari funksiyalar üçün zəruri arxitektura minimumunu müəyyən edin və daha çox əlavə etməyin.

Qərarları “arxitektura” və “funksional” olaraq ayırın. Arxitektura qərarları (qatlar, naviqasiya, DI) YAGNI çərçivəsində deyil — onlar davamlılıq üçün lazımdır. Funksional qərarlar (xüsusiyyətlər, ekran görüntüləri, animasiyalar) — çərçivəyə daxildir.

API ilə işləyərkən YAGNI-yə kor-koranə əməl etmək

Digər ifrat — gələcək API kontraktlarına məhəl qoymamaq. Proqramçı backend-dən 5 sahəli JSON alır və yalnız 3-nü pars edir, çünki “qalanları YAGNI-yə görə lazım deyil”. Problem: sahə əlavə edildikdə backend cavab dəyişərsə, pars pozula bilər. Həll — bütün cavab sahələrinin xəritələnməsi, hətta hamısı indi istifadə edilməsə belə.

Meta API Design Guidelines (2023)-ə görə, kliyent serverin qaytardığı bütün sahələri pars etməli, istifadə olunmayanları görməməzliyə gəlməli, lakin bütün strukturu atmamalıdır. YAGNI burada başqa şeyə aiddir: spesifikasiyada olmayan sahələrin işlənməsini əlavə etmək lazım deyil “bəlkə backend onları qaytarsa”.

Cavabın bütün strukturunu pars edin (serverin indi qaytardığı bütün sahələr). Cari API spesifikasiyasında olmayan sahələrin işlənməsini əlavə etməyin. Bu, YAGNI ilə dəyişikliklərə davamlılıq arasında tarazlıqdır.