KISS у мобилном развоју — шта је то, принцип једноставности и како га применити

Шта је KISS?

KISS (Keep It Simple, Stupid) — принцип пројектовања који захтева минимизацију сложености система. Формулисан је у америчкој морнарици 1960-их година од стране инжењера Келија Џонсона (Lockheed SR-71 Blackbird). Џонсон је захтевао да авион може да поправи механичар у теренским условима без специјалних алата — то је суштина KISS-а.

У развоју софтвера KISS значи: решење треба да буде једноставно колико је могуће, али не једноставније (други део реченице се приписује Алберту Ајнштајну). Једноставност — није синоним за примитивност; једноставно решење обавља задатак са минималном редундантношћу.

Истраживање Google Research (2022) показало је: просечно време уласка у пројекат за новог програмера је 3 недеље у пројектима са поштовањем KISS-а наспрам 10 недеља у пројектима са прекомерном архитектуром. Једноставан код — инвестиција у брзину адаптације нових чланова тима.

Примењујте KISS као филтер: пре додавања нове апстракције запитајте се „да ли ово решава проблем који се појавио данас или проблем који би могао да се појави за годину дана?“ Ако је друго — немојте.

KISS и Окамова бритва

Окамова бритва (XIV век) — филозофски принцип: „не треба умножавати суштине без потребе“. У програмирању ово значи: од два решења која подједнако задовољавају захтеве, изаберите оно са мање суштина (класа, модула, зависности). KISS — практична имплементација Окамове бритве у коду.

Разлика је у томе што је Окамова бритва општи принцип сазнања, а KISS конкретна инжењерска пракса са мерљивим резултатом: смањење цикломатске сложености, смањење броја линија кода, скраћење времена code review-а. Метрике омогућују објективну процену поштовања 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) за моделе података. Структуре су вредносни типови, не захтевају управљање меморијом кроз 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. Изузетак — засебни модули функционалности са сопственим архитектонским решењем, али то треба да буде свестан избор.