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): كل 10 ميغابايت من حجم APK تقلل احتمالية التثبيت بنسبة 1.2%. الكود غير المستخدم ليس مجرد فوضى في المستودع — إنه خسارة مالية مباشرة. المكتبات الإضافية (لوظائف «ربما سنضيفها لاحقًا») هي المصدر الأكثر شيوعًا لتضخم APK.

وفقًا لـ Gradle Build Performance Report (2024)، كل وحدة إضافية في مشروع Android تزيد وقت البناء الكامل بمقدار 3–7 ثوانٍ. إذا أضفت 5 وحدات «احتياطًا» — ستكون الزيادة في وقت البناء 15–35 ثانية لكل بناء. خلال عام، يفقد فريق من 5 مطورين ما يصل إلى 200 ساعة عمل في انتظار الترجمة.

راقب حجم الملف الثنائي في CI: حدد حد تحذير (على سبيل المثال، +500 كيلوبايت لكل commit). إذا زاد الحجم بدون ميزة جديدة — فهذا انتهاك لـ YAGNI يجب مناقشته في مراجعة الكود.

YAGNI ضد التذهيب: أمثلة عملية

التذهيب: الرسوم المتحركة المبكرة

التذهيب (Gold-plating) — إضافة وظائف تتجاوز المتطلبات في محاولة «لتحسين» المنتج. مثال نموذجي: مطور يضيف رسومًا متحركة معقدة للانتقال بين الشاشات، على الرغم من أن التصميم يحدد fade بسيط. تستغرق الرسوم المتحركة يومين، المستخدم لا يلاحظها، والأخطاء على الأجهزة المختلفة تطارد المشروع لسنوات.

وفقًا لـ UX Collective Annual Report (2023)، 78% من المستخدمين يقيمون التطبيق بالسرعة والاستقرار، وليس بالرسوم المتحركة. YAGNI يقول: إذا لم تكن الرسوم المتحركة محددة في المتطلبات — لا تنفذها. سيضيف المصمم الرسوم المتحركة عندما تكون ضرورية بالفعل لحل مشكلة UX.

نفذ فقط ما هو موجود في التصاميم. إذا لم يرسم المصمم رسومًا متحركة — فلا يجب أن تكون موجودة. أي انحراف عن التصميم هو انتهاك لـ YAGNI.

التوطين المبكر إلى 20 لغة

خطأ شائع للشركات الناشئة: بناء دعم 20+ لغة فورًا «للدخول المستقبلي إلى السوق الدولية». YAGNI يوصي: قم بالتوطين فقط للغة السوق الحالية. إضافة كل لغة جديدة تتطلب وقت المترجمين، واختبار النصوص للاقتطاع، وتصحيح تخطيط RTL.

وفقًا لـ Deloitte Digital Globalization Survey (2022)، 60% من التطبيقات المحمولة لا تغادر سوقها الأول أبدًا. إذا كانت هذه حالتك — فإن الموارد المنفقة على الدعم متعدد اللغات تذهب سدى. نهج YAGNI: الإنجليزية (الأساسية) + لغة السوق المستهدف. الباقي — حسب الدخول الفعلي إلى المنطقة.

استخدم YAGNI لتحديد الأولويات: إذا كانت الميزة ليست في خارطة الطريق للربعين القادمين — لا تبدأها. يجب توثيق خارطة الطريق والموافقة عليها من قبل مدير المنتج.

كيف تطبق YAGNI في Android و iOS؟

YAGNI في Android: لا تضف مكتبات غير ضرورية

مشاريع 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 الأدنى)، أضف Retrofit عندما تحتاج إلى عميل REST، وهكذا.

YAGNI في iOS: لا تفرض SwiftUI

SwiftUI هو إطار عمل قوي، لكن تبنيه يجب أن يكون مدفوعًا باحتياجات حقيقية. إذا بدأ مشروع مع iOS 14+ ومتطلبات مكونات UI المخصصة ضئيلة — فإن SwiftUI خيار جيد. إذا كان المشروع يجب أن يدعم iOS 13 أو يتطلب إيماءات مخصصة معقدة — يبقى UIKit الحل الصحيح. YAGNI ضد الترحيل إلى SwiftUI «لأنه عصري».

// YAGNI: استخدم UIKit طالما لا توجد فائدة حقيقية من SwiftUI
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "الملف الشخصي"
    }
}

// إذا كان SwiftUI مطلوبًا — قم بدمجه عبر UIHostingController
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

تحليل Point-Free: «دليل قرار SwiftUI مقابل UIKit» (2024) يوصي: لا ترحل شاشات UIKit الموجودة إلى SwiftUI بدون سبب تجاري واضح (مثلاً، الحاجة إلى Live Preview للمصمم). إعادة كتابة كود يعمل هو انتهاك مباشر لـ YAGNI. SwiftUI — للشاشات الجديدة، UIKit — للموجودة.

الأخطاء النموذجية عند اتباع YAGNI

YAGNI كعذر لسوء الهندسة المعمارية

أخطر خطأ هو استخدام YAGNI كعذر لسوء الهندسة المعمارية. «لن ننشئ طبقة مستودع لأن YAGNI — سنكتب الاستعلام مباشرة في ViewModel». هذا ليس YAGNI، هذا تراكم للديون التقنية. YAGNI يمنع الوظائف غير الضرورية، وليس السلامة المعمارية.

الهندسة المعمارية هي استثمار في قابلية الصيانة. إذا كنت تكتب أكثر من 3 شاشات — فإن طبقة معمارية أساسية (MVVM، مستودع) مبررة بالفعل. إذا كانت شاشة واحدة — يمكنك تحمل نهج أبسط. المفتاح: حدد الحد الأدنى المعماري اللازم للوظائف الحالية، ولا تضف أكثر.

قسّم القرارات إلى «معمارية» و«وظيفية». القرارات المعمارية (الطبقات، التنقل، DI) لا تغطيها YAGNI — فهي ضرورية لقابلية الصيانة. القرارات الوظيفية (الميزات، لقطات الشاشة، الرسوم المتحركة) — تغطيها.

اتباع YAGNI بشكل أعمى عند العمل مع APIs

طرف آخر — تجاهل عقود API المستقبلية. مطور يتلقى JSON من الخادم بـ 5 حقول ويحلل 3 فقط، لأن «الباقي غير ضروري حسب YAGNI». المشكلة: عند إضافة حقل، قد يكسر الخادم التحليل إذا تغير الرد. الحل هو تعيين جميع حقول الرد، حتى لو لم تُستخدم جميعها الآن.

وفقًا لـ Meta API Design Guidelines (2023)، يجب على العميل تحليل جميع الحقول التي يعيدها الخادم، متجاهلاً غير المستخدمة، ولكن دون التخلص من الهيكل بأكمله. YAGNI هنا يتعلق بشيء آخر: لا تضف معالجة لحقول ليست موجودة بعد في المواصفات «احتياطًا في حال أعادها الخادم».

حلل هيكل الرد بالكامل (جميع الحقول التي يعيدها الخادم حاليًا). لا تضف معالجة لحقول ليست في مواصفات API الحالية. هذا توازن بين YAGNI والمرونة في مواجهة التغيير.