DRY vs WET: Kapan Kode Harus Modular, Kapan Boleh Duplikat?

Kalau kamu sudah cukup lama ngoding, pasti pernah dengar istilah DRY (Don’t Repeat Yourself).
Prinsipnya sederhana: jangan menulis kode yang sama dua kali.

Tapi… di dunia nyata, terutama saat proyek mulai kompleks, terlalu fanatik terhadap DRY justru bisa jadi bumerang.
Kadang, menulis kode yang mirip tapi terpisah malah bikin lebih cepat dan mudah dibaca.
Nah, di sinilah muncul lawannya — WET (Write Everything Twice).

💡 Apa Itu DRY dan WET?

DRY (Don’t Repeat Yourself)
Artinya setiap pengetahuan atau logic sebaiknya hanya punya satu sumber kebenaran (single source of truth).
Tujuannya: kode lebih efisien, mudah dipelihara, dan minim bug.

WET (Write Everything Twice)
Sebuah istilah “parodi” yang berarti kadang duplikasi boleh dilakukan,
terutama jika:

kode belum stabil,
abstraksi belum jelas,
atau duplikasi justru membuat logika lebih mudah dipahami.

⚖️ Contoh Kasus Nyata

Misal kamu punya dua komponen React:

// Komponen untuk menampilkan daftar user
function UserList({ users }) {
  return users.map(user => <p>{user.name}</p>);
}

// Komponen untuk menampilkan daftar admin
function AdminList({ admins }) {
  return admins.map(admin => <p>{admin.name}</p>);
}

Dua-duanya mirip banget. Naluri pertama mungkin:

“Wah, harusnya disatukan biar gak duplikat — biar DRY dong!”

Lalu kamu bikin abstraksi:

function List({ items }) {
  return items.map(item => <p>{item.name}</p>);
}

Kedengarannya keren... sampai nanti salah satu butuh fitur tambahan seperti badge untuk admin, atau warna khusus untuk user.
Akhirnya kamu mulai tambal:

function List({ items, showBadge, color }) {
  return items.map(item => (
    <p style={{ color }}>
      {item.name} {showBadge && <Badge />}
    </p>
  ));
}

Dan… kode modularmu justru jadi makin ribet.
Kamu jatuh ke abstraksi prematur (premature abstraction) — salah satu “penyakit” dari DRY yang berlebihan.

🧠 Pendapat Pribadi Saya

Menurut saya, DRY itu penting, tapi bukan agama.
Saya lebih suka prinsip "Semidry" — alias kode boleh mirip selama tujuannya jelas dan mudah dibaca.

Daripada repot membuat abstraksi yang belum tentu berguna, lebih baik:

Tulis dulu kode yang berulang.
Lihat apakah duplikasi itu benar-benar mengganggu.
Baru refactor nanti kalau sudah terbukti butuh.

Biasanya, kalau logic-nya berubah lebih dari 2–3 kali di tempat berbeda, baru saat itu saya jadikan modul atau helper function.

⚙️ Kapan Harus Modular (DRY)

Gunakan prinsip DRY saat:

Logic sudah stabil dan jarang berubah.
Ada proses yang benar-benar identik di banyak tempat.
Kamu ingin menjaga konsistensi (misalnya format tanggal, validasi input).
Refactor-nya tidak mengorbankan keterbacaan.

🧩 Kapan Boleh Duplikat (WET)

Boleh duplikat jika:

Fitur masih dalam tahap eksplorasi.
Abstraksi justru bikin kode lebih susah dibaca.
Tim kamu belum sepakat soal arsitektur.
Duplikasi kecil mempercepat development tanpa mengorbankan stabilitas.

🏁 Kesimpulan

DRY itu bukan aturan keras, tapi pedoman sehat.
Kode yang terlalu kering kadang justru rapuh.
Kode yang sedikit basah (WET) tapi mudah dipahami — bisa jadi lebih “manusiawi”.

Jadi, tujuan akhirnya bukan sekadar “menghindari duplikasi”,
tapi menulis kode yang jujur terhadap tujuannya dan mudah dirawat oleh orang lain.