Rich Hickey & Clojure: Kesederhanaan, Imutabilitas, dan Pengaturan Bawaan yang Lebih Baik

Mengapa kompleksitas sering "menang" di proyek nyata\n\nPerangkat lunak jarang menjadi rumit sekaligus. Ia mencapai titik itu lewat satu keputusan “masuk akal” demi satu: cache cepat untuk mengejar tenggat, objek mutable bersama untuk menghindari menyalin, pengecualian aturan karena “yang ini istimewa.” Setiap pilihan terlihat kecil, tapi bersama-sama mereka menciptakan sistem di mana perubahan terasa berisiko, bug sulit direproduksi, dan menambah fitur mulai memakan waktu lebih lama daripada membangunnya.\n\nKompleksitas menang karena ia menawarkan kenyamanan jangka pendek. Seringkali lebih cepat menambahkan dependensi baru daripada menyederhanakan yang sudah ada. Lebih mudah menambal state daripada bertanya mengapa state tersebar di lima layanan. Dan menggoda untuk bergantung pada konvensi dan pengetahuan tribal saat sistem tumbuh lebih cepat daripada dokumentasi.\n\n### Apa yang artikel ini (dan bukan)\n\nIni bukan tutorial Clojure, dan kamu tidak perlu tahu Clojure untuk mendapat manfaat. Tujuannya adalah meminjam serangkaian gagasan praktis yang sering dikaitkan dengan karya Rich Hickey—gagasan yang dapat kamu terapkan pada keputusan rekayasa sehari-hari, tanpa memandang bahasa.\n\n### Mengapa pengaturan bawaan lebih penting dari yang kamu kira\n\nSebagian besar kompleksitas tidak dibuat oleh kode yang kamu tulis dengan sengaja; ia dibuat oleh apa yang alatmu permudah sebagai default. Jika default adalah “objek mutable di mana-mana,” kamu akan berakhir dengan kopling tersembunyi. Jika default adalah “state hidup di memori,” kamu akan kesulitan debugging dan keterlacakan. Default membentuk kebiasaan, dan kebiasaan membentuk sistem.\n\nKita akan fokus pada tiga tema:\n\n- Kesederhanaan: bukan lebih sedikit fitur, melainkan lebih sedikit bagian bergerak dan lebih sedikit kasus khusus.\n- Imutabilitas: memperlakukan data sebagai nilai yang tidak berubah, sehingga mudah ditalar.\n- Pengaturan bawaan yang lebih baik: memilih pola yang membuat opsi yang aman dan dapat diprediksi menjadi yang paling mudah.\n\nGagasan ini tidak menghilangkan kompleksitas dari domainmu, tetapi bisa mencegah perangkat lunakmu menggandakannya.\n\n## Rich Hickey dan apa yang ingin diperbaiki Clojure\n\nRich Hickey adalah pengembang dan perancang perangkat lunak berpengalaman yang paling dikenal karena menciptakan Clojure dan karena ceramahnya yang menantang kebiasaan pemrograman umum. Fokusnya bukan mengejar tren—melainkan alasan berulang mengapa sistem menjadi sulit diubah, sulit ditalar, dan sulit dipercaya saat mereka berkembang.\n\n### Apa itu Clojure (tingkat tinggi, tanpa jargon)\n\nClojure adalah bahasa pemrograman modern yang berjalan di platform terkenal seperti JVM (runtime Java) dan JavaScript. Ia dirancang untuk bekerja dengan ekosistem yang ada sambil mendorong gaya tertentu: merepresentasikan informasi sebagai data biasa, memfavoritkan nilai yang tidak berubah, dan memisahkan “apa yang terjadi” dari “apa yang ditampilkan di layar.”\n\nKamu bisa memikirkannya sebagai bahasa yang mendorongmu ke blok bangunan yang lebih jelas dan menjauh dari efek samping tersembunyi.\n\n### Masalah yang ingin dikurangi oleh Clojure\n\nClojure tidak dibuat untuk memendekkan skrip kecil. ia ditujukan pada rasa sakit proyek yang berulang:\n\n- Kompleksitas yang tumbuh dari state bersama: ketika banyak bagian sistem dapat memodifikasi data yang sama, bug menjadi tergantung waktu dan sulit direproduksi.\n- Kopling erat antara data dan perilaku: ketika informasi terkunci di dalam objek atau kelas, penggunaan ulang menjadi lebih sulit dan perubahan merambat ke seluruh basis kode.\n- Susahnya konkurensi: saat sistem menambahkan pekerjaan latar belakang, antrean, dan pekerjaan paralel, “siapa mengubah apa, kapan?” menjadi masalah harian.\n\nDefault Clojure mendorong lebih sedikit bagian bergerak: struktur data yang stabil, pembaruan eksplisit, dan alat yang membuat koordinasi lebih aman.\n\n### Berguna meski kamu tak pernah mengadopsi Clojure\n\nNilainya tidak terbatas pada mengganti bahasa. Gagasan inti Hickey—menyederhanakan dengan menghapus ketergantungan yang tak perlu, memperlakukan data sebagai fakta yang tahan lama, dan meminimalkan state yang dapat dimutasi—dapat memperbaiki sistem di Java, Python, JavaScript, dan seterusnya.\n\n## Kesederhanaan: bukan “mudah,” melainkan lebih sedikit bagian bergerak\n\nRich Hickey menarik garis tegas antara sederhana dan mudah—dan itu garis yang sering dilintasi proyek tanpa disadari.\n\n### Sederhana vs. mudah (dengan contoh sehari-hari)\n\nMudah tentang bagaimana sesuatu terasa saat ini. Sederhana tentang berapa banyak bagian yang dimilikinya dan seberapa erat mereka terjerat.\n\n- Mie instan itu mudah. Semur dasar bisa sederhana: beberapa bahan, satu panci, tak ada yang tersembunyi.\n- Remote dengan 60 tombol mungkin membuat satu fitur “mudah” (langsung terlihat), tapi itu tidak sederhana. Remote dengan 6 kontrol jelas lebih sederhana, meski perlu waktu untuk belajar.\n\nDalam perangkat lunak, “mudah” sering berarti “cepat untuk diketik hari ini,” sementara “sederhana” berarti “lebih sulit untuk rusak bulan depan.”\n\n### Bagaimana “mudah sekarang” menciptakan kompleksitas masa depan\n\nTim sering memilih jalan pintas yang mengurangi gesekan segera tapi menambah struktur tak terlihat yang harus dipelihara:\n\n- "Tambahkan flag saja." Sekarang setiap fitur perlu mempertimbangkan flag itu.\n- "Kita simpan nilai terhitung untuk menghemat waktu." Sekarang kamu harus menjaga sinkronisasi di berbagai jalur kode.\n- "Kita tambal di UI." Sekarang aturan bisnis yang sama ada di banyak tempat.\n\nSetiap pilihan mungkin terasa seperti kecepatan, tetapi meningkatkan jumlah bagian bergerak, kasus khusus, dan ketergantungan silang. Begitulah cara sistem menjadi rapuh tanpa satu kesalahan dramatis pun.\n\n### Kecepatan bukanlah kesederhanaan\n\nMeluncurkan cepat bisa sangat baik—tetapi kecepatan tanpa menyederhanakan biasanya berarti kamu berutang ke masa depan. Bunga hutang itu muncul sebagai bug yang sulit direproduksi, onboarding yang melambat, dan perubahan yang membutuhkan “koordinasi hati-hati.”\n\n### Daftar singkat untuk kompleksitas tidak disengaja\n\nAjukan pertanyaan ini saat meninjau desain atau PR:\n\n- Apakah kita memperkenalkan mode, flag, atau cabang konfigurasi baru?\n- Apakah kita melakukan caching atau menduplikasi data yang harus tetap konsisten?\n- Apakah beberapa modul perlu berubah bersama untuk satu perilaku?\n- Apakah aturan diimplementasikan di lebih dari satu tempat?\n- Apakah rekan baru bisa memprediksi cara kerjanya tanpa penjelasan tambahan?\n\n## State: pengganda diam-diam kompleksitas\n\n"State" sederhananya adalah hal-hal di sistemmu yang bisa berubah: keranjang belanja pengguna, saldo akun, konfigurasi saat ini, langkah alur kerja. Yang sulit bukan keberadaan perubahan—tetapi setiap perubahan menciptakan peluang agar hal-hal menjadi tidak sinkron.\n\nSaat orang bilang “state menyebabkan bug,” biasanya maksudnya: jika potongan informasi yang sama bisa berbeda pada waktu yang berbeda (atau tempat yang berbeda), maka kode harus terus menjawab, "Versi mana yang benar sekarang?" Salah menjawab menghasilkan kesalahan yang terasa acak.\n\n### Mutabilitas: perubahan yang tak bisa kamu lihat kembali\n\nMutabilitas berarti objek diedit di tempat: “benda” yang sama menjadi berbeda seiring waktu. Itu terdengar efisien, tetapi membuat penalaran lebih sulit karena kamu tak bisa percaya pada apa yang kamu lihat beberapa saat lalu.\n\nContoh yang bisa dirasakan adalah spreadsheet bersama. Jika banyak orang bisa mengedit sel yang sama bersamaan, pemahamanmu bisa segera tidak valid: total berubah, formula rusak, atau baris hilang karena seseorang merombak. Bahkan tanpa niat buruk, sifat "bersama dan bisa diedit" itulah yang menciptakan kebingungan.\n\nState perangkat lunak berperilaku sama. Jika dua bagian sistem membaca nilai mutable yang sama, satu bagian bisa diam-diam mengubahnya sementara yang lain terus memakai asumsi usang.\n\n### Mengapa debugging jadi menyakitkan\n\nState mutable mengubah debugging menjadi arkeologi. Laporan bug jarang mengatakan "data diubah secara salah pada 10:14:03." Kamu hanya melihat hasil akhir: angka salah, status tak terduga, permintaan yang kadang gagal.\n\nKarena state berubah seiring waktu, pertanyaan terpenting menjadi: urutan penyuntingan apa yang menghasilkan ini? Jika kamu tak bisa merekonstruksi sejarah itu, perilaku menjadi tak terduga:\n\n- Aksi yang sama menghasilkan outcome berbeda tergantung timing.\n- Perbaikan "berfungsi di mesin saya" tapi tidak di produksi.\n- Menambahkan logging mengubah timing dan bug menghilang.\n\nInilah mengapa Hickey memandang state sebagai pengganda kompleksitas: setelah data dibagi dan bisa dimutasi, jumlah interaksi yang mungkin bertambah lebih cepat daripada kemampuanmu untuk memahaminya.\n\n## Imutabilitas dijelaskan tanpa jargon ilmu komputer\n\nImutabilitas berarti data yang tidak berubah setelah dibuat. Alih-alih mengambil informasi yang ada dan mengeditnya di tempat, kamu membuat informasi baru yang merefleksikan pembaruan.\n\nPikirkan kwitansi: setelah dicetak, kamu tidak menghapus baris dan menulis ulang total. Jika sesuatu berubah, kamu keluarkan kwitansi koreksi. Yang lama masih ada, dan yang baru jelas "versi terbaru."\n\n### Mengapa ini mengurangi kejutan\n\nKetika data tidak bisa sunyi-senyap diubah, kamu berhenti khawatir tentang suntingan yang terjadi di belakang punggungmu. Itu membuat penalaran sehari-hari jauh lebih mudah:\n\n- Jika kamu memegang sebuah nilai, kamu bisa percaya ia tetap seperti itu.\n- Bug jadi lebih mudah direproduksi karena input tetap sama.\n- Berbagi data antar bagian sistem lebih aman karena tak ada yang bisa tak sengaja "mengacaukannya" untuk orang lain.\n\nInilah alasan besar mengapa Hickey bicara tentang kesederhanaan: lebih sedikit efek samping tersembunyi berarti lebih sedikit cabang mental yang harus dilacak.\n\n### “Versi baru” vs. “mengedit di tempat”\n\nMembuat versi baru bisa terdengar boros sampai kamu bandingkan dengan alternatifnya. Mengedit di tempat bisa membuatmu bertanya: "Siapa yang mengubah ini? Kapan? Apa sebelumnya?" Dengan data immutable, perubahan eksplisit: ada versi baru, dan versi lama tetap tersedia untuk debugging, audit, atau rollback.\n\nClojure menekankan kebiasaan ini dengan membuatnya alami untuk memperlakukan pembaruan sebagai menghasilkan nilai baru, bukan memutasi yang lama.\n\n### Tradeoff yang perlu jujur\n\nImutabilitas tidak gratis. Kamu mungkin mengalokasikan lebih banyak objek, dan tim yang terbiasa "langsung mengubah" hal mungkin butuh waktu menyesuaikan. Kabar baik: implementasi modern sering berbagi struktur di bawahnya untuk mengurangi biaya memori, dan imbalannya biasanya sistem yang lebih tenang dengan lebih sedikit insiden yang sulit dijelaskan.\n\n## Konkurensi jadi lebih mudah ketika data tidak berubah\n\nKonkurensi hanyalah "banyak hal terjadi sekaligus." Aplikasi web yang melayani ribuan permintaan, sistem pembayaran yang memperbarui saldo sambil membuat kwitansi, atau aplikasi mobile yang sinkron di latar—semua ini concurrent.\n\nYang rumit bukanlah banyaknya hal yang terjadi. Yang rumit adalah ketika mereka sering menyentuh data yang sama.\n\n### Mengapa data bersama yang bisa berubah menimbulkan race condition\n\nKetika dua pekerja dapat membaca lalu memodifikasi nilai yang sama, hasil akhir bisa bergantung pada timing. Itu adalah race condition: bukan bug yang mudah direproduksi, tetapi bug yang muncul saat sistem sibuk.\n\nContoh: dua permintaan mencoba memperbarui total pesanan.\n\n1. Permintaan A membaca total = 100\n2. Permintaan B membaca total = 100\n3. A menambah 20 dan menulis 120\n4. B menambah 10 dan menulis 110\n\nTak ada yang "crash", tetapi update hilang. Di bawah beban, jendela timing seperti ini jadi lebih umum.\n\nPerbaikan tradisional—lock, blok sinkronisasi, penentuan urutan hati-hati—bekerja, tetapi memaksa semua orang berkoordinasi. Koordinasi mahal: memperlambat throughput dan menjadi rapuh saat basis kode tumbuh.\n\n### Bagaimana imutabilitas mengurangi kebutuhan koordinasi\n\nDengan data immutable, sebuah nilai tidak diedit di tempat. Sebagai gantinya, kamu membuat nilai baru yang merepresentasikan perubahan.\n\nPerubahan sederhana ini menghilangkan satu kategori masalah:\n\n- Pembaca tak perlu khawatir bahwa yang mereka lihat akan berubah saat dibaca.\n- Penulis tak “bertengkar” atas memori yang sama; mereka menghasilkan versi baru.\n- Sistem bisa memilih cara aman untuk memublikasikan versi terbaru (sering kali dengan primitif sederhana yang sudah teruji).\n\n### Hasilnya: perilaku yang dapat diprediksi saat beban tinggi\n\nImutabilitas tak membuat konkurensi menjadi gratis—kamu masih perlu aturan tentang versi mana yang menjadi acuan. Tapi ia membuat program concurrent jauh lebih dapat diprediksi, karena datanya sendiri tidak lagi menjadi target yang bergerak. Saat traffic melonjak atau pekerjaan latar menumpuk, kemungkinan melihat kegagalan tergantung-timing yang misterius berkurang.\n\n## Apa maksud “pengaturan bawaan yang lebih baik” dalam praktik\n\n"Pengaturan bawaan yang lebih baik" berarti pilihan yang lebih aman terjadi otomatis, dan kamu hanya mengambil risiko ekstra saat kamu secara eksplisit memilih keluar.\n\nKedengarannya kecil, tapi default diam-diam membimbing apa yang ditulis orang pada hari Senin, apa yang reviewer terima pada Jumat sore, dan apa yang dipelajari rekan baru dari basis kode pertama mereka.\n\n### Default yang mengurangi risiko\n\n"Default yang lebih baik" bukan soal membuat setiap keputusan untukmu. Ini soal membuat jalur umum menjadi lebih tahan kesalahan.\n\nContoh:\n\n- Data immutable sebagai default: alih-alih "mengubah benda", kamu membuat versi barunya. Itu membuat lebih sulit secara tidak sengaja memengaruhi bagian program lain yang mengandalkan nilai lama.\n- Fungsi murni sebagai gaya normal: fungsi menerima input dan mengembalikan output tanpa diam-diam mengubah data bersama atau bergantung pada state global tersembunyi. Itu membuat perilaku lebih mudah diprediksi dan diuji.\n- Perubahan state yang eksplisit: ketika sesuatu harus berubah, itu terjadi melalui mekanisme yang jelas dan terdefinisi (daripada bagian manapun bisa memutasi apa saja).\n\nTidak satu pun dari ini menghilangkan kompleksitas, tetapi mereka mencegahnya menyebar.\n\n### Bagaimana default membentuk tim dan tinjauan kode\n\nTim tidak hanya mengikuti dokumentasi—mereka mengikuti apa yang "diinginkan" kode untuk kamu lakukan.\n\nSaat memutasi state bersama itu mudah, ia menjadi jalan pintas normal, dan reviewer berakhir berdebat soal niat: "Apakah ini aman di sini?" Saat imutabilitas dan fungsi murni adalah default, reviewer bisa fokus pada logika dan kebenaran, karena pola berisiko terlihat menonjol.\n\nDengan kata lain, default yang lebih baik menciptakan baseline yang lebih sehat: sebagian besar perubahan terlihat konsisten, dan pola yang tidak biasa cukup jelas untuk dipertanyakan.\n\n### Pemeliharaan dan onboarding\n\nPemeliharaan jangka panjang sebagian besar soal membaca dan mengubah kode yang ada dengan aman.\n\nDefault yang lebih baik membantu rekan baru naik level lebih cepat karena ada lebih sedikit aturan tersembunyi ("hati-hati, fungsi ini diam-diam memperbarui peta global itu"). Sistem menjadi lebih mudah ditalar, yang menurunkan biaya setiap fitur, perbaikan, dan refactor di masa depan.\n\n## Memisahkan fakta dari tampilan: waktu, sejarah, dan keterlacakan\n\nPeralihan mental yang berguna dalam ceramah Hickey adalah memisahkan fakta (apa yang terjadi) dari tampilan (apa yang kita yakini saat ini). Kebanyakan sistem mengaburkan keduanya dengan hanya menyimpan nilai terbaru—menimpa kemarin dengan hari ini—dan itu membuat waktu menghilang.\n\n### Fakta bersifat append-only; tampilan diturunkan\n\nSebuah fakta adalah catatan immutable: "Order #4821 dibuat pada 10:14," "Pembayaran berhasil," "Alamat diubah." Ini tidak diedit; kamu menambahkan fakta baru saat realitas berubah.\n\nSebuah tampilan adalah apa yang aplikasi butuhkan sekarang: "Apa alamat pengiriman saat ini?" atau "Berapa saldo pelanggan?" Tampilan bisa dihitung ulang dari fakta, dicache, diindeks, atau dimaterialisasi untuk kecepatan.\n\n### Mengapa menyimpan sejarah menguntungkan\n\nSaat kamu menyimpan fakta, kamu mendapat:\n\n- Auditabilitas: kamu bisa menjelaskan mengapa nilai saat ini seperti itu.\n- Debugging: kamu bisa memutar ulang urutan dan menemukan saat perbedaan terjadi.\n- Keterlacakan: "Siapa mengubah ini, kapan, dan apa sebelumnya?" menjadi pertanyaan data, bukan cerita detektif.\n\n### Contoh sederhana: menimpa vs menambahkan\n\nMenimpa catatan seperti memperbarui sel spreadsheet: kamu hanya melihat angka terbaru.\n\nLog append-only seperti buku cek: setiap entri adalah fakta, dan "saldo saat ini" adalah tampilan yang dihitung dari entri-entri itu.\n\n### Tidak semua sistem butuh event sourcing penuh\n\nKamu tidak harus mengadopsi arsitektur event-sourced penuh untuk mendapat manfaat. Banyak tim mulai lebih kecil: simpan tabel audit append-only untuk perubahan penting, simpan event perubahan untuk beberapa alur berisiko tinggi, atau pertahankan snapshot plus jendela sejarah singkat. Intinya adalah kebiasaan: perlakukan fakta sebagai tahan lama, dan perlakukan state saat ini sebagai proyeksi yang nyaman.\n\n## Data pertama: buat informasi tahan lama dan fleksibel\n\nSalah satu gagasan paling praktis dari Hickey adalah data first: perlakukan informasi sistem sebagai nilai biasa (fakta), dan perlakukan perilaku sebagai sesuatu yang kamu jalankan terhadap nilai-nilai itu.\n\nData itu tahan lama. Jika kamu menyimpan informasi yang jelas dan mandiri, kamu bisa menafsirkan ulang nanti, memindahkannya antar layanan, mengindeks ulang, mengauditnya, atau memasukkannya ke fitur baru. Perilaku kurang tahan lama—kode berubah, asumsi berubah, dependensi berubah.\n\n### Nilai vs aksi (tanpa jargon)\n\n- Data (nilai): "Apa yang benar?" Email pelanggan, total pesanan, timestamp, status.\n- Perilaku (aksi): "Apa yang kita lakukan?" Validasi, hitung diskon, kirim notifikasi, putuskan arti sebuah status.\n\nSaat kamu mencampur keduanya, sistem menjadi lengket: kamu tidak bisa menggunakan ulang data tanpa membawa serta perilaku yang membuatnya.\n\n### Kurangi kopling, tingkatkan reuse\n\nMemisahkan fakta dari aksi mengurangi kopling karena komponen bisa setuju pada bentuk data tanpa setuju pada jalur kode bersama.\n\nPekerjaan laporan, alat dukungan, dan layanan penagihan bisa mengkonsumsi data pesanan yang sama, masing-masing menerapkan logikanya sendiri. Jika kamu menyematkan logika ke dalam representasi yang disimpan, setiap konsumen menjadi bergantung pada logika itu—dan mengubahnya menjadi berisiko.\n\n### Contoh: menyimpan data bersih vs menyimpan mini-program\n\nData bersih (mudah berkembang):\n\n```json\n{

"type": "discount", "code": "WELCOME10", "percent": 10, "valid_until": "2026-01-31" } \n\n**Mini-program dalam penyimpanan** (sulit berkembang):\n\njson { "type": "discount", "rule": "if (customer.orders == 0) return total * 0.9; else return total;" }