KISS, YAGNI, DRY: Tiga Prinsip yang Wajib Diketahui Setiap Developer

Kalau kita mulai belajar coding, fokusnya biasanya ke sintaks dan logika. Bagaimana cara bikin loop, cara kerja function, dan sebagainya. Tapi seiring waktu, kita mulai sadar bahwa menulis kode yang benar itu bukan hanya soal kode yang berjalan. Kode yang bagus juga harus mudah dibaca, mudah diubah, dan tidak membebani tim.

Di sinilah tiga prinsip ini masuk: KISS, YAGNI, dan DRY. Ketiganya bukan framework, bukan library. Hanya prinsip. Tapi dampaknya besar kalau kita konsisten menerapkannya.

KISS: Keep It Simple, Stupid

KISS artinya buat sesederhana mungkin. Bukan berarti kita bodoh. Justru sebaliknya, butuh keahlian lebih untuk membuat sesuatu yang sederhana dibanding yang kompleks. Masalahnya, banyak developer (termasuk yang sudah pengalaman) tergoda untuk menulis kode yang "canggih". Terlalu banyak abstraksi, terlalu banyak layer, padahal masalahnya sederhana.

Contoh mudahnya:

// Versi over-engineered
function getUserStatus(User $user) {
    $statusMap = [
        'active' => fn() => 'User aktif',
        'inactive' => fn() => 'User tidak aktif',
    ];

    if (isset($statusMap[$user->status])) {
        return $statusMap[$user->status]();
    }
    return 'Status tidak diketahui';
}

// Versi KISS
function getUserStatus(User $user) {
    if ($user->status === 'active') {
        return 'User aktif';
    }

    if ($user->status === 'inactive') {
        return 'User tidak aktif';
    }

    return 'Status tidak diketahui';
}

Keduanya menghasilkan output yang sama. Tapi yang kedua lebih mudah dibaca, mudah di-debug, dan lebih cepat dipahami orang lain.

Kapan KISS dilanggar?

Biasanya saat kita terlalu dini mengoptimasi sesuatu yang belum perlu dioptimasi. Atau saat kita ingin terlihat "pintar" lewat kode. Aturan praktisnya: kalau ada dua cara untuk melakukan sesuatu dan keduanya benar, pilih yang lebih mudah dibaca.

YAGNI: You Aren't Gonna Need It

YAGNI artinya jangan bikin fitur yang belum dibutuhkan sekarang. Ini sering terjadi saat kita sedang coding dan tiba-tiba punya ide: "Eh, nanti mungkin butuh fitur ini juga. Sekalian aja sekarang." Masalahnya, "nanti" itu sering tidak datang. Dan kode yang kita tulis untuk fitur tersebut tetap ada, tetap perlu di-maintain, dan tetap bisa jadi sumber bug.

Contohnya seperti ini:

// Kita diminta bikin fungsi kirim email
function sendEmail($to, $subject, $body) {
    // logika kirim email
}

// Tapi kita tambahkan ini "untuk jaga-jaga"
function sendEmail($to, $subject, $body, $cc = null, $bcc = null, 
                   $attachments = [], $priority = 'normal', 
                   $scheduleTime = null, $templateId = null) {
    // logika yang makin kompleks
}

Parameter cc, bcc, attachments, dan seterusnya mungkin tidak pernah dipakai. Tapi sekarang kita harus mikirin edge case untuk semuanya, nulis test untuk semuanya, dan mendokumentasikan semuanya. YAGNI mengajarkan kita untuk fokus ke apa yang dibutuhkan sekarang. Kalau nanti memang butuh, kita tambahkan nanti. Kode yang baik mudah untuk di-extend.

Kapan YAGNI dilanggar?

Paling sering saat estimasi kebutuhan masa depan tanpa dasar yang jelas. Kalau belum ada requirement nyata untuk fitur tersebut, jangan bikin.

DRY: Don't Repeat Yourself

DRY artinya setiap pengetahuan atau logika hanya boleh ada di satu tempat dalam codebase. Kalau kita menulis logika yang sama di dua tempat berbeda, dan suatu saat logika itu perlu diubah, kita harus ingat mengubahnya di dua tempat. Kalau lupa salah satu, muncul bug.

Contoh:

// Melanggar DRY
function getAdminUsers() {
    return User::where('role', 'admin')
               ->where('is_active', true)
               ->get();
}

function getAdminCount() {
    return User::where('role', 'admin')
               ->where('is_active', true)
               ->count();
}

// Versi DRY
function activeAdmins() {
    return User::where('role', 'admin')
               ->where('is_active', true);
}

function getAdminUsers() {
    return activeAdmins()->get();
}

function getAdminCount() {
    return activeAdmins()->count();
}

Sekarang kalau kondisi "admin aktif" berubah, kita cukup edit di satu tempat saja. DRY bukan hanya soal kode. Ini juga berlaku untuk dokumentasi, konfigurasi, dan data. Kalau ada satu sumber kebenaran, kita tidak perlu khawatir data atau logika yang tidak sinkron.

Kapan DRY dilanggar?

Saat kita copy-paste kode tanpa membuat abstraksi. Itu sinyal paling jelas.

Ketiganya Saling Melengkapi

KISS, YAGNI, dan DRY bukan aturan yang berdiri sendiri. Ketiganya bekerja bersama.

• KISS mencegah kita menulis kode yang terlalu rumit
• YAGNI mencegah kita menulis kode yang belum perlu
• DRY mencegah kita menduplikasi kode yang sudah ada

Kalau kita pegang ketiganya, hasilnya adalah codebase yang ramping, mudah dibaca, dan mudah di-maintain. Satu catatan penting: prinsip ini adalah panduan, bukan hukum mati. Ada situasi di mana sedikit duplikasi lebih baik dari abstraksi yang dipaksakan. Ada saatnya kita perlu mempersiapkan fondasi untuk fitur yang jelas akan datang. Tapi secara umum, kalau kita ragu, pegang prinsip ini. Lebih mudah menambah kompleksitas nanti daripada menyederhanakan kode yang sudah terlanjur rumit.

Penutup

Tiga prinsip ini sederhana, tapi butuh latihan untuk benar-benar terbiasa menerapkannya. Mulai dari hal kecil: sebelum nulis kode baru, tanya ke diri sendiri tiga pertanyaan ini.

• Apakah ini sesederhana mungkin? (KISS)
• Apakah ini benar-benar dibutuhkan sekarang? (YAGNI)
• Apakah logika ini sudah ada di tempat lain? (DRY)

Kalau jawaban ketiga pertanyaan itu sudah baik, biasanya kode yang kita tulis pun akan baik.