ایپ ڈویلپمنٹ میں YAGNI: یہ کیا ہے، اصول کا جوہر اور عملی فائدہ

YAGNI کیا ہے؟

YAGNI (You Aren't Gonna Need It) — ایکسٹریم پروگرامنگ (XP) کا اصول جس کا مطلب ہے “آپ کو اس کی ضرورت نہیں پڑے گی”۔ قاعدہ کہتا ہے: موجودہ صارف کی کہانیوں کے ذریعے مطلوب نہ ہونے والی فعالیت کبھی لاگو نہ کریں۔ اگر کوئی خصوصیت آج ضروری نہیں ہے — تو اسے مت بنائیں، “ہو سکتا ہے کام آئے” کے طور پر بھی نہیں۔

یہ اصطلاح رون جیفریز نے وضع کی، جو XP طریقہ کار کے شریک مصنفین میں سے ایک ہیں (کینٹ بیک کے ساتھ)۔ جیفریز نے کہا: “سب سے آسان چیز لاگو کریں جو کام کرتی ہے، اور جب تک ضرورت نہ ہو کچھ شامل نہ کریں”۔ YAGNI منصوبہ بندی کی ممانعت نہیں، بلکہ قبل از وقت عمل‌آوری کی ممانعت ہے۔

Standish Group CHAOS Report (2023) کے مطابق، اوسط سافٹ ویئر پروڈکٹ میں 64% خصوصیات شاذ و نادر ہی استعمال ہوتی ہیں یا کبھی استعمال نہیں ہوتیں۔ موبائل ایپ پر لاگو کریں — لکھے گئے کوڈ کا آدھے سے زیادہ صارف کو قدر نہیں پہنچاتا۔ YAGNI وسائل کے اس ضیاع کو روکتا ہے۔

YAGNI کو ایک سخت فلٹر کے طور پر لاگو کریں: ہر خصوصیت کو سوال کا جواب دینا چاہیے “یہ ابھی کس مخصوص صارف کے مسئلے کو حل کرتی ہے؟” اگر کوئی جواب نہیں — تو خصوصیت ضروری نہیں ہے۔

YAGNI اور کاہلی یا شارٹ کٹ میں فرق

YAGNI معیاری فن تعمیر کو مسترد کرنا نہیں ہے۔ YAGNI غیر ضروری کوڈ لکھنے سے منع کرتا ہے، لیکن صحیح کوڈ لکھنے سے منع نہیں کرتا۔ اگر موجودہ خصوصیت کو صاف تجریدی پرت کی ضرورت ہے — تو اسے بنائیں۔ اگر پرت ضروری نہیں ہے — تو اسے نہ بنائیں۔ کلیدی فرق: YAGNI فعالیت کے بارے میں ہے، معیار کے بارے میں نہیں۔

ڈویلپرز اکثر YAGNI کو جان بوجھ کر تکنیکی قرض جمع کرنے کے ساتھ الجھاتے ہیں (تکنیکی قرض ہمیشہ ایک سمجھوتہ ہوتا ہے، YAGNI کارکردگی کا اصول ہے)۔ فرق یہ ہے کہ تکنیکی قرض کو تسلیم اور دستاویزی کیا جاتا ہے، جبکہ YAGNI کی خلاف ورزی محض اضافی کام ہے۔

خود سے پوچھیں: “اگر میں یہ تجرید ابھی نہیں بناتا، تو جب ضرورت ہوگی تو ریفیکٹرنگ میں کتنا وقت لگے گا؟” اگر ریفیکٹرنگ کا وقت ابھی لکھنے کے وقت سے کم ہے — تو اسے ملتوی کریں۔

موبائل پروجیکٹس کے لیے YAGNI کیوں اہم ہے؟

موبائل ڈویلپمنٹ تین وجوہات کی بنا پر YAGNI کی خلاف ورزیوں کے لیے خاص طور پر حساس ہے: APK/IPA کا سائز براہ راست انسٹالیشن کی تبدیلی کی شرح کو متاثر کرتا ہے، موبائل پروجیکٹس کا کمپائلیشن وقت کوڈ کے حجم کے ساتھ خطی طور پر بڑھتا ہے، اور ہر اضافی خصوصیت ناکامی کے نکات شامل کرتی ہے۔ YAGNI کاہلی کے بارے میں نہیں، بلکہ توجہ مرکوز کرنے کے بارے میں ہے۔

Google Play Console Data (2023) کے ایک مطالعہ نے دکھایا: APK سائز کا ہر 10 MB انسٹالیشن کے امکان کو 1.2% کم کرتا ہے۔ غیر استعمال شدہ کوڈ صرف ریپوزٹری میں کوڑا نہیں ہے — یہ براہ راست مالی نقصان ہے۔ “شاید بعد میں شامل کریں” والی فعالیت کے لیے اضافی لائبریریاں APK کے پھولنے کی سب سے عام وجہ ہیں۔

Gradle Build Performance Report (2024) کے مطابق، Android پروجیکٹ میں ہر اضافی ماڈیول مکمل بلڈ ٹائم کو 3–7 سیکنڈ بڑھاتا ہے۔ اگر آپ “ہو سکتا ہے ضرورت پڑے” کے طور پر 5 ماڈیول شامل کرتے ہیں — تو بلڈ ٹائم میں اضافہ فی بلڈ 15–35 سیکنڈ ہوگا۔ ایک سال میں، 5 ڈویلپرز کی ٹیم کمپائلیشن کے انتظار میں 200 گھنٹے تک کھو دیتی ہے۔

CI میں بائنری سائز کی نگرانی کریں: ایک انتباہی حد مقرر کریں (مثال کے طور پر، فی کمٹ +500 KB)۔ اگر نئی خصوصیت کے بغیر سائز بڑھ گیا — تو یہ YAGNI کی خلاف ورزی ہے جس پر کوڈ ریویو میں بات کی جانی چاہیے۔

YAGNI بمقابلہ گولڈ پلیٹنگ: عملی مثالیں

گولڈ پلیٹنگ: قبل از وقت اینیمیشن

گولڈ پلیٹنگ — مصنوعات کو “بہتر” بنانے کی کوشش میں ضروریات سے زیادہ فعالیت شامل کرنا۔ ایک عام مثال: ڈویلپر اسکرینوں کے درمیان پیچیدہ ٹرانزیشن اینیمیشن شامل کرتا ہے، حالانکہ ڈیزائن میں ایک سادہ fade بتایا گیا ہے۔ اینیمیشن میں 2 دن لگتے ہیں، صارف اسے محسوس نہیں کرتا، اور مختلف آلات پر بگز سالوں تک پروجیکٹ کا پیچھا کرتے ہیں۔

UX Collective Annual Report (2023) کے مطابق، 78% صارفین کسی ایپ کا اندازہ اینیمیشنز سے نہیں، بلکہ رفتار اور استحکام سے کرتے ہیں۔ YAGNI کہتا ہے: اگر اینیمیشن ضروریات میں متعین نہیں ہے — تو اسے لاگو نہ کریں۔ ڈیزائنر اینیمیشن اس وقت شامل کرے گا جب واقعی کسی UX مسئلے کو حل کرنے کے لیے ضروری ہو۔

صرف وہی لاگو کریں جو موک اپس میں ہے۔ اگر ڈیزائنر نے اینیمیشن نہیں بنائی — تو اسے موجود نہیں ہونا چاہیے۔ موک اپ سے کوئی بھی انحراف YAGNI کی خلاف ورزی ہے۔

20 زبانوں میں قبل از وقت لوکلائزیشن

اسٹارٹ اپس کی ایک عام غلطی: “مستقبل میں بین الاقوامی مارکیٹ میں داخلے کے لیے” فوری طور پر 20+ زبانوں کی معاونت بنانا۔ YAGNI سفارش کرتا ہے: صرف موجودہ مارکیٹ کی زبان میں لوکلائز کریں۔ ہر نئی زبان شامل کرنے میں مترجمین کا وقت، سٹرنگ کٹنے کی جانچ اور RTL لے آؤٹ ڈیبگنگ درکار ہوتی ہے۔

Deloitte Digital Globalization Survey (2022) کے مطابق، 60% موبائل ایپس کبھی اپنی پہلی مارکیٹ سے باہر نہیں جاتیں۔ اگر یہ آپ کا معاملہ ہے — تو کثیر لسانی معاونت پر خرچ کردہ وسائل ضائع ہیں۔ YAGNI نقطہ نظر: انگریزی (بنیادی) + ہدف مارکیٹ کی زبان۔ باقی — جب حقیقت میں کسی علاقے میں داخل ہوں۔

ترجیح دینے کے لیے YAGNI استعمال کریں: اگر کوئی خصوصیت اگلے دو سہ ماہیوں کے روڈ میپ میں نہیں ہے — تو اسے شروع نہ کریں۔ روڈ میپ کو دستاویزی شکل میں ہونا چاہیے اور پروڈکٹ مینیجر کے ذریعے منظور شدہ ہونا چاہیے۔

Android اور iOS میں YAGNI کیسے لاگو کریں؟

Android میں YAGNI: غیر ضروری لائبریریاں شامل نہ کریں

Android پروجیکٹس لائبریری افراط زر کا شکار ہیں۔ ڈویلپرز کاروباری منطق کی پہلی لائن لکھنے سے پہلے بھی Retrofit، OkHttp، Gson، Room، Dagger Hilt، Navigation Component، DataStore شامل کرتے ہیں۔ YAGNI سفارش کرتا ہے: لائبریریاں حقیقی ضرورت کے مطابق شامل کریں، احتیاطی طور پر نہیں۔

// YAGNI کی خلاف ورزی: لائبریریوں کا احتیاطی شامل کرنا
// 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")

// اور ایپ ابھی صرف "Hello World" دکھاتی ہے

لائبریریاں اپنی پیچیدگی کے ساتھ انحصار ہیں۔ ہر ایک کو ورژن اپ ڈیٹ، بریکنگ چینجز پر منتقلی کی ضرورت ہوتی ہے اور APK سائز بڑھاتی ہے۔ شامل کریں ایک لائبریری جب کوئی مخصوص کام پیدا ہو جو وہ لائبریری حل کرتی ہے۔ OkHttp (کم سے کم HTTP کلائنٹ) سے شروع کریں، جب REST کلائنٹ کی ضرورت ہو تو Retrofit شامل کریں، اور اسی طرح جاری رکھیں۔

iOS میں YAGNI: SwiftUI کو زبردستی نہ لگائیں

SwiftUI ایک طاقتور فریم ورک ہے، لیکن اسے اپنانا حقیقی ضروریات سے چلنا چاہیے۔ اگر کوئی پروجیکٹ iOS 14+ سے شروع ہوتا ہے اور کسٹم UI اجزاء کی ضروریات کم سے کم ہیں — تو SwiftUI ایک اچھا انتخاب ہے۔ اگر کسی پروجیکٹ کو iOS 13 سپورٹ کرنا ہے یا پیچیدہ کسٹم جیسچرز کی ضرورت ہے — تو UIKit صحیح حل رہتا ہے۔ YAGNI “کیونکہ یہ ٹرینڈی ہے” کی بنیاد پر SwiftUI میں منتقلی کے خلاف ہے۔

// YAGNI: SwiftUI سے حقیقی فائدہ نہ ہونے تک UIKit استعمال کریں
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "پروفائل"
    }
}

// اگر SwiftUI کی ضرورت ہو — UIHostingController کے ذریعے مربوط کریں
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Point-Free: “SwiftUI vs UIKit Decision Guide” (2024) کا تجزیہ سفارش کرتا ہے: واضح کاروباری وجہ (مثال کے طور پر، ڈیزائنر کے لیے لائیو پیش نظارہ کی ضرورت) کے بغیر موجودہ UIKit اسکرینوں کو SwiftUI میں منتقل نہ کریں۔ کام کرنے والے کوڈ کو دوبارہ لکھنا YAGNI کی براہ راست خلاف ورزی ہے۔ SwiftUI — نئی اسکرینوں کے لیے، UIKit — موجودہ کے لیے۔

YAGNI پر عمل کرتے وقت عام غلطیاں

YAGNI خراب فن تعمیر کے بہانے کے طور پر

سب سے خطرناک غلطی خراب فن تعمیر کے بہانے YAGNI کا استعمال کرنا ہے۔ “ہم ریپوزٹری پرت نہیں بنائیں گے کیونکہ YAGNI — ہم براہ راست ViewModel میں کوئری لکھیں گے”۔ یہ YAGNI نہیں ہے، یہ تکنیکی قرض جمع کرنا ہے۔ YAGNI غیر ضروری فعالیت کو روکتا ہے، فن تعمیراتی سالمیت کو نہیں۔

فن تعمیر برقرار رکھنے کی صلاحیت میں ایک سرمایہ کاری ہے۔ اگر آپ 3 سے زیادہ اسکرینیں لکھ رہے ہیں — تو ایک بنیادی فن تعمیراتی پرت (MVVM، ریپوزٹری) پہلے ہی جائز ہے۔ اگر 1 اسکرین ہے — تو آپ ایک آسان طریقہ اپنا سکتے ہیں۔ کنجی: موجودہ خصوصیات کے لیے ضروری فن تعمیراتی کم از کم کا تعین کریں، اور مزید شامل نہ کریں۔

فیصلوں کو “فن تعمیراتی” اور “عملی” میں تقسیم کریں۔ فن تعمیراتی فیصلے (پرت، نیویگیشن، DI) YAGNI کے تحت نہیں آتے — یہ برقرار رکھنے کی صلاحیت کے لیے ضروری ہیں۔ عملی فیصلے (خصوصیات، اسکرین شاٹس، اینیمیشنز) — آتے ہیں۔

API کے ساتھ کام کرتے وقت YAGNI کی آنکھ بند کرکے پیروی

دوسری انتہا — مستقبل کے API معاہدوں کو نظر انداز کرنا۔ ایک ڈویلپر کو بیک اینڈ سے 5 فیلڈز کے ساتھ JSON ملتا ہے اور “باقی YAGNI کے مطابق ضروری نہیں ہیں” کہہ کر صرف 3 کو پارس کرتا ہے۔ مسئلہ: جب کوئی فیلڈ شامل کیا جاتا ہے، اگر جواب تبدیل ہوا تو بیک اینڈ پارسنگ توڑ سکتا ہے۔ حل یہ ہے کہ تمام جوابی فیلڈز کو میپ کیا جائے، چاہے سب ابھی استعمال نہ ہوں۔

Meta API Design Guidelines (2023) کے مطابق، کلائنٹ کو سرور کے ذریعے لوٹائے گئے تمام فیلڈز کو پارس کرنا چاہیے، غیر استعمال شدہ کو نظر انداز کرتے ہوئے، لیکن پوری ساخت کو ضائع نہیں کرنا چاہیے۔ YAGNI یہاں کسی اور چیز کے بارے میں ہے: “ہو سکتا ہے بیک اینڈ انہیں لوٹائے” کے طور پر ان فیلڈز کی ہینڈلنگ شامل نہ کریں جو ابھی تک تصریح میں نہیں ہیں۔

پورے جوابی ڈھانچے کو پارس کریں (وہ تمام فیلڈز جو سرور فی الحال لوٹاتا ہے)۔ موجودہ API تصریح میں نہ ہونے والے فیلڈز کی ہینڈلنگ شامل نہ کریں۔ یہ YAGNI اور تبدیلی کے خلاف لچک کے درمیان ایک توازن ہے۔