Ilova ishlab chiqishda YAGNI: bu nima, prinsipning mohiyati va amaliy foydasi

YAGNI nima?

YAGNI (You Aren't Gonna Need It) — ekstremal dasturlash (XP) prinsipi, “senga bu kerak bo‘lmaydi” degan ma’noni anglatadi. Qoida: hech qachon joriy foydalanuvchi hikoyalari talab qilmaydigan funksionallikni tatbiq etmang. Agar funksiya bugun kerak bo‘lmasa — uni “har ehtimolga qarshi” ham qilmang.

Atama Ron Jeffries tomonidan, XP metodologiyasining hammualliflaridan biri (Kent Bek bilan) kiritilgan. Jeffries: “Ishlaydigan eng oddiy narsani tatbiq qiling va ehtiyoj tug‘ilgunga qadar hech narsa qo‘shmang” deb ta’kidlagan. YAGNI — rejalashtirishni taqiqlash emas, balki erta tatbiq qilishni taqiqlashdir.

Standish Group CHAOS Report (2023) ma’lumotlariga ko‘ra, o‘rtacha dasturiy mahsulotdagi funksiyalarning 64% kamdan-kam yoki hech qachon ishlatilmaydi. Buni mobil ilovaga tatbiq etsak — yozilgan kodning yarmidan ko‘pi foydalanuvchiga qiymat bermaydi. YAGNI bu resurs isrofining oldini oladi.

YAGNI ni qattiq filtr sifatida qo‘llang: har bir funksiya “aniq bir foydalanuvchining qaysi muammosini aynan hozir hal qiladi?” degan savolga javob berishi kerak. Javob bo‘lmasa — funksiya kerak emas.

YAGNI ning dangasalik va burchaklarni kesishdan farqi

YAGNI — sifatli arxitekturadan voz kechish emas. YAGNI ortiqcha kod yozishni taqiqlaydi, lekin to‘g‘ri kod yozishni taqiqlamaydi. Agar joriy funksiya üçün toza abstraksiya qatlami kerak bo‘lsa — uni yarating. Agar qatlam kerak bo‘lmasa — yaratmang. Asosiy farq: YAGNI funksionallik haqida, sifat haqida emas.

Dasturchilar ko‘pincha YAGNI ni ataylab texnik qarz to‘plash bilan aralashtirib yuborishadi (texnik qarz har doim kompromisdir, YAGNI esa samaradorlik prinsipidir). Farq shundaki, texnik qarz ongli va hujjatlashtirilgan, YAGNI ni buzish esa shunchaki ortiqcha ishdir.

O‘zingizga savol bering: “Agar bu abstraksiyani hozir qilmasam, kerak bo‘lganda refaktoring qancha vaqt oladi?” Agar refaktoring vaqti hozir yozish vaqtidan kam bo‘lsa — keyinga qoldiring.

Nega YAGNI mobil loyihalar üçün muhim?

Mobil ilovalarni ishlab chiqish YAGNI ni buzishga ayniqsa uch sababdan sezgir: APK/IPA hajmi to‘g‘ridan-to‘g‘ri o‘rnatish konversiyasiga ta’sir qiladi, mobil loyihalarning kompilyatsiya vaqti kod hajmi bilan chiziqli o‘sadi va har bir ortiqcha funksiya nosozlik nuqtalarini qo‘shadi. YAGNI — dangasalik haqida emas, diqqat haqida.

Google Play Console Data (2023) har 10 MB APK hajmi o‘rnatish ehtimolini 1.2% ga kamaytirishini ko‘rsatdi. Foydalanilmaydigan kod — bu shunchaki repozitorijdagi axlat emas, bu to‘g‘ridan-to‘g‘ri moliyaviy yo‘qotishdir. Ortiqcha kutubxonalar (“balki keyin qo‘shamiz” degan funksionallik üçün) — APK ning shishishining eng keng tarqalgan manbai.

Gradle Build Performance Report (2024), Android loyihasidagi har bir qo‘shimcha modul to‘liq qurish vaqtini 3–7 soniyaga oshiradi. 5 modulni “kelajak üçün” qo‘shsangiz — har bir buildda kompilyatsiya vaqti 15–35 soniyaga oshadi. Bir yil davomida 5 dasturchidan iborat jamoa kompilyatsiyani kutish üçün 200 kishi-soatgacha yo‘qotadi.

CI da binar fayl hajmini kuzatib boring: ogohlantirish chegarasini o‘rnating (masalan, har bir commit üçün +500 KB). Agar hajm yangi funksiyasiz oshgan bo‘lsa — bu YAGNI buzilishi bo‘lib, code review da muhokama qilinishi kerak.

YAGNI gold-plating ga qarshi: amaliy misollar

Gold-plating: erta animatsiya

Gold-plating — mahsulotni “yaxshilash” urinishida talablardan ortiq funksionallik qo‘shish. Oddiy misol: dizaynda oddiy fade ko‘rsatilgan bo‘lsa-da, dasturchi ekranlar o‘rtasida murakkab o‘tish animatsiyasini qo‘shadi. Animatsiya 2 kun oladi, foydalanuvchi buni sezmaydi va turli qurilmalardagi xatolar loyihani yillar davomida ta’qib qiladi.

UX Collective Annual Report (2023) foydalanuvchilarning 78% ilovani tezlik va barqarorlik bo‘yicha baholaydi, animatsiyalar bo‘yicha emas. YAGNI aytadi: agar animatsiya talablarda belgilanmagan bo‘lsa — uni tatbiq etmang. Dizayner UX muammosini hal qilish üçün haqiqatan kerak bo‘lganda animatsiya qo‘shadi.

Faqat maketlarda bo‘lgan narsani tatbiq qiling. Agar dizayner animatsiyani chizmagan bo‘lsa — demak u bo‘lmasligi kerak. Maketdan har qanday chetlashish YAGNI buzilishidir.

20 tilga erta lokalizatsiya

Startaplarning keng tarqalgan xatosi: “kelajakda xalqaro bozorga chiqish üçün” darhol 20+ tilni qo‘llab-quvvatlashni qo‘shish. YAGNI tavsiya qiladi: faqat joriy bozor tilida lokalizatsiya qiling. Har bir yangi til tarjimonlar vaqti, satrlarni kesish testi va RTL tartibini sozlashni talab qiladi.

Deloitte Digital Globalization Survey (2022) mobil ilovalarning 60% hech qachon birinchi bozordan tashqariga chiqmasligini ko‘rsatdi. Agar bu sizning holatingiz bo‘lsa — ko‘p tillilikka sarflangan resurslar behuda ketgan. YAGNI yondashuvi: ingliz (asosiy) + maqsadli bozor tili. Qolganlari — mintaqaga real chiqish bilan.

Prioritetlashtirish üçün YAGNI dan foydalaning: agar funksiya kelgusi ikki kvartal roadmapsida bo‘lmasa — boshlamang. Roadmap hujjatlashtirilgan holda product manager tomonidan tasdiqlanishi kerak.

Android va iOS da YAGNI ni qanday qo‘llash kerak?

Android da YAGNI: ortiqcha kutubxonalar qo‘shmang

Android loyihalari kutubxona inflyatsiyasidan aziyat chekadi. Dasturchilar birinchi biznes-mantiq satri yozilmasdanoq Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore ni ulaydilar. YAGNI tavsiya qiladi: kutubxonalarni profilaktik emas, real ehtiyoj tug‘ilganda ulang.

// YAGNI buzilishi: kutubxonalarning profilaktik ulanishi
// 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")

// Ilova esa hozircha faqat "Hello World" ko'rsatadi

Kutubxonalar – o‘z murakkabligiga ega bog‘liqliklardir. Har biri versiya yangilanishi, breaking changes da migratsiya va APK hajmini oshirishni talab qiladi. Kutubxonani o‘sha kutubxona hal qiladigan aniq vazifa paydo bo‘lganda ulang. OkHttp dan boshlang (minimal HTTP kliyent), REST kliyent kerak bo‘lganda Retrofit ni qo‘shing va h.k.

iOS da YAGNI: SwiftUI ni majburlamang

SwiftUI — kuchli freymvork, lekin uni joriy etish real ehtiyojlar bilan asoslanishi kerak. Loyiha iOS 14+ bilan boshlansa va maxsus UI komponentlariga talablar minimal bo‘lsa — SwiftUI yaxshi tanlov. Loyiha iOS 13 ni qo‘llab-quvvatlashi yoki murakkab maxsus jestlarni talab qilsa — UIKit to‘g‘ri yechim bo‘lib qoladi. YAGNI “moda bo‘lgani üçün” SwiftUI ga migratsiyaga qarshi.

// YAGNI: SwiftUI dan real foyda bo'lmaguncha UIKit dan foydalaning
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Profil"
    }
}

// Agar SwiftUI kerak bo'lsa — UIHostingController orqali joriy qiling
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Point-Free: “SwiftUI vs UIKit Decision Guide” (2024) mavjud UIKit ekranlarini aniq biznes sababisiz SwiftUI ga o‘tkazmang (masalan, dizayner üçün Live Preview zaruriyati). Ishlaydigan kodni qayta yozish — to‘g‘ridan-to‘g‘ri YAGNI buzilishi. SwiftUI — yangi ekranlar üçün, UIKit — mavjudlari üçün.

YAGNI ga amal qilishdagi odatiy xatolar

YAGNI ni yomon arxitektura üçün bahona sifatida ishlatish

Eng xavfli xato — YAGNI ni yomon arxitektura üçün bahona sifatida ishlatish. “Repozitoriya qatlamini ajratmaymiz, chunki YAGNI — so‘rovni to‘g‘ridan-to‘g‘ri ViewModel da yozamiz”. Bu YAGNI emas, texnik qarz to‘plashdir. YAGNI ortiqcha funksionallikni taqiqlaydi, arxitektura yaxlitligini emas.

Arxitektura — barqarorlikka investitsiya. Agar 3 ekrandan ko‘p yozsangiz — asosiy arxitektura qatlami (MVVM, repozitoriya) allaqachon asoslangan. Agar 1 ekran bo‘lsa — oddiy yondashuv bilan kifoyalanish mumkin. Kalit: joriy funksiyalar üçün zarur arxitektura minimumini aniqlang va ko‘proq qo‘shmang.

Qarorlarni “arxitektura” va “funksional” ga ajrating. Arxitektura qarorlari (qatlamlar, navigatsiya, DI) YAGNI bilan qamrab olinmaydi — ular barqarorlik üçün kerak. Funksional qarorlar (funksiyalar, ekran tasvirlari, animatsiyalar) — qamrab olinadi.

API bilan ishlashda YAGNI ga ko‘r-ko‘rona amal qilish

Boshqa ekstremal — kelajakdagi API shartnomalarini e’tiborsiz qoldirish. Dasturchi backend dan 5 maydonli JSON oladi va faqat 3 tasini tahlil qiladi, chunki “qolganlari YAGNI bo‘yicha kerak emas”. Muammo: maydon qo‘shilganda, backend javobni o‘zgartirsa, tahlil qilish buzilishi mumkin. Yechim — barcha javob maydonlarini xaritalash, hatto hammasi hozir ishlatilmasa ham.

Meta API Design Guidelines (2023) ga ko‘ra, kliyent server qaytaradigan barcha maydonlarni tahlil qilishi, foydalanilmaydiganlarini e’tiborsiz qoldirishi, lekin butun strukturani tashlab yubormasligi kerak. YAGNI bu yerda boshqa narsa haqida: spetsifikatsiyada hali bo‘lmagan maydonlarni qayta ishlashni qo‘shish shart emas, “agar backend ularni qaytarsa”.

Javobning butun strukturasini tahlil qiling (server hozir qaytaradigan barcha maydonlar). Joriy API spetsifikatsiyasida bo‘lmagan maydonlarni qayta ishlashni qo‘shmang. Bu YAGNI va o‘zgarishlarga chidamlilik o‘rtasidagi muvozanatdir.