Mengapa tidak boleh terlalu dini menghilangkan duplikasi kode
- Menerapkan prinsip DRY (Don't Repeat Yourself) terlalu ketat dapat memicu abstraksi "premature" yang justru membuat perubahan di masa depan menjadi lebih rumit
- Perlu dipikirkan apakah duplikasi itu benar-benar tidak perlu, atau justru merupakan fungsi yang akan berkembang secara mandiri seiring waktu
- Meski fungsi atau kelas terlihat sama, masing-masing bisa memiliki konteks dan kebutuhan bisnis yang berbeda
- Daripada sekadar memendekkan kode, lebih penting memikirkan apakah tujuan fungsi tersebut akan tetap relevan seiring waktu
- Risiko abstraksi: jika ada kemungkinan fitur berkembang secara berbeda, abstraksi justru bisa merugikan
- Saat merancang abstraksi, jangan terlalu dini menggabungkan perilaku yang dalam jangka panjang bisa berkembang secara terpisah
- Jika ragu, sebaiknya biarkan perilaku tetap terpisah sampai muncul pola umum yang cukup kuat untuk membenarkan penggabungannya seiring waktu
- Dalam skala kecil, mengelola duplikasi bisa lebih sederhana daripada menyelesaikan kompleksitas akibat abstraksi premature
- Pada tahap awal pengembangan, lebih baik mengizinkan sedikit duplikasi dan menunda abstraksi
- Kebutuhan masa depan sering kali sulit diprediksi
- Perlu mempertimbangkan prinsip YAGNI (You Aren't Gonna Need It)
- Bisa jadi duplikasi tidak akan menjadi masalah, atau seiring waktu akan makin jelas perlunya abstraksi yang benar-benar telah dipertimbangkan matang
10 komentar
Sejak awal, penerapan DRY seharusnya dilakukan dengan cara mengurangi sesuatu jika memang ada yang berulang,
tetapi jika memikirkan kode berdasarkan DRY sebagai tolok ukur sejak awal, rasanya itu adalah penerapan yang keliru.
Di antara pendapat di Hacker News,
kesalahpahaman tentang prinsip DRY: DRY bertujuan mencegah duplikasi informasi/pengetahuan, bukan duplikasi kode. Jika hanya berfokus pada duplikasi kode, itu bisa berujung pada optimasi yang tidak perlu.
Pendapat ini yang paling saya setujui.
Bukankah saat masa transisi kita sering punya kekhawatiran seperti itu? Karena tidak ada kode yang sempurna, mungkin memang pekerjaan kita adalah terus memikirkannya setiap hari. Sepertinya ini sangat tergantung kasusnya.
Belakangan ini cukup sering muncul tulisan yang memandang skeptis struktur dengan tingkat abstraksi tinggi.
MSA, clean code, SOLID, DRY, dan sebagainya...
Sepertinya orang-orang mulai merasa lelah dengan istilah-istilah seperti itu.
Padahal sebenarnya itu semua hanyalah penanda arah yang bisa dijadikan acuan saat kita memikirkan cara menulis kode yang mudah dibaca, mudah dipahami, tidak bocor memori, bebas error, dan cepat...
Tinggal diterapkan secukupnya, disesuaikan dengan situasi bisnis yang sedang kita hadapi saat ini.
https://velog.io/@kineo2k/…
Artikel yang sangat bagus.
Rasanya ini jadi semakin penting terutama saat beralih dari model waterfall ke model agile.
Sudah agile, tetapi masih terlalu berusaha memprediksi masa depan.
Seberapa terburu-burunya hingga disebut “terlalu cepat”?
Jawabannya terlalu mudah. Jika dilakukan begitu saja sejak awal, itu berarti "terlalu cepat".
Masalah yang sedikit lebih sulit adalah kapan melakukannya agar tidak "terlalu cepat".
Ini memang terdengar seperti permainan kata, tapi kalau dari awal memang tidak dilakukan, berarti jadinya tidak "terlalu cepat", ya ^^;
Ya, terutama dalam Agile
Komentar Hacker News
Penerapan awal prinsip DRY: Menerapkan prinsip DRY sejak awal itu baik. Menggunakan codebase bersama lebih efisien daripada menangani data serupa secara terpisah.
Prioritas best practice: Tidak semua best practice setara. Penting untuk memprioritaskan keterbacaan dan kohesi. Menulis kode adalah proses memilih praktik terbaik yang paling tepat.
Salah paham tentang prinsip DRY: DRY bertujuan mencegah duplikasi informasi/pengetahuan, bukan sekadar duplikasi kode. Jika hanya fokus pada duplikasi kode, hal itu bisa berujung pada optimasi yang tidak perlu.
Masalah reusabilitas: Ada kalanya fungsi tertentu tidak digunakan ulang dalam situasi lain. Diperlukan pendekatan yang lebih baik untuk menghindari kerja ganda.
Masalah dengan solusi DRY yang kompleks: Terkadang kode yang berulang lebih baik daripada solusi DRY yang rumit. Menerapkan DRY terlalu cepat bisa menimbulkan masalah struktural yang tak terduga.
DRY bukan best practice: Pengulangan sering kali merupakan sinyal bahwa abstraksi memang dibutuhkan. Penerapan DRY secara serampangan adalah kesalahan yang sering dilakukan engineer tingkat menengah.
Contoh kode sederhana: Dua fungsi bisa digabungkan menjadi satu fungsi. Penting untuk menjelaskan dengan jelas kelebihan dan kekurangan refactoring.
Masalah pemeliharaan pada kode DRY: Kode DRY bisa menjadi kompleks sehingga sulit dipelihara. Sebaliknya, kode WET sederhana tetapi perubahannya lebih mudah diprediksi.
Efek samping prinsip DRY: Prinsip DRY dapat membuat codebase menjadi kompleks dan sulit dipelihara. Beberapa buku clean code telah memberi dampak negatif pada industri.
Generalisasi dan performa: Generalisasi dapat berdampak negatif pada performa. Duplikasi kode yang disesuaikan dengan pola data tertentu bisa membantu optimasi performa.