Beban kognitif itu penting

 (github.com/zakirullin)
10 poin oleh GN⁺ 2025-08-31 | 1 komentar | Bagikan ke WhatsApp
  • Proyek open source ini merangkum secara sistematis berbagai cara dan contoh untuk mengurangi beban kognitif dalam pengembangan perangkat lunak
  • Kode, struktur, dan abstraksi yang rumit tanpa perlu menghambat produktivitas developer dan meningkatkan biaya pemeliharaan
  • Untuk modul, yang lebih diinginkan bukan “kecil dan dangkal”, melainkan struktur yang dalam dengan antarmuka sederhana dan fungsi yang kuat
  • Abstraksi berlebihan, ketergantungan pada framework, dan penyalahgunaan prinsip DRY justru menjadi penyebab meningkatnya beban kognitif
  • Arsitektur terbaik adalah codebase yang sederhana dan bisa cepat dipahami bahkan oleh developer baru

Ringkasan proyek dan maknanya

Materi open source di GitHub ini berfokus pada ‘beban kognitif (cognitive load)’ sebagai salah satu prinsip inti dalam pengembangan perangkat lunak. Ciri paling menonjol dari repositori ini adalah kemampuannya merangkum sumber kompleksitas yang benar-benar dihadapi developer dalam praktik, beserta berbagai contoh dan cara mengatasinya, terlepas dari ukuran tim maupun tren teknologi. Berbeda dari materi lain yang berpusat pada best practice semata, materi ini juga mempertimbangkan beban psikologis dan kognitif, sehingga memberi keunggulan nyata dalam pemeliharaan serta onboarding anggota tim baru.

Pendahuluan

  • Konsep trendi atau best practice yang sering kita dengar di lapangan pengembangan kerap gagal dalam praktik nyata
  • Penyebab utama kebingungan yang dirasakan di pekerjaan sehari-hari, beserta kerugian waktu/biaya yang ditimbulkannya, adalah beban kognitif yang tinggi
  • Developer menghabiskan lebih banyak waktu untuk memahami dan membaca daripada menulis kode
  • Tulisan ini berfokus pada cara-cara praktis untuk mengurangi beban kognitif yang tidak perlu (Extraneous Cognitive Load)

Apa itu beban kognitif

  • Beban kognitif berarti jumlah informasi yang harus disimpan developer di dalam kepala untuk menyelesaikan pekerjaan
  • Rata-rata, manusia hanya dapat menyimpan sekitar 4 ‘chunk informasi’ (kondisi, nilai variabel, dan sebagainya) dalam memori jangka pendek pada satu waktu
  • Saat beban kognitif mencapai ambang batas, pemahaman dan kecepatan pengembangan akan menurun drastis

Jenis-jenis beban kognitif

  • Beban kognitif intrinsik (Intrinsic): berasal dari tingkat kesulitan hakiki dari pekerjaan itu sendiri. Tidak bisa dikurangi
  • Beban kognitif yang tidak perlu (Extraneous): berasal dari kompleksitas buatan seperti cara penyajian informasi, desain struktur, atau pola yang tidak perlu. Ini bisa dikurangi secara aktif

Contoh praktis dan cara perbaikan

Kondisional yang kompleks

  • Kode dengan banyak kondisi bertingkat menambah hal-hal yang harus diingat di tiap tahap, sehingga meningkatkan beban kognitif
  • Solusi: perkenalkan variabel antara yang bermakna agar tujuan tiap kondisi terbagi dengan jelas

if bertingkat vs Early Return

  • Dibandingkan if bertingkat, pola Early Return mengurangi beban mengingat prasyarat
  • Ini membebaskan ruang memori kerja karena kita cukup mengingat ‘happy path’ saja

Efek samping struktur pewarisan

  • Sistem pewarisan yang dalam (misalnya: kelasA → kelasB → kelasC …) mengharuskan banyak informasi lapisan diingat sekaligus untuk memahami kode, sehingga beban kognitif melonjak
  • Solusi: utamakan composition, gunakan komposisi alih-alih pewarisan yang tidak perlu

Terlalu banyak modul/fungsi dangkal

  • Dibanding 80 kelas kecil dan dangkal, deep module dengan beberapa antarmuka yang kuat dan sederhana jauh lebih mudah dipelihara
  • Sebagai contoh, disebutkan antarmuka sederhana UNIX I/O: open, read, write, lseek, close

Salah paham terhadap 'Single Responsibility Principle'

  • Tafsir yang kabur atas ‘hanya melakukan satu hal’ justru menghasilkan banyak abstraksi dangkal dan tidak jelas
  • Dalam praktiknya, prinsip ini lebih tepat dimaknai sebagai ‘bertanggung jawab kepada satu pemangku kepentingan’ agar pemahaman kaitan bisnis meningkat dan beban kognitif berkurang

Penyalahgunaan microservices

  • Terlalu banyak microservice dangkal membuat hubungan antar-layanan dan informasi integrasinya harus terus disimpan di kepala, sehingga beban kognitif serta biaya debugging/peluncuran meningkat
  • Pada tahap awal, struktur monolitik yang matang justru lebih menguntungkan untuk pemeliharaan

Fitur/opsi bahasa yang berlebihan

  • Banyaknya fitur baru dalam bahasa itu sendiri (terutama C++ dan sejenisnya) justru menambah beban ingatan karena developer harus menelusuri ‘mengapa ini diimplementasikan seperti ini’
  • Ini memperbanyak beban kognitif tambahan yang tidak terkait bisnis

Pemetaan kode status HTTP dan logika bisnis

  • Pemetaan sewenang-wenang antara kode status HTTP (401, 403, 418, dll.) dan makna bisnis internal berarti seluruh anggota tim harus menghafalnya
  • Perbaikan: gunakan kode string yang self-explanatory (misalnya, "jwt_has_expired") secara konsisten

Penyalahgunaan prinsip DRY (Do not repeat yourself)

  • Dalam codebase yang kompleks, jika hanya memaksakan penghapusan duplikasi, ketergantungan kuat akan muncul dan justru meningkatkan beban kognitif serta biaya perubahan
  • Tulisan ini mengutip pernyataan terkenal Rob Pike bahwa ‘sedikit penyalinan secara lokal’ bisa jadi lebih baik

Ketergantungan pada framework dan dampak buruk Layered Architecture

  • Jika terlalu bergantung pada struktur ‘ajaib’ milik framework, developer baru akan membutuhkan waktu lama untuk memahami logika internal
  • Penumpukan layer abstraksi menyebabkan lonjakan besar beban kognitif saat menelusuri masalah nyata
  • Yang perlu difokuskan adalah prinsip-prinsip dasar seperti Dependency Inversion, Info Hiding, dan pengendalian Cognitive Load

Salah paham terhadap Domain-Driven Design (DDD)

  • Inti DDD adalah analisis domain masalah; obsesi pada struktur folder/pola justru memicu tafsir subjektif dan beban kognitif
  • Framework seperti ‘Team Topologies’ lebih efektif untuk membagi beban kognitif

Keakraban vs kesederhanaan

  • Keakraban tidak sama dengan kesederhanaan. Sesuatu terasa ringan karena sudah terbiasa, bukan karena strukturnya memang mudah
  • Jika karyawan baru merasa bingung lebih dari 40 menit, itu adalah sinyal bahwa kode perlu diperbaiki

Contoh sukses/gagal nyata

  • Seperti Instagram, arsitektur monolitik yang sederhana pun bisa memberi pengalaman skalabilitas dan pemeliharaan yang tinggi
  • Perusahaan yang memiliki “developer yang sangat pintar” dan membangun struktur kompleks justru sering mengalami kegagalan
  • Struktur yang bisa dibaca dengan mudah dan memungkinkan onboarding cepat bagi semua developer memainkan peran kunci dalam peningkatan produktivitas

Kesimpulan

  • Beban kognitif yang tidak perlu, di luar pekerjaan yang memang esensial, merugikan semua pihak yang terlibat dalam pengembangan
  • Kode terbaik adalah kode yang bisa dipahami secepat mungkin oleh developer lain di masa depan maupun oleh diri sendiri
  • Dibanding struktur yang “terlihat pintar”, solusi yang biasa dan lugas lebih menguntungkan dalam jangka panjang untuk pemeliharaan dan produktivitas tim

Referensi/ulasan

  • Juga dikutip pendapat dari Rob Pike, Andrej Karpathy, Elon Musk, Addy Osmani, antirez (developer Redis), dan developer terkenal lainnya
  • Menyajikan implikasi yang sejalan dengan kasus nyata berskala besar seperti Chromium, Redis, dan Instagram
  • Kesederhanaan, kejelasan, dan pengurangan beban kognitif adalah inti dari keberlanjutan perangkat lunak

Nilai dari proyek open source ini

  • Materi yang berfokus pada pengalaman developer di dunia nyata dan contoh praktis, yang sering terlewat dalam banyak buku desain perangkat lunak atau pola
  • Memberikan bantuan nyata yang langsung bisa diterapkan untuk berbagai tim dalam onboarding developer, review arsitektur, dan pemeliharaan jangka panjang
  • Berfungsi sebagai checklist untuk meninjau kembali kode melalui kerangka yang jelas bernama ‘beban kognitif’

Bacaan terkait

1 komentar

 
GN⁺ 2025-08-31
Komentar Hacker News

  • Pencerahan terbesar saya datang dari buku A Philosophy Of Software Design karya John Ousterhout, buku terbaik tentang topik ini dan sangat saya rekomendasikan untuk dibaca para developer. Intinya, tujuan desain perangkat lunak haruslah meminimalkan kompleksitas, dan kompleksitas di sini didefinisikan sebagai "seberapa sulit untuk diubah", sementara "kesulitan" itu ditentukan oleh beban kognitif yang dibutuhkan untuk memahami kode

    • Masalahnya, tidak ada aturan yang pada akhirnya bisa menggantikan penilaian, pengalaman, dan intuisi. Semua aturan bisa jadi alat untuk berdebat, dan Anda tidak akan pernah menang dalam debat arsitektur. Alasan tulisan ini bagus adalah karena orang yang tidak membutuhkannya sudah tahu, dan bagi orang yang benar-benar membutuhkannya, isinya tidak akan dipahami. Pada akhirnya ini bukan masalah teknis, melainkan masalah manusia dan budaya. Arsitektur pada akhirnya mengikuti manusia dan budaya. Seperti Go lahir karena ada Rob Pike dan Google, Anda tidak akan melahirkan bahasa seperti Go hanya dengan membaca satu buku

    • Saya rasa prinsip DRY (jangan mengulang) adalah prinsip yang baru layak dipertimbangkan setelah Anda benar-benar memahami aplikasinya dan sudah membuat beberapa versi. Pada awalnya justru perlu mengulang agar lebih dulu memahami ruang masalahnya, lalu di versi kedua baru mulai memikirkan agar mudah dirawat. Mungkin baru di versi ketiga DRY pantas diterapkan

    • Sangat sulit mendapatkan buku ini tanpa memberi uang ke Jeff Bezos. Kalau ada yang kenal penulisnya, John, saya harap masalah ini bisa disampaikan. Tidak ada di toko buku kampus, toko buku lokal, bahkan Powell’s juga tidak punya

    • Saya sudah lama menyerah mencari solusi perangkat lunak yang sempurna. Rasanya tidak ada seorang pun yang benar-benar berhasil merapikannya secara sempurna. Pada akhirnya senjata terbaik yang kita punya adalah kebijaksanaan dan pengalaman manusia. Konteks, industri, dan tim terlalu berbeda untuk bisa didefinisikan rapi lewat angka atau hukum. Jadi tujuan saya dalam desain adalah mencari keseimbangan antara "berantakan" dan "indah". Bagian tersulitnya adalah bisnis itu tidak pasti sementara perangkat lunak itu deterministik, jadi kebutuhan bisnis selalu berubah dan sulit menyesuaikannya dengan kekakuan sistem komputer. Akhir-akhir ini saya hanya mencoba refactor kalau saya benar-benar merasakan ketidaknyamanan saat hendak mengubah kode. Itupun saya hanya merapikan seminimal mungkin. Dari refactor kecil yang berulang-ulang seperti ini, kadang pola baru muncul dan kemudian bisa diangkat menjadi abstraksi

    • Buku ini memang yang terbaik untuk topik tersebut. Tulisan itu juga terinspirasi dari buku ini. Saya juga pernah berdiskusi satu dua hal dengan John tentang isi tulisannya

  • Kemampuan menulis kode yang mengurangi beban kognitif orang lain adalah skill yang sangat langka dan sulit. Sekalipun punya bakatnya, tetap butuh usaha konsisten. Pada akhirnya pekerjaan developer adalah memampatkan ide inti agar hanya esensinya yang terlihat, dan hanya mengekspos kompleksitas yang memang perlu. Saya hampir tidak pernah melihat orang yang benar-benar jago dalam hal ini

    • Kode yang benar-benar bagus pada akhirnya membuat orang berpikir, "Apa ini memang dari awal masalah yang mudah?" Sebaliknya, kode seperti "rumah kartu" yang kompleksitasnya kelihatan jelas justru mendapat pengakuan sebagai jejak kerja keras dan bahkan bisa berujung promosi

    • Ini juga berlaku persis sama pada desain antarmuka maupun UX/interaksi. Developer jauh lebih mampu menahan beban kognitif dibanding orang biasa, tetapi untuk membuat sesuatu yang mudah dipakai oleh non-teknis, Anda harus keluar dari intuisi developer Anda sendiri, dan itu sangat sulit. Mendesain alat agar pengguna umum bisa menyelesaikan masalah kompleks secara intuitif itu benar-benar sulit

    • Kebanyakan abstraksi tidak bertahan baik saat kebutuhan berubah. Framework yang saya sukai paham bahwa mereka tidak akan pernah bisa membuat lapisan abstraksi yang sempurna selamanya, jadi mereka sengaja menyediakan "jalan keluar". (Contoh: memberi direct reference ke elemen HTML dalam framework web UI) Kebijaksanaan pentingnya adalah sadar bahwa masa depan tidak bisa diprediksi sempurna

    • Pada praktiknya, skill seperti ini di banyak perusahaan bukan kebutuhan utama, melainkan bonus. Lihat saja codebase utama mereka, itu sudah cukup menjelaskan

  • Saya menganggap diri saya salah satu "developer pintar yang agak nyentrik". Saya suka membangun abstraksi. Saya merasa aneh sekaligus khawatir melihat industri belakangan ini bergerak ke "arsitektur tumpukan if". Saya paham kenapa banyak orang menyukainya: kelihatan sederhana, mudah dipahami, dan Anda tinggal menutup tiket yang diberikan. Sebagian besar proses development bergantung pada tumpukan if, dan pendekatan ini memang bekerja cukup baik sampai level kasus tertentu. Bahkan ketika terjadi kebocoran data pribadi besar-besaran pun, jarang ada yang benar-benar dimintai tanggung jawab. Masalahnya, saya sendiri tidak tahu apakah ada alternatif yang lebih baik. Abstraksi mewah atau arsitektur keren tampaknya juga tidak benar-benar meningkatkan konsistensi kode. Khususnya di lingkungan perusahaan, pemilik logika bisnis hampir tidak benar-benar peduli pada logikanya, jadi Anda tidak pernah bisa membangun abstraksi yang rapi dengan hati-hati. Pada akhirnya ada kebutuhan seperti "pesanan hanya dikirim ke satu alamat", lalu tiba-tiba berubah menjadi "pelanggan besar minta dikirim ke beberapa alamat", dan dalam kekacauan seperti ini rasanya mustahil ada abstraksi yang bebas bug. Kadang saya sampai berpikir, mungkin untuk perangkat lunak enterprise, tumpukan if memang solusi terbaik

    • Untuk pertanyaan apakah pendekatan "tumpukan if" itu yang terbaik, saya merekomendasikan paper Big Ball of Mud dan ringkasannya. Sistem nyata selalu berevolusi: awalnya dimulai sebagai "gumpalan lumpur", lalu sebagian-bagiannya diperbaiki, lalu ketika perubahan baru datang, abstraksi yang tadinya indah runtuh lagi. Intinya adalah membesarkan sistem lewat kombinasi pemodelan domain, abstraksi secukupnya, dan perubahan destruktif yang memang diperlukan, seperti kota kecil yang tumbuh menjadi kota besar

    • Anda tetap bisa membuat abstraksi keren di perangkat lunak seperti ini, tetapi begitu logika bisnis ikut campur, menjaganya tetap utuh menjadi sulit. Bagian yang biasanya masih punya abstraksi yang baik adalah aspek produk seperti autentikasi, perizinan, log, database, middleware, infrastruktur, dan sejenisnya. Begitu logika internal bisnis mulai memengaruhi abstraksi, semuanya akan kembali berantakan. Di beberapa tempat bahkan logikanya dikelola langsung oleh orang bisnis, dan hasilnya jadi sulit diuji, tidak bisa dipahami, bahkan tidak bisa disimulasikan. Akhirnya tetap butuh operator, sampai junior developer menulis kode lewat alat grafis. Sudah di-rewrite berkali-kali pun, 2–3 tahun kemudian selalu kembali kacau

    • Orang bisnis tidak akan pernah bisa menjelaskan logika bisnis secara sempurna kepada implementornya. Mereka mungkin memahaminya sendiri, tetapi tidak bisa mengekspresikannya dari sudut pandang coding. Justru minimal harus ada satu implementor yang benar-benar mengalami langsung menjadi pengguna agar bisa memahami dengan tepat. Realitasnya, perusahaan memaksa pemisahan antardepartemen, dan "logika bisnis" menjadi wilayah yang tidak benar-benar diperhatikan, sehingga akhirnya yang dimanipulasi hanya if statement

    • Intinya, realitas itu sendiri—yakni bisnis—sudah merupakan tumpukan if. Kalau masalah atau domainnya jelas bersifat teknis atau bisa digeneralisasi, abstraksi memang bisa mengurangi if. Tetapi kalau domainnya sendiri kacau, maka abstraksi pun akhirnya harus dibangun dengan "fleksibilitas" sebagai sifat dasarnya. Kontradiksi bahkan bisa menjadi fitur

    • Kalau bermain-main dengan alat seperti Codex CLI, Anda akan melihat alat ini selalu membuat patch if khusus untuk kasus tertentu saat menemukan bug. Kecuali Anda secara eksplisit memberi tahu polanya dan meminta abstraksi baru, alat ini akan terus menambahkan if yang mereka sebut "heuristik". Untuk 10 bug dari tipe tertentu, akan dibuat 10 patch, dan ketika bug ke-11 yang mirip muncul, jelas tidak akan bekerja. Solusi yang diajukan Codex pada akhirnya adalah kumpulan pengulangan if

  • Saya bertanya-tanya seberapa sering dalam dunia nyata orang diminta memodifikasi proyek yang sama sekali tidak mereka kenal. Kalau perpindahan proyek tidak terlalu sering, mungkin hanya sekali tiap dua tahun. Menurut saya lebih baik fokus pada masalah yang benar-benar sulit, bukan sekadar kekurangan pengalaman

  • Selama 8 tahun bekerja di organisasi developer Microsoft, pemodelan tipe engineer pada masa awal sangat berguna. Ada tiga persona, lalu belakangan diganti framework yang lebih kompleks. Meski begitu, persona awal itu sampai sekarang tetap sangat membantu saya berkomunikasi efektif dengan engineer lain sepanjang karier saya.

    • Mort: engineer pragmatis, hasil bisnis adalah prioritas utama. Kalau tumpukan if bisa cepat jalan, itu sudah cukup.
    • Elvis: inovasi adalah prioritas, suka memakai teknologi terbaru, dan ingin kejeniusannya diketahui. Terobsesi pada framework baru, kode yang tidak stabil, visibilitas, dan inovasi.
    • Einstein: terobsesi pada performa, keanggunan, dan ketepatan teknis. Lebih mementingkan konsistensi kode dan kesempurnaan teknis. Dalam praktiknya semua engineer adalah campuran dari ketiganya. Dari beberapa PR dan review desain saja biasanya sudah cukup untuk menebak kecenderungan utamanya

    • Saya rasa harus ada juga tipe engineer bernama Amanda. Setelah 20 tahun mereview kode berantakan milik sendiri dan orang lain, ia akhirnya benar-benar menghayati bahwa kode di atas segalanya ditulis untuk dibaca manusia. Saya ingin membentuk tim yang hanya berisi Amanda seperti itu

    • Mort itu pragmatis, Einstein perfeksionis, dan Elvis... sejujurnya saya anggap lebih banyak mudaratnya untuk proyek. Sedikit banyak memang memotivasi, tetapi tim ideal adalah campuran Mort dan Einstein yang pas. Harus dibuat sesederhana yang diperlukan, tapi juga cukup akurat agar maintenance tidak menyiksa. Bahkan kalau Mort diberi proyek jangka panjang, lama-lama ia akan mulai peduli seperti Einstein. Sedikit keluar topik, coding agent otomatis belakangan ini terlalu kuat sifat Mort-nya, sampai saya justru harus mengelolanya sebagai Mort

    • Persona adalah alat yang bagus. Dalam pengalaman saya, seiring waktu ia sering berubah jadi jalan pintas yang keliru. Elvis pada praktiknya sebenarnya istilah politik internal, dan seperti hukum Goodhart, karena tampak masuk akal secara logis, semua orang mulai memakainya dalam debat sehingga kegunaannya menurun. Alan Cooper dulu memperkenalkan konsep persona bersamaan dengan pengembangan Visual Basic. Penting untuk memahami sudut pandang yang berbeda dari kita—misalnya ilmuwan dan developer firmware bisa memiliki nilai yang sangat berbeda. Buku terkait

    • Saya rasa engineer terbaik adalah orang yang mampu menyesuaikan ketiga kecenderungan itu sesuai proyek, situasi, dan tujuan pribadinya. Tiap peran membutuhkan komposisi yang berbeda. Misalnya optimisasi compiler lebih membutuhkan Einstein dan Mort, sedangkan kode seperti game engine akan berbeda lagi proporsinya. Detail tiap sifatnya masih bisa diperdebatkan, tetapi intinya semua orang perlu bergerak berbeda seiring waktu

    • Saya rasa pendekatan ini perlu batasan. Mengategorikan orang terlalu sederhana bisa menjadi bentuk pelabelan yang tidak adil dan permanen. Dari pengalaman saya, justru manajemen lebih suka Mort daripada Elvis. Solusi nyatanya ada pada leadership dan manajemen. Jika standar kualitas kode dimasukkan ke dalam requirement untuk Mort, hasilnya bisa tetap layak walaupun sedikit lebih lambat. Elvis perlu dibatasi, sementara Einstein perlu diberi tenggat yang pragmatis dan jelas. Pendekatan ini memang punya keterbatasan karena mengabaikan kompleksitas manusia

  • Saya khawatir AI akan merusak industri perangkat lunak. AI tidak punya keterbatasan manusia, jadi bisa menulis kode yang sangat kompleks dan sulit dibaca tetapi tetap berjalan, lalu ketika akhirnya rusak tidak ada yang bisa memperbaikinya. Karena itu saya menyarankan engineer junior agar tidak hanya bergantung pada AI, tetapi juga mempelajari karakter codebase mereka. Kalau tidak, mereka bisa kehilangan kemampuan untuk menulis kode sendiri

    • Saya rasa argumen ini tidak terlalu meyakinkan, karena AI bisa memperbaikinya lagi saat berhenti bekerja

    • Dalam pengalaman saya, saya selalu meminta AI terus menyederhanakan kode sampai saya benar-benar bisa memahaminya. Kalau terlalu kompleks, saya minta dibuat lebih sederhana; kalau memakai library eksternal yang tidak perlu, saya minta dibuang dan diganti stdlib atau hanya dependency yang sudah ada. AI menulis kode untuk saya, bukan untuk dirinya sendiri

    • Justru karena AI mengurangi beban kognitif pada desain level rendah, saya bisa lebih fokus memikirkan arsitektur tingkat atas, jadi kualitas perangkat lunak mungkin malah bisa meningkat

  • Soal "kebiasaan khas developer pintar" yang disebut di tulisan itu, saya menangkapnya seolah penulis hanya bisa memahami kode yang ia tulis sendiri atau yang ditulis dengan gayanya. Namun rahasia sebenarnya untuk mengurangi beban kognitif adalah meminimalkan jumlah kode yang perlu dibaca. Batas yang kuat dan API yang jelas membuat perubahan lebih mudah, dan yang penting bukan keseluruhan kode, melainkan hanya kompleksitas yang berasal dari antarmuka yang terdefinisi dengan baik. Keanehan "developer pintar" itu justru tampaknya hanya masalah permukaan

    • Menurut saya ini adalah kelebihan terbesar konsep microservices. Kalau dua tim hanya berkomunikasi lewat API, dan batasannya didefinisikan ketat dengan alat seperti schema, mereka akan menjadi sangat konservatif terhadap perubahan dan berpikir jauh lebih mendalam sebelumnya. Rasanya seperti secara teknis menyisipkan gesekan buatan pada titik yang memang Anda ingin tetap stabil

    • Saat debugging, saya sering merasa sangat melelahkan kalau ada bagian yang terlalu dioptimalkan untuk kode yang harus di-debug langsung dari call stack. Karena itu kalau bagian tertentu dipisah menjadi fungsi tersendiri dan commit-nya juga dipisah, perubahan kode yang tidak diinginkan jadi lebih mudah di-rollback dan fokus kodenya lebih tinggi. Mungkin di PR semuanya tetap masuk sekaligus, tapi kalau batasnya jelas hasilnya jauh lebih baik

    • Developer umumnya tidak terlalu pandai berpikir dalam istilah "kontrak dan antarmuka". Mereka harus dipaksa untuk hanya melihat janji yang tampak dari luar, bukan implementasi internal. Targetnya adalah bisa memahami tanpa harus membaca kodenya. Kalau untuk memahami kode saya orang harus benar-benar masuk dan membacanya, berarti saya gagal

    • Sejelas apa pun API-nya, kode internal belum tentu mudah dipahami. Dari luar mungkin tampak berfungsi baik, tetapi dalam praktiknya sering kali Anda tetap harus menyelam sampai ke dalam

  • Saya sangat suka tulisan ini karena merangkum pengalaman saya dengan sangat baik. Sebagian besar metodologi pemrograman yang saya pelajari secara formal justru berbalik merugikan saat orang lain harus membaca kode saya. Kode yang menyembunyikan terlalu banyak kompleksitas seperti Rust dan C++ terasa berat, sementara melihat struktur seperti C yang tidak memungkinkan kode disembunyikan di balik 6 lapis template justru membuat saya lega

    • Senang mendengar pengalaman Anda sejalan. Saya juga dulu menyukai C karena alasan yang sama, dan belakangan pindah ke Golang karena kesederhanaannya juga terasa pas bagi saya

  • Gagasan bahwa aksesibilitas kode harus diperlakukan sebagai warga kelas satu benar-benar mengena bagi saya. Aturan sebaiknya dijadikan pedoman, dan orang yang benar-benar ahli adalah mereka yang tahu, sesuai konteks, kapan harus melanggar atau melengkapinya agar kode tetap mudah dibaca. Pada akhirnya yang penting adalah intuisi terhadap beban kognitif kode dan trade-off-nya. Entah itu duplikasi atau abstraksi, Anda harus selalu memikirkan orang berikutnya—termasuk diri Anda sendiri enam bulan lagi. Setiap permintaan untuk menambah satu aturan lagi sebenarnya hanya pengulangan masalah yang sama. Setelah panduan dasar, yang tersisa adalah tacit knowledge, yaitu pengetahuan implisit yang lahir dari pengalaman. Seiring waktu, Anda akan mulai merasakan sendiri kode mana yang baik dan mana yang buruk. Pada akhirnya memang harus dirasakan langsung

    • Saya setuju dengan inti aksesibilitas kode, tetapi sayangnya penulis mengabaikan germane overhead (konsumsi sumber daya kognitif oleh penerima). Untuk benar-benar meningkatkan aksesibilitas kode, kita harus mempertimbangkan ketiga jenis overhead: intrinsic, extraneous, dan germane

  • Orang sering bilang dokumentasikan "mengapa", tetapi saya sulit memisahkan "mengapa" dan "apa", jadi saya catat keduanya. Komentar terburuk adalah

    x = 4 // assign 4 to x

    seperti itu. Mencampur kode dan komentar membuatnya lebih sulit dibaca dan memaksa pergantian konteks. Lebih baik seperti ini:

    // mengapa ini dilakukan, dan apa yang akan dikerjakan
setup();
t = setupThing();
t.useThing(42);
t.theWidget(need=true);
...

    Dengan cara itu, komentar dan kode dipisahkan dengan jelas. Meski begitu, menulis "apa" pun masih jauh lebih baik daripada tidak menulis apa-apa sama sekali, dan tetap mengurangi beban kognitif

    • Komentar dalam format seperti ini biasanya sulit dirawat, dan karena implementasinya bisa berubah lima kali dalam setahun, komentar itu cepat usang dan malah membingungkan. Di proyek-proyek terakhir, saya menghapus hampir semua komentar dan hanya menyisakan logika yang benar-benar sulit serta dokumentasi tingkat tertinggi

    • Saya rasa ada saatnya kedua hal itu (why/what) memang perlu didokumentasikan. Kadang alasannya yang perlu dijelaskan, kadang perilakunya yang perlu diperjelas. Belakangan saya merasa nilai komentar justru diremehkan. Tidak perlu memberi komentar di setiap baris, tetapi sebagian besar "self-documenting code" juga sebenarnya tidak terlalu mudah dibaca

    • Belakangan ini saya merasa bagian tersulit adalah memutuskan apa yang sebaiknya ditinggalkan di dalam kode, dan apa yang sebaiknya ditulis di design doc atau dokumentasi teknis. Kesimpulan saya: komentar dalam kode paling baik dipakai untuk menjelaskan niat yang tidak intuitif atau tersembunyi. Misalnya: "alasan ini dimemoisasi adalah karena X"

    • Saya tertawa melihat komentar gaya ChatGPT seperti x=4. Tapi kelemahan pendekatan yang Anda usulkan adalah risiko komentar menjadi usang dan tidak lagi selaras dengan kode. Saat mengubah kode, komentarnya juga harus ikut diperbarui

    • Saya bukan programmer dari latar pendidikan formal, melainkan fisikawan, jadi setiap kali menulis komentar saya sedang berusaha mengubah kebiasaan ke gaya seperti ini. Waktu masih mahasiswa, budaya yang ada adalah demi nilai bagus Anda harus memberi komentar sebanyak mungkin pada kode