KISS sa mobile development — ano ito, prinsipyo ng pagiging simple at kung paano ito ilapat

Ano ang KISS?

KISS (Keep It Simple, Stupid) — prinsipyo ng disenyo na nag-uutos ng pag-minimize ng pagiging kumplikado ng sistema. Binumula sa US Navy noong 1960s ng inhinyero na si Kelly Johnson (Lockheed SR-71 Blackbird). Hiniling ni Johnson na ang eroplano ay maaaring ayusin ng isang mekaniko sa field nang walang espesyal na kasangkapan — iyon ang esensya ng KISS.

Sa pag-develop ng software, ang KISS ay nangangahulugang: ang solusyon ay dapat na kasing simple hangga't maaari, ngunit hindi mas simple (ang ikalawang bahagi ng parirala ay iniuugnay kay Albert Einstein). Pagiging simple — hindi kasingkahulugan ng pagiging primitive; ang simpleng solusyon ay gumaganap ng gawain na may minimal na redundansya.

Ang pananaliksik ng Google Research (2022) ay nagpakita: ang average na oras ng pagpasok sa proyekto para sa isang bagong developer ay 3 linggo sa mga proyektong sumusunod sa KISS kumpara sa 10 linggo sa mga proyektong may labis na arkitektura. Simpleng code — pamumuhunan sa bilis ng adaptasyon ng mga bagong miyembro ng koponan.

Ilapat ang KISS bilang filter: bago magdagdag ng bagong abstraksyon, tanungin ang iyong sarili “nilulutas ba nito ang problemang lumitaw ngayon o isang problemang maaaring lumitaw sa isang taon?” Kung ang pangalawa — huwag gawin.

KISS at prinsipyo ng labaha ni Occam

Labaha ni Occam (ika-14 na siglo) — pilosopikal na prinsipyo: “hindi dapat paramihin ang mga entidad nang walang pangangailangan”. Sa programming, nangangahulugan ito: mula sa dalawang solusyon na parehong nakakatugon sa mga kinakailangan, piliin ang may mas kaunting entidad (klase, modyul, dependency). KISS — praktikal na implementasyon ng labaha ni Occam sa code.

Ang pagkakaiba ay ang labaha ni Occam ay isang pangkalahatang prinsipyo ng pagkilala, habang ang KISS ay isang konkretong praktika ng inhinyeriya na may nasusukat na resulta: pagbawas ng cyclomatic complexity, pagbawas ng bilang ng mga linya ng code, pagpapaikli ng oras ng code review. Mga metrik ay nagbibigay-daan sa obhetibong pagsusuri ng pagsunod sa KISS.

Sundin ang metrik: ang code ay itinuturing na “sapat na simple” kung ang isang bagong developer ay nauunawaan ang fragment sa loob ng isang minuto nang walang komento. Kung kailangan ng higit pa — pasimplehin.

Bakit mahalaga ang pagiging simple sa mobile development?

Mobile development ay may tatlong katangian na ginagawang partikular na mahalaga ang KISS: limitadong mapagkukunan ng device (memorya, processor), madalas na pag-update ng platform (iOS taun-taon, Android — quarterly) at pangangailangan ng mabilis na paghahatid ng feature sa pamamagitan ng CI/CD. Ang kumplikadong code ay hindi kayang tiisin ang bilis na ito.

Ang pagsusuri ng Apple WWDC 2023: “Embrace Swift Generics” ay nagpakita: ang average na iOS project ay naglalaman ng 40–60% “patay na code” — mga abstraksyon na isinulat para sa hinaharap na hindi kailanman ginagamit. Ang code na ito ay hindi lamang nagpapalaki ng binary size, kundi nagpapabagal din ng compilation at nagpapahirap sa nabigasyon. KISS ay pumipigil dito: isulat lamang kung ano ang kailangan ngayon.

Ayon sa Android Developer Relations Report (2024), ang mga proyektong may mababang ratio ng code sa test (mas mababa sa 1:0.8) ay may 67% mas maraming production bug. Ang kumplikadong code ay mas mahirap subukan — ito ay direktang banta sa kalidad. Pagiging simple — kinakailangang kondisyon para sa mataas na test coverage.

Sukatin ang pagiging kumplikado ng iyong code sa pamamagitan ng mga metrik: cyclomatic complexity — panatilihin ang bawat metodo sa ibaba 10, perpekto hanggang 5. Gamitin ang Detekt (Android) o SwiftLint (iOS) para sa awtomatikong pagsusuri.

KISS laban sa overengineering: mga praktikal na halimbawa

Labis na arkitektura: masyadong maraming layer

Karaniwang overengineering — paglikha ng abstract factory ng repositoryo sa isang proyektong may isang mapagkukunan ng data. Sa halip na simpleng Repository class, ang developer ay gumagawa ng chain: RepositoryFactory → IRepository → BaseRepository → RepositoryImpl — para sa hipotetikal na pagbabago ng API sa GraphQL.

Ayon sa survey ng JetBrains Developer Survey (2023), 43% ng Android developers ay umamin na kahit isang beses ay nagtapon ng architectural layer sa refactoring dahil hindi ito ginamit. KISS ay nagsasabi: gumawa ng abstraksyon kapag lumitaw ang ikalawang implementasyon, hindi sa pag-asa.

Magsimula sa konkretong implementasyon nang walang interface. Kapag lumitaw ang ikalawang mapagkukunan ng data — i-extract ang interface sa pamamagitan ng refactoring (gagawin ito ng IDE nang awtomatiko). Ito ay mas mabilis kaysa sa pagsulat ng interface nang maaga.

Masyadong komplikadong dependency injection graphs

Mga DI framework (Dagger, Hilt, Swinject) — makapangyarihang kasangkapan, ngunit madalas silang pumupukaw ng komplikasyon. Ang mga developer ay gumagawa ng hiwalay na modyul para sa bawat entidad, kahit na ginagamit ito sa isang lugar. Alternatibong KISS: manu-manong ineksyon sa pamamagitan ng constructor para sa mga simpleng kaso.

// Overengineering: modyul para sa isang repositoryo
@Module
object UserModule {
    @Provides
    fun provideUserRepo(): UserRepository = UserRepositoryImpl()
}

// KISS: manu-manong ineksyon, kung isa lang ang repositoryo
class UserViewModel(
    private val repo: UserRepository = UserRepositoryImpl()
) { /* ... */ }

Ang manu-manong ineksyon sa constructor — ang pinakasimpleng pattern ng DI. Hindi ito nangangailangan ng pagbuo ng code, anotasyon o modyul. Lumipat sa DI framework lamang kapag ang proyekto ay umabot sa 5+ screen at ang manu-manong ineksyon ay nagiging mahirap panatilihin.

Paano ilapat ang KISS sa Android at iOS?

KISS sa Android: simpleng ViewModel at LiveData

Android ViewModel — madalas na mapagkukunan ng labis na pagiging kumplikado. Ang mga developer ay nagdaragdag ng StateFlow, combine, flatMapLatest at mga transformation chain kung saan sapat na ang simpleng MutableLiveData na may postValue. KISS ay nagrerekomenda: magsimula sa pinakasimpleng solusyon (LiveData), magpakumplikado lamang para sa tiyak na gawain (pag-reset ng estado, debounce).

// KISS: simpleng ViewModel nang walang reaktibong chain
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)
        }
    }
}

Sa halimbawang ito, ang ViewModel ay gumagamit ng coroutine para sa asynchronous na request, LiveData para sa pag-publish ng resulta. Walang StateFlow, walang combine — tanging kung ano ang talagang kailangan. Magdagdag ng StateFlow kapag kinakailangan ang unidirectional data flow (UDF) na may tahasang estado.

KISS sa iOS: simpleng struct sa halip na class

Sa iOS ang prinsipyong KISS ay nagpapakita sa pamamagitan ng kagustuhan sa mga istruktura (struct) kaysa sa mga klase (class) para sa mga modelo ng data. Ang mga istruktura ay value type, hindi nangangailangan ng pamamahala ng memorya sa pamamagitan ng ARC, hindi nababago bilang default. Ang mga klase ay makatwiran lamang kapag kinakailangan ang pagkakakilanlan (dalawang sanggunian sa iisang bagay) o pamana.

// KISS: struct sa halip na class para sa modelo
struct User: Codable {
    let id: Int
    let name: String
    let email: String
}

// Overengineering: class na may manu-manong init at deinit
class UserClass: NSObject {
    let id: Int
    init(id: Int) { self.id = id }
}

Ang istrukturang User ay awtomatikong nakakakuha ng memberwise init, suporta para sa Equatable at Hashable (sa lahat ng field), hindi pagbabago at kaligtasan sa multi-threaded na kapaligiran. Ang klase ay nangangailangan ng manu-manong init, implementasyon ng NSObject at mahina sa race conditions sa pamamagitan ng shared state.

Pagiging simple sa network layer

Network layer — isa pang lugar kung saan madalas nilalabag ang KISS. Ang mga developer ay nagdaragdag ng Interceptor chain na may 5+ elemento, serialization sa pamamagitan ng abstract factories at mapper para sa bawat endpoint. Solusyong KISS: isang URLSession na may configuration at isang decoding sa pamamagitan ng Codable/JSON.

Ayon sa rekomendasyon ng Apple: URLSession Programming Guide (2023), ang simpleng network layer sa URLSession na may Codable ay sumasaklaw sa 95% ng mga mobile app scenario. Ang mga kumplikadong Interceptor chain ay kailangan lamang para sa mga tiyak na kaso: pag-refresh ng token, pag-log, pag-encrypt.

Magsimula sa simpleng network layer sa URLSession + Codable. Magdagdag ng Interceptor batay sa aktwal na pangangailangan, hindi para sa susunod. Pinapaikli nito ang code ng network layer ng 2–3 beses.

Mga karaniwang pagkakamali sa pagsunod sa KISS

Pagkalito sa pagitan ng pagiging simple at primitiveness

Pagiging simple — hindi katulad ng primitiveness. Ang simpleng solusyon ay maigsi, naiintindihan at nilulutas ang gawain nang walang kalabisan. Ang primitive — binabalewala ang best practices at malusog na arkitektura. Ang pagkakaiba ay ang simpleng solusyon ay madaling palawakin, samantalang ang primitive — hindi.

Halimbawa: paggamit ng Activity bilang nag-iisang entidad para sa lahat ng screen — ito ay primitiveness, hindi pagiging simple. Pagiging simple — paggamit ng Navigation Component na may iba't ibang Fragment para sa iba't ibang screen, ngunit walang hindi kinakailangang abstraksyon. KISS ay hindi nagbibigay-katwiran sa masamang arkitektura.

Suriin ang iyong sarili: maaari bang magbago ang iyong code kapag nagdaragdag ng bagong feature? Kung oo — tama ang pagiging simple. Kung para sa bawat feature ay kailangang muling isulat lahat — ito ay primitiveness, agad na mag-refactor.

Pagbabalewala sa mga pattern sa ngalan ng KISS

Mga pattern (MVVM, MVI, Coordinator) — hindi komplikasyon, kundi pag-istruktura. Hindi ipinagbabawal ng KISS ang paggamit ng mga napatunayang pattern ng arkitektura. Ipinagbabawal ang labis na paggamit ng mga ito: tatlong pattern kung saan sapat na ang isa. Gitnang daan — isang pattern ng arkitektura bawat proyekto at hindi hihigit sa 2–3 pantulong (DI, Navigation).

Ayon sa State of Mobile Architecture Report (2024), ang mga proyektong gumagamit ng eksaktong isang pattern ng arkitektura ay may 34% mas kaunting bug sa unang taon ng pag-develop kumpara sa mga proyektong “frankenstein” na may kombinasyon ng 3+ pattern. Pumili ng MVVM o MVI para sa mobile project — at sundin ito sa lahat ng screen.

Huwag paghaluin ang MVVM at MVI sa isang proyekto. Kung pinili ng koponan ang MVVM — ang buong proyekto ay dapat sumunod sa MVVM. Pagbubukod — hiwalay na feature module na may sariling solusyon sa arkitektura, ngunit ito ay dapat na malay na pagpili.