KISS در توسعه موبایل — چیست، اصل سادگی و چگونه آن را به کار ببریم

KISS چیست؟

KISS (Keep It Simple, Stupid) — اصل طراحی که به حداقل رساندن پیچیدگی سیستم را الزام می‌کند. توسط مهندس کلی جانسون (Lockheed SR-71 Blackbird) در نیروی دریایی ایالات متحده در دهه 1960 فرموله شد. جانسون خواستار این بود که هواپیما بتواند توسط مکانیک در شرایط میدانی بدون ابزار خاص تعمیر شود — این جوهر KISS است.

در توسعه نرم‌افزار KISS به این معناست: راه‌حل باید تا حد امکان ساده باشد، اما نه ساده‌تر (بخش دوم جمله منسوب به آلبرت اینشتین). سادگی — مترادف ابتدایی بودن نیست؛ راه‌حل ساده کار را با حداقل افزونگی انجام می‌دهد.

تحقیق Google Research (2022) نشان داد: میانگین زمان ورود به پروژه برای یک توسعه‌دهنده جدید در پروژه‌های با رعایت KISS 3 هفته در مقابل 10 هفته در پروژه‌های با معماری بیش از حد است. کد ساده — سرمایه‌گذاری در سرعت سازگاری اعضای جدید تیم.

KISS را به عنوان فیلتر به کار بگیرید: قبل از اضافه کردن یک انتزاع جدید از خود بپرسید «آیا این مشکلی را حل می‌کند که امروز پیش آمده یا مشکلی که ممکن است یک سال دیگر پیش بیاید؟» اگر دومی — انجام ندهید.

KISS و اصل تیغ اوکام

تیغ اوکام (قرن چهاردهم) — اصل فلسفی: «نباید موجودات را بدون ضرورت افزایش داد». در برنامه‌نویسی این به این معناست: از دو راه‌حلی که به یک اندازه نیازها را برآورده می‌کنند، راهی را انتخاب کنید که موجودات کمتری (کلاس‌ها، ماژول‌ها، وابستگی‌ها) دارد. KISS — پیاده‌سازی عملی تیغ اوکام در کد است.

تفاوت در این است که تیغ اوکام یک اصل عمومی شناخت است، در حالی که KISS یک رویه مهندسی مشخص با نتیجه قابل اندازه‌گیری است: کاهش پیچیدگی سیکلوماتیک، کاهش تعداد خطوط کد، کوتاه شدن زمان بازبینی کد. متریک‌ها امکان ارزیابی عینی رعایت KISS را فراهم می‌کنند.

از این متریک پیروی کنید: کد «به اندازه کافی ساده» در نظر گرفته می‌شود اگر یک توسعه‌دهنده جدید قطعه را در یک دقیقه بدون توضیح بفهمد. اگر بیشتر نیاز است — ساده‌سازی کنید.

چرا سادگی در توسعه موبایل حیاتی است؟

توسعه موبایل سه ویژگی دارد که KISS را به ویژه مهم می‌کند: منابع محدود دستگاه (حافظه، پردازنده)، به‌روزرسانی‌های مکرر پلتفرم‌ها (iOS سالانه، Android — فصلی) و نیاز به تحویل سریع ویژگی‌ها از طریق CI/CD. کد پیچیده این سرعت را تحمل نمی‌کند.

تحلیل Apple WWDC 2023: «Embrace Swift Generics» نشان داد: پروژه متوسط iOS حاوی 40–60% «کد مرده» است — انتزاع‌هایی که برای آینده نوشته شده‌اند اما هرگز استفاده نمی‌شوند. این کد نه تنها حجم باینری را افزایش می‌دهد، بلکه کامپایل را کند می‌کند و ناوبری را دشوار می‌سازد. KISS از این جلوگیری می‌کند: فقط آنچه اکنون نیاز است را بنویسید.

بر اساس گزارش Android Developer Relations Report (2024)، پروژه‌های با نسبت پایین کد به تست (کمتر از 1:0.8) 67% باگ تولیدی بیشتری دارند. کد پیچیده تست کردن سخت‌تر است — این تهدیدی مستقیم برای کیفیت است. سادگی — شرط لازم برای پوشش بالای تست است.

پیچیدگی کد خود را از طریق متریک‌ها اندازه بگیرید: پیچیدگی سیکلوماتیک (Cyclomatic Complexity) — هر متد را زیر 10، ایده‌آل تا 5 نگه دارید. برای بررسی خودکار از Detekt (Android) یا SwiftLint (iOS) استفاده کنید.

KISS در مقابل overengineering: مثال‌های عملی

معماری بیش از حد: لایه‌های زیاد

overengineering معمولی — ایجاد کارخانه انتزاعی مخازن در پروژه‌ای با یک منبع داده. به جای یک کلاس Repository ساده، توسعه‌دهنده زنجیره‌ای می‌سازد: RepositoryFactory → IRepository → BaseRepository → RepositoryImpl — برای تغییر فرضی API به GraphQL.

بر اساس نظرسنجی JetBrains Developer Survey (2023)، 43% توسعه‌دهندگان Android اعتراف کردند که حداقل یک بار یک لایه معماری را هنگام بازآرایی حذف کرده‌اند چون استفاده نشده بود. KISS می‌گوید: وقتی دومین پیاده‌سازی ظاهر شد انتزاع ایجاد کنید، نه از روی پیش‌بینی.

با یک پیاده‌سازی مشخص بدون رابط شروع کنید. وقتی منبع داده دوم ظاهر شد — رابط را از طریق بازآرایی جدا کنید (IDE این کار را خودکار انجام می‌دهد). این سریع‌تر از نوشتن رابط از قبل است.

گراف‌های تزریق وابستگی بیش از حد پیچیده

چارچوب‌های DI (Dagger, Hilt, Swinject) — ابزارهای قدرتمندی هستند، اما اغلب باعث پیچیدگی می‌شوند. توسعه‌دهندگان برای هر موجودیت یک ماژول جداگانه ایجاد می‌کنند، حتی اگر در یک مکان استفاده شود. جایگزین KISS: تزریق دستی از طریق سازنده برای موارد ساده.

// Overengineering: ماژول برای یک مخزن
@Module
object UserModule {
    @Provides
    fun provideUserRepo(): UserRepository = UserRepositoryImpl()
}

// KISS: تزریق دستی، اگر مخزن یکی است
class UserViewModel(
    private val repo: UserRepository = UserRepositoryImpl()
) { /* ... */ }

تزریق دستی در سازنده — ساده‌ترین الگوی DI. نیاز به تولید کد، حاشیه‌نویسی و ماژول ندارد. به چارچوب DI مهاجرت کنید فقط وقتی پروژه به 5+ صفحه رسید و تزریق دستی دشوار شد.

چگونه KISS را در Android و iOS به کار ببریم؟

KISS در Android: ViewModel و LiveData ساده

Android ViewModel — منبع مکرر پیچیدگی بیش از حد. توسعه‌دهندگان StateFlow، combine، flatMapLatest و زنجیره‌های تبدیل را جایی اضافه می‌کنند که یک MutableLiveData ساده با postValue کافی است. KISS توصیه می‌کند: با ساده‌ترین راه‌حل شروع کنید (LiveData)، فقط برای کار خاص پیچیده کنید (بازنشانی حالت، debounce).

// KISS: ViewModel ساده بدون زنجیره‌های واکنشی
class ProfileViewModel : ViewModel() {
    private val _name = MutableLiveData<String>()
    val name: LiveData<String> = _name

    fun loadUser(id: String) {
        viewModelScope.launch {
            _name.postValue(repo.getUser(id).name)
        }
    }
}

در این مثال ViewModel از coroutine برای درخواست ناهمگام و LiveData برای انتشار نتیجه استفاده می‌کند. خبری از StateFlow نیست، خبری از combine نیست — فقط آنچه واقعاً نیاز است. StateFlow را اضافه کنید وقتی جریان داده یک‌طرفه (UDF) با حالت صریح مورد نیاز است.

KISS در iOS: ساختارهای ساده به جای کلاس‌ها

در iOS اصل KISS از طریق ترجیح ساختارها (struct) بر کلاس‌ها (class) برای مدل‌های داده نمایان می‌شود. ساختارها نوع ارزشی (value type) هستند، نیاز به مدیریت حافظه از طریق ARC ندارند، به طور پیش‌فرض تغییرناپذیرند. کلاس‌ها فقط در صورت نیاز به هویت (دو ارجاع به یک شیء) یا وراثت توجیه می‌شوند.

// KISS: struct به جای class برای مدل
struct User: Codable {
    let id: Int
    let name: String
    let email: String
}

// Overengineering: class با init و deinit دستی
class UserClass: NSObject {
    let id: Int
    init(id: Int) { self.id = id }
}

ساختار User به طور خودکار memberwise init، پشتیبانی از Equatable و Hashable (در همه فیلدها)، تغییرناپذیری و امنیت در محیط چندنخی را دریافت می‌کند. کلاس نیاز به init دستی، پیاده‌سازی NSObject دارد و در معرض race conditions از طریق حالت مشترک است.

سادگی در لایه شبکه

لایه شبکه — حوزه دیگری که KISS اغلب نقض می‌شود. توسعه‌دهندگان زنجیره Interceptor با 5+ عنصر، سریال‌سازی از طریق کارخانه‌های انتزاعی و مپرها برای هر endpoint اضافه می‌کنند. راه‌حل KISS: یک URLSession با تنظیمات و یک دیکدینگ از طریق Codable/JSON.

بر اساس توصیه‌های Apple: URLSession Programming Guide (2023)، یک لایه شبکه ساده روی URLSession با Codable 95% سناریوهای برنامه موبایل را پوشش می‌دهد. زنجیره‌های پیچیده Interceptor فقط برای موارد خاص لازم است: تازه‌سازی توکن، ثبت وقایع، رمزگذاری.

با یک لایه شبکه ساده روی URLSession + Codable شروع کنید. Interceptor را بر اساس نیاز واقعی اضافه کنید، نه برای آینده. این کار کد لایه شبکه را 2–3 برابر کاهش می‌دهد.

اشتباهات رایج هنگام پیروی از KISS

اشتباه گرفتن سادگی با ابتدایی بودن

سادگی — همان ابتدایی بودن نیست. راه‌حل ساده — مختصر، قابل فهم و حل‌کننده کار بدون افزونگی است. ابتدایی — نادیده‌گیرنده best practices و معماری سالم. تفاوت در این است که راه‌حل ساده به راحتی گسترش می‌یابد، اما ابتدایی — نه.

مثال: استفاده از Activity به عنوان تنها موجودیت برای همه صفحه‌ها — این ابتدایی بودن است، نه سادگی. سادگی — استفاده از Navigation Component با Fragmentهای مختلف برای صفحه‌های مختلف، اما بدون انتزاع‌های اضافی. KISS معماری بد را توجیه نمی‌کند.

خود را بررسی کنید: آیا کد شما می‌تواند با اضافه شدن یک ویژگی جدید تغییر کند؟ اگر بله — سادگی درست است. اگر برای هر ویژگی باید همه چیز را بازنویسی کنید — این ابتدایی بودن است، فوراً بازآرایی کنید.

نادیده گرفتن الگوها به نام KISS

الگوها (MVVM, MVI, Coordinator) — پیچیده‌سازی نیستند، بلکه ساختاردهی هستند. KISS استفاده از الگوهای معماری اثبات‌شده را منع نمی‌کند. استفاده بیش از حد آنها ممنوع است: سه الگو در جایی که یکی کافی است. حد وسط طلایی — یک الگوی معماری برای پروژه و حداکثر 2–3 الگوی کمکی (DI, Navigation).

طبق State of Mobile Architecture Report (2024)، پروژه‌هایی که دقیقاً از یک الگوی معماری استفاده می‌کنند 34% باگ کمتری در سال اول توسعه نسبت به پروژه‌های «فرانکنشتاین» با ترکیب 3+ الگو دارند. انتخاب کنید MVVM یا MVI را برای پروژه موبایل — و در همه صفحه‌ها به آن پایبند باشید.

MVVM و MVI را در یک پروژه مخلوط نکنید. اگر تیم MVVM را انتخاب کرده است — کل پروژه باید از MVVM پیروی کند. استثنا — ماژول‌های ویژگی جداگانه با راه‌حل معماری خاص خود، اما این باید انتخابی آگاهانه باشد.