KISS dalam pengembangan mobile — apa itu, prinsip kesederhanaan dan cara menerapkannya

Apa itu KISS?

KISS (Keep It Simple, Stupid) — prinsip desain yang mengharuskan minimalisasi kompleksitas sistem. Dirumuskan di Angkatan Laut AS pada tahun 1960-an oleh insinyur Kelly Johnson (Lockheed SR-71 Blackbird). Johnson menuntut agar pesawat dapat diperbaiki oleh mekanik di lapangan tanpa alat khusus — itulah esensi KISS.

Dalam pengembangan perangkat lunak, KISS berarti: solusi harus sesederhana mungkin, tetapi tidak lebih sederhana (bagian kedua kalimat dikaitkan dengan Albert Einstein). Kesederhanaan — bukan sinonim primitivitas; solusi sederhana menjalankan tugas dengan redundansi minimal.

Penelitian Google Research (2022) menunjukkan: rata-rata waktu masuk proyek untuk pengembang baru adalah 3 minggu di proyek dengan kepatuhan KISS dibandingkan 10 minggu di proyek dengan arsitektur berlebihan. Kode sederhana — investasi dalam kecepatan adaptasi anggota tim baru.

Terapkan KISS sebagai filter: sebelum menambahkan abstraksi baru, tanyakan pada diri sendiri “apakah ini memecahkan masalah yang muncul hari ini atau masalah yang mungkin muncul setahun lagi?” Jika yang kedua — jangan lakukan.

KISS dan prinsip pisau cukur Occam

Pisau cukur Occam (abad XIV) — prinsip filosofis: “entitas tidak boleh diperbanyak tanpa kebutuhan”. Dalam pemrograman ini berarti: dari dua solusi yang sama-sama memenuhi persyaratan, pilih yang memiliki lebih sedikit entitas (kelas, modul, ketergantungan). KISS — implementasi praktis pisau cukur Occam dalam kode.

Perbedaannya adalah bahwa pisau cukur Occam adalah prinsip kognisi umum, sedangkan KISS adalah praktik rekayasa konkret dengan hasil yang terukur: pengurangan kompleksitas sikomatis, pengurangan jumlah baris kode, pemendekan waktu code review. Metrik memungkinkan penilaian objektif kepatuhan KISS.

Ikuti metrik: kode dianggap “cukup sederhana” jika pengembang baru memahami fragmen dalam satu menit tanpa komentar. Jika perlu lebih — sederhanakan.

Mengapa kesederhanaan penting dalam pengembangan mobile?

Pengembangan mobile memiliki tiga karakteristik yang membuat KISS sangat penting: sumber daya perangkat terbatas (memori, prosesor), pembaruan platform yang sering (iOS tahunan, Android — triwulanan) dan kebutuhan pengiriman fitur cepat melalui CI/CD. Kode kompleks tidak tahan dengan kecepatan ini.

Analisis Apple WWDC 2023: “Embrace Swift Generics” menunjukkan: proyek iOS rata-rata mengandung 40–60% “kode mati” — abstraksi yang ditulis untuk masa depan yang tidak pernah digunakan. Kode ini tidak hanya memperbesar ukuran biner, tetapi juga memperlambat kompilasi dan mempersulit navigasi. KISS mencegah ini: tulis hanya apa yang dibutuhkan sekarang.

Menurut Android Developer Relations Report (2024), proyek dengan rasio kode ke tes rendah (kurang dari 1:0.8) memiliki 67% lebih banyak bug produksi. Kode kompleks lebih sulit diuji — ini ancaman langsung terhadap kualitas. Kesederhanaan — syarat penting untuk cakupan tes yang tinggi.

Ukur kompleksitas kode Anda melalui metrik: kompleksitas sikomatis (Cyclomatic Complexity) — jaga setiap metode di bawah 10, idealnya hingga 5. Gunakan Detekt (Android) atau SwiftLint (iOS) untuk pemeriksaan otomatis.

KISS vs overengineering: contoh praktis

Arsitektur berlebihan: terlalu banyak lapisan

Overengineering tipikal — membuat pabrik abstrak repositori dalam proyek dengan satu sumber data. Alih-alih kelas Repository sederhana, pengembang membangun rantai: RepositoryFactory → IRepository → BaseRepository → RepositoryImpl — untuk perubahan API hipotetis ke GraphQL.

Menurut survei JetBrains Developer Survey (2023), 43% pengembang Android mengaku setidaknya sekali membuang lapisan arsitektur saat refactoring karena tidak digunakan. KISS mengatakan: buat abstraksi ketika implementasi kedua muncul, bukan dalam antisipasi.

Mulailah dengan implementasi konkret tanpa antarmuka. Ketika sumber data kedua muncul — ekstrak antarmuka melalui refactoring (IDE akan melakukannya secara otomatis). Ini lebih cepat daripada menulis antarmuka terlebih dahulu.

Graf dependency injection yang terlalu rumit

Framework DI (Dagger, Hilt, Swinject) — alat yang kuat, tetapi sering memicu komplikasi. Pengembang membuat modul terpisah untuk setiap entitas, bahkan jika digunakan di satu tempat. Alternatif KISS: injeksi manual melalui konstruktor untuk kasus sederhana.

// Overengineering: modul untuk satu repositori
@Module
object UserModule {
    @Provides
    fun provideUserRepo(): UserRepository = UserRepositoryImpl()
}

// KISS: injeksi manual, jika repositori hanya satu
class UserViewModel(
    private val repo: UserRepository = UserRepositoryImpl()
) { /* ... */ }

Injeksi manual di konstruktor — pola DI paling sederhana. Tidak memerlukan pembuatan kode, anotasi, atau modul. Beralihlah ke framework DI hanya ketika proyek mencapai 5+ layar dan injeksi manual menjadi sulit dipelihara.

Bagaimana menerapkan KISS di Android dan iOS?

KISS di Android: ViewModel dan LiveData sederhana

Android ViewModel — sumber kompleksitas berlebihan yang sering terjadi. Pengembang menambahkan StateFlow, combine, flatMapLatest dan rantai transformasi di mana MutableLiveData sederhana dengan postValue sudah cukup. KISS merekomendasikan: mulai dengan solusi paling sederhana (LiveData), rumitkan hanya untuk tugas tertentu (reset status, debounce).

// KISS: ViewModel sederhana tanpa rantai reaktif
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)
        }
    }
}

Dalam contoh ini ViewModel menggunakan coroutine untuk permintaan asinkron, LiveData untuk mempublikasikan hasil. Tidak ada StateFlow, tidak ada combine — hanya yang benar-benar diperlukan. Tambahkan StateFlow ketika aliran data searah (UDF) dengan status eksplisit diperlukan.

KISS di iOS: struktur sederhana alih-alih kelas

Di iOS prinsip KISS terwujud melalui preferensi struktur (struct) daripada kelas (class) untuk model data. Struktur adalah value type, tidak memerlukan manajemen memori melalui ARC, bersifat immutabel secara default. Kelas hanya dibenarkan ketika diperlukan identitas (dua referensi ke objek yang sama) atau pewarisan.

// KISS: struct alih-alih class untuk model
struct User: Codable {
    let id: Int
    let name: String
    let email: String
}

// Overengineering: class dengan init dan deinit manual
class UserClass: NSObject {
    let id: Int
    init(id: Int) { self.id = id }
}

Struktur User secara otomatis mendapatkan memberwise init, dukungan Equatable dan Hashable (di semua bidang), immutabilitas dan keamanan di lingkungan multi-thread. Kelas memerlukan init manual, implementasi NSObject dan rentan terhadap race conditions melalui status bersama.

Kesederhanaan di lapisan jaringan

Lapisan jaringan — area lain di mana KISS sering dilanggar. Pengembang menambahkan rantai Interceptor dengan 5+ elemen, serialisasi melalui pabrik abstrak dan mapper untuk setiap endpoint. Solusi KISS: satu URLSession dengan konfigurasi dan satu decoding melalui Codable/JSON.

Menurut rekomendasi Apple: URLSession Programming Guide (2023), lapisan jaringan sederhana di URLSession dengan Codable mencakup 95% skenario aplikasi mobile. Rantai Interceptor kompleks hanya diperlukan untuk kasus spesifik: penyegaran token, logging, enkripsi.

Mulailah dengan lapisan jaringan sederhana di URLSession + Codable. Tambahkan Interceptor berdasarkan kebutuhan nyata, bukan untuk jaga-jaga. Ini memperpendek kode lapisan jaringan 2–3 kali.

Kesalahan umum saat mengikuti KISS

Kebingungan antara kesederhanaan dan primitivitas

Kesederhanaan — tidak sama dengan primitivitas. Solusi sederhana itu ringkas, dapat dipahami dan menyelesaikan tugas tanpa redundansi. Primitif — mengabaikan best practices dan arsitektur yang sehat. Perbedaannya adalah bahwa solusi sederhana mudah diperluas, sedangkan yang primitif — tidak.

Contoh: menggunakan Activity sebagai satu-satunya entitas untuk semua layar — ini primitivitas, bukan kesederhanaan. Kesederhanaan — menggunakan Navigation Component dengan Fragment berbeda untuk layar berbeda, tetapi tanpa abstraksi yang tidak perlu. KISS tidak membenarkan arsitektur yang buruk.

Periksa diri Anda: dapatkah kode Anda berubah saat menambahkan fitur baru? Jika ya — kesederhanaannya tepat. Jika untuk setiap fitur harus menulis ulang semuanya — ini primitivitas, refactor segera.

Mengabaikan pola atas nama KISS

Pola (MVVM, MVI, Coordinator) — bukan komplikasi, tetapi penataan. KISS tidak melarang penggunaan pola arsitektur yang terbukti. Penggunaannya yang berlebihan dilarang: tiga pola di mana satu sudah cukup. Jalan tengah — satu pola arsitektur per proyek dan tidak lebih dari 2–3 pendukung (DI, Navigation).

Menurut State of Mobile Architecture Report (2024), proyek yang menggunakan tepat satu pola arsitektur memiliki 34% lebih sedikit bug di tahun pertama pengembangan dibandingkan proyek “frankenstein” dengan kombinasi 3+ pola. Pilih MVVM atau MVI untuk proyek mobile — dan patuhi di semua layar.

Jangan campur MVVM dan MVI dalam satu proyek. Jika tim memilih MVVM — seluruh proyek harus mengikuti MVVM. Pengecualian — modul fitur terpisah dengan solusi arsitektur sendiri, tetapi ini harus menjadi pilihan sadar.