KISS mobil inkişafda — nədir, sadəlik prinsipi və onu necə tətbiq etmək olar

KISS nədir?

KISS (Keep It Simple, Stupid) — sistemin mürəkkəbliyini minimuma endirməyi tələb edən dizayn prinsipi. ABŞ Hərbi Dəniz Qüvvələrində 1960-cı illərdə mühəndis Kelly Johnson (Lockheed SR-71 Blackbird) tərəfindən formalaşdırılmışdır. Johnson təyyarənin çöl şəraitində xüsusi alətlər olmadan mexanik tərəfindən təmir edilə bilməsini tələb edirdi — KISS-in mahiyyəti budur.

Proqram təminatı inkişafında KISS o deməkdir: həll mümkün qədər sadə olmalıdır, ancaq daha sadə yox (Albertdə Eynşteynə aid edilən ikinci hissə). Sadəlik — primitivliyin sinonimi deyil; sadə həll tapşırığı minimal artıqlıqla yerinə yetirir.

Google Research (2022) tədqiqatı göstərdi: yeni proqramçı üçün layihəyə giriş orta vaxtı KISS-ə əməl edilən layihələrdə 3 həftə, həddindən artıq arxitekturalı layihələrdə 10 həftə təşkil edir. Sadə kod — komandanın yeni üzvlərinin adaptasiya sürətinə investisiyadır.

KISS-i filtr kimi tətbiq edin: yeni abstraksiya əlavə etməzdən əvvəl özünüzdən soruşun „bu gün yaranan problemi həll edir, yoxsa bir ildən sonra yarana biləcək problemi?” Əgər ikincidirsə — etməyin.

KISS və Occam ülgücü prinsipi

Occam ülgücü (XIV əsr) — fəlsəfi prinsip: „varlıqları zərurət olmadan çoxaltmaq olmaz”. Proqramlaşdırmada bu o deməkdir: tələbləri eyni dərəcədə ödəyən iki həlldən daha az varlığı (sinif, modul, asılılıq) olanı seçin. KISS — Occam ülgücünün koddakı praktiki tətbiqidir.

Fərq ondadır ki, Occam ülgücü ümumi idrak prinsipidir, KISS isə ölçülə bilən nəticəsi olan konkret mühəndislik təcrübəsidir: siklotomik mürəkkəbliyin azaldılması, kod sətirlərinin sayının azaldılması, code review vaxtının qısaldılması. Metriklər KISS-ə riayəti obyektiv qiymətləndirməyə imkan verir.

Metrikə əməl edin: kod „kifayət qədər sadə” sayılır, əgər yeni proqramçı fraqmenti bir dəqiqə ərzində şərhsiz başa düşürsə. Daha çox vaxt lazımdırsa — sadələşdirin.

Niyə sadəlik mobil inkişafda kritik əhəmiyyət daşıyır?

Mobil inkişaf KISS-i xüsusilə vacib edən üç xüsusiyyətə malikdir: məhdud cihaz resursları (yaddaş, prosessor), platformaların tez-tez yenilənməsi (iOS hər il, Android — hər rüb) və CI/CD vasitəsilə funksiyaların sürətli çatdırılması zərurəti. Mürəkkəb kod bu tempə tab gətirmir.

Apple WWDC 2023: „Embrace Swift Generics” təhlili göstərdi: orta iOS layihəsində 40–60% „ölü kod” var — gələcək üçün yazılmış, lakin heç vaxt istifadə olunmayan abstraksiyalar. Bu kod təkcə binar faylın ölçüsünü artırmır, həm də kompilyasiyanı ləngidir və naviqasiyanı çətinləşdirir. KISS bunun qarşısını alır: yalnız indi lazım olanı yazın.

Android Developer Relations Report (2024) məlumatına görə, kodun testlərə nisbəti aşağı olan layihələrdə (1:0.8-dən az) istehsal səhvləri 67% daha çoxdur. Mürəkkəb kodu test etmək çətindir — bu keyfiyyət üçün birbaşa təhlükədir. Sadəlik — yüksək test əhatəsi üçün zəruri şərtdir.

Kodunuzun mürəkkəbliyini metriklərlə ölçün: siklotomik mürəkkəblik (Cyclomatic Complexity) — hər metodu 10-dan aşağı, ideal olaraq 5-ə qədər saxlayın. Avtomatik yoxlama üçün Detekt (Android) və ya SwiftLint (iOS) istifadə edin.

KISS overengineering-ə qarşı: praktiki nümunələr

Həddindən artıq arxitektura: çox qat

Tipik overengineering — bir məlumat mənbəyi olan layihədə abstrakt repository fabriki yaratmaqdır. Sadə Repository class əvəzinə proqramçı bir zəncir qurur: RepositoryFactory → IRepository → BaseRepository → RepositoryImpl — hipotetik API dəyişikliyi GraphQL üçün.

JetBrains Developer Survey (2023) sorğusuna görə, Android proqramçılarının 43%-ü ən azı bir dəfə refaktorinq zamanı arxitektura qatını silib, çünki o istifadə olunmurdu. KISS deyir: abstraksiyanı ikinci tətbiq variantı yarandıqda yaradın, gözlənti ilə yox.

Konkret tətbiqdən interfeysiz başlayın. İkinci məlumat mənbəyi yarandıqda — refaktorinq vasitəsilə interfeysi ayırın (IDE bunu avtomatik edəcək). Bu, interfeysi əvvəlcədən yazmaqdan daha sürətlidir.

Həddindən artıq mürəkkəb dependency injection qrafları

DI freymvorkları (Dagger, Hilt, Swinject) — güclü alətlərdir, lakin çox vaxt mürəkkəbləşməyə təhrik edirlər. Proqramçılar hər bir varlıq üçün ayrıca modul yaradır, hətta bir yerdə istifadə olunsa belə. KISS alternativi: sadə hallarda konstruktor vasitəsilə əl ilə enjeksiyon.

// Overengineering: bir repozitoriya üçün modul
@Module
object UserModule {
    @Provides
    fun provideUserRepo(): UserRepository = UserRepositoryImpl()
}

// KISS: əl ilə enjeksiyon, repozitoriya birdirsə
class UserViewModel(
    private val repo: UserRepository = UserRepositoryImpl()
) { /* ... */ }

Konstruktorda əl ilə enjeksiyon — ən sadə DI nümunəsidir. Kod generasiyası, annotasiyalar və modullar tələb etmir. DI freymvorkuna keçin yalnız layihə 5+ ekrana çatdıqda və əl ilə enjeksiyon çətinləşdikdə.

KISS-i Android və iOS-da necə tətbiq etmək olar?

Android-də KISS: sadə ViewModel və LiveData

Android ViewModel — tez-tez həddindən artıq mürəkkəblik mənbəyidir. Proqramçılar sadə MutableLiveData ilə postValue kifayət etdiyi yerdə StateFlow, combine, flatMapLatest və transformasiya zəncirləri əlavə edirlər. KISS tövsiyə edir: ən sadə həllə başlayın (LiveData), yalnız konkret tapşırıq üçün mürəkkəbləşdirin (state sıfırlama, debounce).

// KISS: reaktiv zəncirlər olmadan sadə 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)
        }
    }
}

Bu nümunədə ViewModel asinxron sorğu üçün coroutine, nəticəni dərc etmək üçün LiveData istifadə edir. StateFlow yox, combine yox — yalnız həqiqətən lazım olan. StateFlow əlavə edin aydın vəziyyətlə (UDF) birtərəfli məlumat axını tələb olunduqda.

iOS-da KISS: siniflər yerinə sadə strukturlar

iOS-da KISS prinsipi məlumat modelləri üçün siniflər (class) əvəzinə strukturların (struct) üstünlük təşkil etməsində özünü göstərir. Strukturlar value type-dır, ARC vasitəsilə yaddaş idarəçiliyi tələb etmir, susmaya görə dəyişməzdir. Siniflər yalnız eynilik (bir obyektə iki istinad) və ya miras zərurəti olduqda əsaslandırılır.

// KISS: model üçün class əvəzinə struct
struct User: Codable {
    let id: Int
    let name: String
    let email: String
}

// Overengineering: əl ilə init və deinit ilə class
class UserClass: NSObject {
    let id: Int
    init(id: Int) { self.id = id }
}

User strukturu avtomatik olaraq memberwise init, Equatable və Hashable dəstəyi (bütün sahələr üzrə), dəyişməzlik və çoxiplikli mühitdə təhlükəsizlik əldə edir. Sinif əl ilə init, NSObject tətbiqi tələb edir və paylaşılan vəziyyət vasitəsilə race conditions-a məruz qalır.

Şəbəkə qatında sadəlik

Şəbəkə qatı — KISS-in tez-tez pozulduğu başqa bir sahədir. Proqramçılar 5+ elementli Interceptor zənciri, abstrakt fabriklər və hər endpoint üçün mapper-lər əlavə edirlər. KISS həlli: konfiqurasiya ilə bir URLSession və Codable/JSON vasitəsilə bir dekodinq.

Apple: URLSession Programming Guide (2023) tövsiyələrinə görə, URLSession və Codable üzərində sadə şəbəkə qatı mobil proqram ssenarilərinin 95%-ni əhatə edir. Mürəkkəb Interceptor zəncirləri yalnız spesifik hallar üçün lazımdır: token yeniləmə, loqlama, şifrələmə.

URLSession + Codable üzərində sadə şəbəkə qatı ilə başlayın. Interceptor-ı həqiqi ehtiyac olduqca əlavə edin, ehtiyat üçün yox. Bu, şəbəkə qatının kodunu 2–3 dəfə qısaldır.

KISS-ə əməl edərkən tipik səhvlər

Sadəlik və primitivliyin qarışdırılması

Sadəlik — primitivliklə eyni şey deyil. Sadə həll — yığcam, anlaşılan və tapşırığı izafiliksiz həll edən həlldir. Primitiv — best practices və sağlam arxitekturanı nəzərə almayan. Fərq ondadır ki, sadə həlli genişləndirmək asan, primitivi isə çətindir.

Nümunə: bütün ekranlar üçün yeganə varlıq kimi Activity istifadə etmək — bu primitivlikdir, sadəlik deyil. Sadəlik — Navigation Component ilə müxtəlif ekranlar üçün müxtəlif Fragment istifadə etmək, ancaq lazımsız abstraksiyalar olmadan. KISS pis arxitekturanı əsaslandırmır.

Özünüzü yoxlayın: kodu yeni funksiya əlavə edərkən dəyişə bilərsinizmi? Bəli — sadəlik düzgündür. Əgər hər funksiya üçün hər şeyi yenidən yazmaq lazımdırsa — bu primitivlikdir, təcili refaktorinq edin.

KISS adına nümunələri gözardı etmək

Nümunələr (MVVM, MVI, Coordinator) — çətinləşdirmə deyil, strukturlaşdırmadır. KISS sübut edilmiş arxitektura nümunələrinin istifadəsini qadağan etmir. Onların həddindən artıq tətbiqi qadağandır: biri kifayət edən yerdə üç nümunə. Qızıl orta — layihə üçün bir arxitektura nümunəsi və 2–3 köməkçidən (DI, Navigation) çox olmamalıdır.

State of Mobile Architecture Report (2024)-ə görə, düz bir arxitektura nümunəsi istifadə edən layihələr 3+ nümunə kombinasiyası olan „frankenşteyn” layihələrindən ilk inkişaf ilində 34% daha az səhvə malikdir. Seçin mobil layihə üçün MVVM və ya MVI — və bütün ekranlarda ona əməl edin.

Bir layihədə MVVM və MVI-nı qarışdırmayın. Əgər komanda MVVM seçibsə — bütün layihə MVVM-ə əməl etməlidir. İstisna — öz arxitektura həlli olan ayrıca funksiya modulları, lakin bu şüurlu seçim olmalıdır.