Kenapa Nulis Kode Jadi Ribet Banget Sih?

Pernah nggak sih kamu ngerasa nulis kode yang seharusnya simpel malah jadi ribet banget? Kayak lagi bikin sesuatu yang sederhana, tapi malah muter-muter di labirin abstraksi yang nggak perlu.

Ini masalah klasik yang sering dialami programmer. Kita mulai dengan niat baik: bikin kode yang modular, reusable, dan clean. Tapi di tengah jalan, malah kebablasan.

Abstraksi bertumpuk-tumpuk. Interface saling bersilangan. Dan tiba-tiba kamu lupa apa tujuan awalnya. Sound familiar?

Masalahnya, komposisi itu konsep yang powerful banget. Tapi implementasinya sering kelewatan. Kita jadi obsessed sama 'flexibility' sampai lupa bahwa kode itu harus dibaca orang lain (atau diri sendiri tiga bulan lagi).

Ada prinsip sederhana yang sering dilupakan: compose, don't inherit. Tapi bahkan setelah paham ini, banyak yang masih salah arah.

Kita bikin hierarki class yang dalam banget. Atau nge-pass dependency sana-sini sampai nggak tau lagi siapa yang ngapain. Padahal komposisi itu seharusnya bikin hidup lebih mudah, nggak lebih susah.

Salah satu anti-pattern paling umum adalah premature abstraction. Kamu lihat potensi reuse di masa depan, jadi langsung bikin generic solution. Padahal kebutuhan sebenarnya belum jelas.

Hasilnya? Abstraksi yang ngambang, nggak grounded sama use case konkret. Dan ketika requirement berubah—which pasti terjadi—kode malah jadi kaku bukannya fleksibel.

Lalu gimana solusinya? Pertama, mulai dari concrete case dulu. Jangan langsung abstrak.

Tulis kode yang solve masalah spesifik kamu sekarang. Baru setelah pola muncul beberapa kali, kamu ekstrak abstraksinya. Ini yang disebut Rule of Three: tunggu sampai ada tiga duplikasi sebelum nge-refactor jadi generic.

Kedua, jaga supaya komposisi itu shallow. Artinya, objek yang kamu compose sebaiknya punya interface yang sederhana dan jelas.

Kalau kamu perlu ngeliat tiga layer abstrasi buat ngerti satu komponen, itu tandanya ada yang salah. Komposisi yang baik itu kayak LEGO: bloknya jelas fungsinya, dan pasangnya intuitif.

Ketiga, perhatiin data flow. Komposisi yang clean punya arah data yang jelas, nggak muter-muter.

Kalau kamu nge-trace satu data harus loncat-loncat file sana-sini, itu red flag. Struktur seharusnya mengikuti alur logika, nggak melawannya.

Practical takeaway-nya gini: next time kamu mau bikin abstraksi baru, tanya dulu ke diri sendiri. Apa ini solve masalah yang udah ada, atau masalah yang aku prediksi bakal ada?

Kalau jawabannya yang kedua, tahan dulu. Tulis versi concrete-nya. Biarkan repetisi terjadi—sementara. Baru abstraksi ketika polanya beneran stabil.

Ingat, kode yang gampang dihapus lebih berharga daripada kode yang gampang di-extend. Fleksibilitas sejati datang dari simplicity, bukan dari menumpuk layer abstraction.

Komposisi itu alat yang keren. Tapi seperti semua alat, bisa jadi berbahaya kalau dipakai tanpa pikir panjang. Pahami dulu masalahnya, baru pilih tools-nya.

Bukan sebaliknya: punya hammer, lalu lihat semua masalah kayak paku.