YAGNI در توسعه اپلیکیشن: چیست، ماهیت اصل و فایده عملی

YAGNI چیست؟

YAGNI (You Aren't Gonna Need It) — اصلی از برنامهنویسی افراطی (XP) به معنای «به آن نیاز نخواهید داشت». این قانون میگوید: هرگز قابلیتی را که در داستانهای کاربری فعلی لازم نیست پیادهسازی نکنید. اگر قابلیت امروز لازم نیست — حتی «برای احتیاط» هم آن را نسازید.

این اصطلاح توسط ران جفریز، یکی از همکاران متدولوژی XP (همراه با کنت بک)، معرفی شد. جفریز میگفت: «سادهترین چیزی را پیادهسازی کنید که کار میکند و تا زمانی که لازم نشده چیزی اضافه نکنید». YAGNI منع برنامهریزی نیست، بلکه منع پیادهسازی زودهنگام است.

بر اساس گزارش CHAOS بنیاد Standish (2023)، ۶۴٪ از قابلیتهای یک محصول نرمافزاری متوسط به ندرت استفاده میشوند یا هرگز. اگر این را روی یک اپلیکیشن موبایل تعمیم دهیم — بیش از نیمی از کد نوشتهشده ارزشی برای کاربر ایجاد نمیکند. YAGNI از این اتلاف منابع جلوگیری میکند.

YAGNI را بهعنوان یک فیلتر سختگیرانه به کار بگیرید: هر قابلیت باید به این سؤال پاسخ دهد «همین حالا چه مشکلی از کاربر خاص را حل میکند؟» اگر پاسخی وجود ندارد — قابلیت لازم نیست.

تفاوت YAGNI با تنبلی و برش گوشهها

YAGNI انکار معماری باکیفیت نیست. YAGNI نوشتن کد اضافی را منع میکند، اما نوشتن کد درست را منع نمیکند. اگر برای قابلیت فعلی به یک لایه انتزاع تمیز نیاز است — آن را بسازید. اگر لایه لازم نیست — نسازید. تفاوت کلیدی: YAGNI درباره قابلیت است، نه درباره کیفیت.

توسعهدهندگان اغلب YAGNI را با انباشت عمدی بدهی فنی اشتباه میگیرند (بدهی فنی همیشه یک مصالحه است، YAGNI یک اصل کارآمدی است). تفاوت در این است که بدهی فنی آگاهانه و مستند میشود، در حالی که نقض YAGNI فقط کار بیهوده است.

از خود بپرسید: «اگر همین حالا این انتزاع را نسازم، وقتی لازم شد، چه مدت طول میکشد تا بازسازی (refactoring) انجام شود؟» اگر زمان بازسازی کمتر از زمان نوشتن در حال حاضر است — به تعویق بیندازید.

چرا YAGNI برای پروژههای موبایل حیاتی است؟

توسعه موبایل به سه دلیل نسبت به نقض YAGNI حساس است: اندازه APK/IPA به طور مستقیم بر نرخ نصب تأثیر میگذارد، زمان کامپایل پروژههای موبایل به صورت خطی با حجم کد افزایش مییابد و هر قابلیت اضافی نقاط خرابی را بیشتر میکند. YAGNI درباره تنبلی نیست، بلکه درباره تمرکز است.

تحقیق Google Play Console Data (2023) نشان داد: هر ۱۰ مگابایت اندازه APK احتمال نصب را ۱.۲٪ کاهش میدهد. کد استفادهنشده فقط زباله در مخزن نیست، بلکه ضرر مالی مستقیم است. کتابخانههای اضافی (برای قابلیتی که «شاید بعداً اضافه کنیم») رایجترین منبع بزرگ شدن APK هستند.

بر اساس گزارش عملکرد ساخت Gradle (2024)، هر ماژول اضافی در پروژه Android زمان ساخت کامل را ۳ تا ۷ ثانیه افزایش میدهد. اگر ۵ ماژول «برای آینده» اضافه کنید — افزایش زمان کامپایل ۱۵ تا ۳۵ ثانیه در هر ساخت خواهد بود. در یک سال، تیمی ۵ نفره تا ۲۰۰ نفر-ساعت را صرف انتظار برای کامپایل میکند.

اندازه باینری را در CI پایش کنید: حد هشدار تعیین کنید (مثلاً +۵۰۰ کیلوبایت به ازای هر کامیت). اگر اندازه بدون قابلیت جدید بزرگ شد — این نقض YAGNI است که باید در code review بررسی شود.

YAGNI در برابر gold-plating: مثالهای عملی

Gold-plating: انیمیشن زودهنگام

Gold-plating — افزودن قابلیت فراتر از نیازها در تلاش برای «بهبود» محصول است. نمونه معمول: توسعهدهنده یک انیمیشن پیچیده برای انتقال بین صفحهها اضافه میکند، در حالی که در طراحی یک fade ساده مشخص شده است. ساخت انیمیشن ۲ روز طول میکشد، کاربر متوجه آن نمیشود و باگها در دستگاههای مختلف سالها پروژه را دنبال میکنند.

بر اساس گزارش سالانه UX Collective (2023)، ۷۸٪ از کاربران اپلیکیشن را بر اساس سرعت و پایداری ارزیابی میکنند، نه انیمیشنها. YAGNI میگوید: اگر انیمیشن در نیازها مشخص نشده — آن را پیادهسازی نکنید. طراح انیمیشن را زمانی اضافه میکند که واقعاً برای حل یک مشکل UX لازم شود.

فقط چیزی را پیادهسازی کنید که در طرحها (mockup) وجود دارد. اگر طراح انیمیشن نکشیده — یعنی نباید وجود داشته باشد. هر انحرافی از طرح، نقض YAGNI است.

بومیسازی زودهنگام به ۲۰ زبان

اشتباه رایج استارتاپها: بلافاصله پشتیبانی از ۲۰+ زبان را «برای ورود آینده به بازار بینالمللی» در نظر میگیرند. YAGNI توصیه میکند: فقط به زبان بازار فعلی بومیسازی کنید. افزودن هر زبان جدید به زمان مترجمان، تست متنها از نظر برش و رفع مشکلات چیدمان RTL نیاز دارد.

تحقیق Deloitte Digital Globalization Survey (2022) نشان داد: ۶۰٪ از اپلیکیشنهای موبایل هرگز از بازار اول فراتر نمیروند. اگر این مورد شماست — منابع صرفشده برای چندزبانگی هدر رفتهاند. رویکرد YAGNI: انگلیسی (پایه) + زبان بازار هدف. بقیه — با ورود واقعی به منطقه.

برای اولویتبندی از YAGNI استفاده کنید: اگر قابلیتی در نقشه راه (roadmap) دو فصل آینده نیست — آن را شروع نکنید. نقشه راه باید به صورت مستند توسط مدیر محصول تأیید شود.

چگونه YAGNI را در Android و iOS اعمال کنیم؟

YAGNI در Android: کتابخانههای اضافی اضافه نکنید

پروژههای Android از تورم کتابخانهای رنج میبرند. توسعهدهندگان Retrofit، OkHttp، Gson، Room، Dagger Hilt، Navigation Component، DataStore را حتی قبل از نوشتن اولین خط منطق تجاری اضافه میکنند. YAGNI توصیه میکند: کتابخانهها را بر اساس نیاز واقعی اضافه کنید، نه به صورت پیشگیرانه.

// نقض YAGNI: اتصال پیشگیرانه کتابخانهها
// build.gradle (ماژول)
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» را نشان میدهد

کتابخانهها وابستگیهایی با پیچیدگی خاص خودشان هستند. هر کدام نیاز به بهروزرسانی نسخهها، مهاجرت هنگام تغییرات ناسازگار (breaking changes) دارد و اندازه APK را افزایش میدهد. کتابخانه را زمانی اضافه کنید که یک وظیفه مشخص ظاهر میشود که توسط آن کتابخانه حل میشود. با OkHttp (حداقل کلاینت HTTP) شروع کنید، وقتی به کلاینت REST نیاز شد Retrofit را اضافه کنید و به همین ترتیب.

YAGNI در iOS: 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 در برابر UIKit» (2024) توصیه میکند: صفحههای UIKit موجود را بدون دلیل تجاری واضح (مثلاً نیاز به Live Preview برای طراح) به SwiftUI مهاجرت ندهید. بازنویسی کد کارا — نقض مستقیم YAGNI است. SwiftUI برای صفحههای جدید، UIKit برای صفحههای موجود.

اشتباهات رایج در پیروی از YAGNI

YAGNI بهعنوان بهانه معماری بد

خطرناکترین اشتباه — استفاده از YAGNI بهعنوان بهانهای برای معماری بد. «ما لایه مخزن (repository) را جدا نمیکنیم چون YAGNI — درخواست را مستقیم در ViewModel مینویسیم». این YAGNI نیست، این انباشت بدهی فنی است. YAGNI قابلیت اضافی را منع میکند، نه یکپارچگی معماری را.

معماری یک سرمایهگذاری در قابلیت نگهداری است. اگر بیش از ۳ صفحه مینویسید — لایه معماری پایه (MVVM، repository) از قبل توجیه شده است. اگر ۱ صفحه است — میتوانید رویکرد ساده را داشته باشید. کلید: حداقل معماری لازم برای قابلیتهای فعلی را تعیین کنید و بیشتر از آن اضافه نکنید.

تصمیمها را به «معماری» و «عملکردی» تقسیم کنید. تصمیمهای معماری (لایهها، ناوبری، DI) تحت پوشش YAGNI نیستند — آنها برای قابلیت نگهداری لازم هستند. تصمیمهای عملکردی (قابلیتها، اسکرینشاتها، انیمیشنها) — تحت پوشش هستند.

پیروی کورکورانه از YAGNI هنگام کار با API

افراط دیگر — نادیده گرفتن قراردادهای آینده API است. توسعهدهنده از بکاند JSON با ۵ فیلد دریافت میکند و فقط ۳ فیلد را پارس میکند، چون «بقیه طبق YAGNI لازم نیستند». مشکل: هنگام اضافه شدن یک فیلد، بکاند ممکن است پارس را خراب کند اگر پاسخ تغییر کرده باشد. راهحل — نگاشت (mapping) همه فیلدهای پاسخ، حتی اگر همه در حال حاضر استفاده نشوند.

بر اساس راهنمای طراحی API متا (2023)، کلاینت باید همه فیلدهایی را که سرور برمیگرداند پارس کند، فیلدهای استفادهنشده را نادیده بگیرد، اما کل ساختار را کنار نگذارد. YAGNI اینجا چیز دیگری میگوید: نباید پردازش فیلدهایی را اضافه کرد که هنوز در مشخصات وجود ندارند، «برای اینکه شاید بکاند آنها را برگرداند».

کل ساختار پاسخ را پارس کنید (همه فیلدهایی که سرور در حال حاضر برمیگرداند). پردازش فیلدهایی را که در مشخصات فعلی API نیستند اضافه نکنید. این تعادل بین YAGNI و مقاومت در برابر تغییرات است.