Clean Code vs. Filosofi Desain Perangkat Lunak

• Ini adalah percakapan tentang desain perangkat lunak antara Robert “Uncle Bob” Martin dan John Ousterhout yang berlangsung dari September 2024 hingga Februari 2025
• Keduanya sama-sama menulis buku tentang desain perangkat lunak
• Mereka menunjukkan perbedaan pandangan pada tiga topik utama (panjang metode, komentar, Test-Driven Development)
• Inti percakapan adalah bagaimana mengurangi kompleksitas kode dan meningkatkan keterbacaan, serta bagaimana menulis pengujian yang tepat

Panjang metode

• Uncle Bob (selanjutnya UB) menekankan posisi “fungsi pendek itu baik, dan jika memungkinkan pisahkan menjadi lebih pendek lagi”
  • Satu metode seharusnya hanya melakukan satu “hal (One Thing)”
  • Namun, jika diterapkan terlalu ekstrem, ini bisa berujung pada pemecahan berlebihan (over-decomposition)
• John menunjukkan bahwa metode yang terlalu kecil justru membuat alur keseluruhan lebih sulit dipahami
  • Jika terlalu banyak metode “dangkal (shallow)”, akan muncul masalah karena untuk memahami satu fungsi, semua metode terkait harus ditelusuri
  • Ketergantungan timbal balik antar metode (“entanglement”) meningkat, sehingga beban membaca kode menjadi lebih besar
• Contoh PrimeGenerator
  • Kode asli UB dibagi menjadi sekitar 8 metode kecil, dan metode-metode itu saling terjalin sehingga sulit dipahami
  • Versi John ditulis agar alur keseluruhan dapat dipahami sekilas dengan menaruh komentar yang memadai dalam satu metode
  • UB juga sampai taraf tertentu mengakui bahwa “ada pemecahan yang berlebihan”
• Pada akhirnya, keduanya mengakui bahwa pemecahan kode itu penting, tetapi kuncinya adalah menjaga keseimbangan antara “memecah terlalu kecil” dan “membiarkannya terlalu besar”

Komentar

• UB memandang komentar sebagai “kejahatan yang perlu (necessary evil)”
  • Ia menilai komentar berisiko tidak diperbarui dengan baik atau berisi informasi yang salah
  • Ia lebih menyukai pendekatan untuk mengungkapkan niat semaksimal mungkin melalui kode, dan bila perlu menggunakan nama yang sangat panjang
• John berpendapat bahwa komentar memang perlu
  • Jika tujuan antarmuka (metode) atau niat implementasi ditulis dengan jelas dalam bahasa Inggris, pengembang lain dapat mengurangi waktu yang terbuang untuk menelusuri kode yang tidak perlu
  • Ia melihat bahwa “hal yang paling berbahaya adalah situasi ketika tidak ada komentar sehingga kita harus menafsirkan kode secara langsung”
• Dengan PrimeGenerator sebagai contoh, John menunjukkan bahwa tanpa komentar yang menjelaskan “mengapa algoritme bekerja seperti itu”, kode akan sangat sulit dipahami
• UB berpandangan bahwa “jika komentar tidak akurat, justru akan merugikan”, tetapi John cenderung pada posisi bahwa “komentar yang tidak ada lebih berbahaya daripada komentar yang salah”
• Keduanya sampai batas tertentu sepakat bahwa “tingkat komentar yang tepat harus disesuaikan dengan tim dan situasi”, tetapi secara umum John menilai nilai komentar jauh lebih tinggi

Refaktorisasi PrimeGenerator oleh John

• John menyusun ulang kode yang semula dipisah menjadi 8 metode menjadi satu metode tunggal, atau bentuk 2~3 metode
• Ia menambahkan komentar yang kaya pada bagian yang perlu untuk menjelaskan “mengapa diimplementasikan dengan cara ini”
• Melalui komentar, ia juga menjelaskan niat variabel utama (multiples, primes) dan cara kerja algoritme, agar pemahaman kode bisa lebih cepat
• UB menyatakan bahwa kode ini pun tidak sepenuhnya intuitif
  • Untuk menjelaskan algoritme yang kompleks tetap dibutuhkan waktu, dan penulis sendiri pun merasa kesulitan selama proses peninjauan ulang

Refaktorisasi PrimeGenerator2 oleh Bob

• Ini adalah versi UB yang sedikit memodifikasi kode John
• Ia memisahkan beberapa metode tambahan dan menerapkan “refaktorisasi lanjutan”
  • Pada bagian perulangan, keterbacaan meningkat, tetapi performa sempat menurun untuk sementara
• John menunjukkan bahwa “jika dipecah menjadi metode yang terlalu kecil, masalah performa bisa muncul”, dan UB kemudian merevisinya lagi untuk memperbaiki performa
• Namun, karena preferensi UB untuk “meminimalkan komentar”, John tetap mempertahankan pendapat bahwa “pemahaman akan lebih mudah jika diberi penjelasan tambahan”

Test-Driven Development

• UB sangat merekomendasikan pendekatan TDD, yaitu menulis pengujian lebih dulu dalam siklus pendek lalu sedikit demi sedikit menambahkan kode untuk meloloskan pengujian yang gagal
  • Ia berpendapat bahwa dengan cara ini kode selalu mempertahankan cakupan pengujian dan dapat menghindari debugging yang rumit
  • Menurutnya, kode akan sering direfaktor dan menjadi semakin bersih secara bertahap
• John khawatir TDD akan terlalu condong menjadi “pendekatan taktis”
  • Ia menilai bahwa “desain seharusnya didahulukan, tetapi TDD mendorong penulisan kode lebih dulu (implementasi minimum untuk pengujian)”
  • Ia berpandangan bahwa desain yang baik sebaiknya mempertimbangkan cakupan yang lebih luas sekaligus, lalu menulis pengujian secara berkelompok (bundling) untuk kode tersebut
• UB berpendapat bahwa memang bisa ada masalah yang muncul karena “penerapan TDD yang salah”, tetapi jika dijalankan dengan benar, TDD membantu cakupan pengujian dan perancangan ulang (refaktorisasi)
• John menyatakan kekhawatiran bahwa “bagi pemula, TDD justru berisiko membuat kode cepat menjadi berantakan”
• Pada akhirnya, keduanya sepakat bahwa “baik TDD maupun pendekatan Bundling, jika dilakukan dengan baik, sama-sama bisa menghasilkan kode yang hebat”, tetapi mereka tetap berbeda pandangan soal mana yang lebih baik

Penutup

• John:
  • Ia khawatir “Clean Code” terlalu menekankan pemisahan fungsi yang sangat kecil dan penekanan komentar, sehingga pembaca berisiko mengikutinya secara ekstrem
  • Jika komentar tidak diberikan dengan cukup, kode menjadi sulit dipahami, dan pada akhirnya pengembang akan menghabiskan lebih banyak waktu
  • Ia juga menunjukkan bahwa TDD bisa membuat orang kehilangan desain gambaran besarnya
• UB:
  • Ia menyatakan bahwa edisi ke-2 “Clean Code” telah sampai taraf tertentu melengkapi hal tersebut dan mengintegrasikan sebagian pendapat John
  • Sambil menghormati pengalaman dan sudut pandang yang berbeda, ia menekankan kesamaan bahwa pada akhirnya “semua orang harus mengarah pada kode yang bersih dan mudah dipelihara”
• Kesimpulannya, keduanya menempatkan pentingnya desain perangkat lunak dan “membuat kode mudah dibaca” sebagai nilai yang paling utama
• Namun, perbedaan pandangan tetap ada dalam standar pemisahan metode, cara memanfaatkan komentar, dan urutan penulisan pengujian
• Intinya adalah perlunya menjaga keseimbangan sesuai lingkungan tim dan struktur kode, serta terus berupaya memperbaiki desain

[mhj5730]

Saya punya beberapa buku dari seri Clean, tetapi rasanya buku-buku itu paling cocok dijadikan rujukan hanya pada tingkat metakognitif. Kalau diperlakukan seperti prinsip atau hukum, jadinya sangat melelahkan dan juga tidak praktis. Paman Bob ini selalu membicarakan prinsip SOLID, tetapi menurut saya pribadi isinya yang benar-benar praktis tidak terlalu banyak.

[ahwjdekf]

Menurut saya, Code Complete dan Clean Code menempati peringkat pertama bersama sebagai buku yang paling dilebih-lebihkan.

[carnoxen]

Apakah sudah ada terjemahan untuk The Philosophy of Software Design? Saya coba cari, tapi tidak menemukannya.

[mageia]

Ironisnya, ketimbang buku yang mengatakan bahwa ini adalah kode yang baik, rasanya buku yang bernada satir seperti cara membuat kode yang sulit dipelihara justru akan lebih mudah dipahami.

[aer0700]

Akhir-akhir ini rasanya saya lebih sering berdebat bukan soal clean code, melainkan karena ada penggemar tech stack atau arsitektur tertentu yang berbicara seolah-olah akan jadi masalah besar kalau tech stack atau arsitektur itu tidak diadopsi. Menurut saya, penerapannya harus disesuaikan dengan situasi; sepertinya tidak ada yang mutlak selalu baik.

[yadameda]

Diskusinya keren.

[spilist2]

Kalau dipikir-pikir, saya juga merekomendasikan philosophy of sw design karya John kepada para junior, tetapi tidak benar-benar merekomendasikan clean code.

[bbulbum]

Menurut saya, yang penting adalah tidak sekadar mengikuti headline secara membabi buta, melainkan memahami konteksnya dengan baik dan menerapkannya dengan tepat.

[savvykang]

Buku pengembangan diri tentang coding mungkin cocok untuk pemula yang belum punya pandangan nilai tentang teknologi atau cara implementasi, tetapi menurut saya manfaatnya berkurang seiring bertambahnya pengalaman. Soalnya tidak ada kebenaran mutlak yang cocok untuk semua proyek dan lingkungan, dan ada juga situasi di mana teori umum tidak berlaku. Seperti nasihat dalam buku pengembangan diri di bidang umum lainnya, tampaknya lebih baik menjaga jarak secukupnya, hanya menerapkan saran yang sesuai dengan situasi, dan tidak mengejar nasihat itu secara membabi buta.

[nicewook]

Saya sedikit lebih sependapat dengan perkataan John.
Intinya, mungkin yang penting bukan mengikuti perkataan kedua orang itu secara membabi buta seperti dogma, melainkan memahami mengapa mereka berpandangan demikian lalu melangkah maju.

[leojineoo]

Jangan lupa bahwa clean code bukanlah tujuan, melainkan sarana.

[ilikeall]

Memang, yang penting adalah secukupnya.

[elddytbt]

Bermanfaat 👍🏻

[GN⁺]

Opini Hacker News

• Beberapa orang bisa sangat dogmatis tentang hal tertentu. Sulit memahami kenapa hal-hal seperti ini diterima seperti ajaran suci

  • Pernah harus berurusan dengan orang-orang yang marah setiap kali batas 80 karakter per baris terlampaui
  • Kecenderungan ini bahkan lebih parah bukan hanya dalam gaya pemrograman, pola, dan idiom, tetapi juga dalam tech stack dan arsitektur solusi
  • Sangat membuat frustrasi berdiskusi dengan orang yang hanya mengutip mentah-mentah apa yang mereka baca di buku atau blog
  • Ini особенно parah saat demam NoSQL dan microservices, dan masih terasa pada PAAS/SAAS dan containerization
  • App, lambda, atau pekerjaan transformasi yang hanya menjalankan fungsi dasar justru menambah beban pemeliharaan dan tidak memberi nilai
  • Perbedaan antara saya dan orang yang menulis buku atau blog itu hanya mereka yang menuliskannya. Kita harus selalu ingat bahwa opini mereka bukan fakta

• Jika pernah mengalami proyek yang membabi buta mengikuti rekomendasi Uncle Bob, kita jadi tahu betapa rendah nilainya

  • Ia memang menghasilkan sejumlah teks dalam upaya memperbaiki software engineering, tetapi isinya penuh nasihat yang buruk
  • Kesuksesannya ditopang oleh kebutuhan tanpa akhir para developer junior yang mencari panduan
  • Kode dengan terlalu banyak lapisan tidak langsung menjadi sulit dikerjakan

• Clean Code adalah salah satu alat dalam kotak peralatan seorang software engineer yang baik

• Ada orang yang sekadar mengelompokkan baris-baris yang berdekatan lalu menyebutnya "refactoring", alih-alih memisahkan fungsi saat memang bisa dipakai ulang atau masuk akal secara logis

  • Saat membaca Clean Code di masa kuliah, saya merasakan nuansa umum dari Uncle Bob
  • Sepertinya ini berasal dari pola pikir bahwa fungsi harus berjumlah X baris
  • Saya bersyukur atas fitur inline di IDE modern, dan menyusun ulang kode untuk memahaminya

• Ada kasus penting yang tidak disebutkan terkait pentingnya komentar

  • Saat menulis software device driver USB, sangat mudah membuat perangkat masuk ke kondisi yang salah
  • Setiap kali menerapkan workaround, saya menambahkan komentar untuk mendokumentasikannya
  • Tanpa komentar, orang lain akan sulit memahami maksud kode tersebut

• Sangat merekomendasikan "A Philosophy of Software Design"

  • Intinya adalah mengukur kualitas abstraksi terhadap tingkat kompleksitas
  • Setelah membaca buku nasihat pemrograman lain, kode saya tidak menjadi lebih baik

• Ini adalah respons terhadap masalah nyata di industri software sebelum gerakan Clean Code muncul

  • Clean Code bergerak ke arah yang lebih baik, tetapi lalu dikoreksi secara berlebihan
  • Tidak jelas apakah orang akan kembali lagi ke metode raksasa dan conditional yang bersarang dalam

• Pendapat Bob tentang komentar terasa aneh

  • Sikap paranoid terhadap komentar yang salah terasa konyol
  • Terlalu banyak waktu terbuang karena kode yang tidak jelas
  • Daripada membuat diagram aneh, akan lebih mudah menjelaskan algoritme secara singkat atau memberi tautan

• Buku Uncle Bob adalah sesuatu yang pada akhirnya akan ditinggalkan seiring waktu

  • Dengan mengikuti panduan Clean Code, saya belajar tentang "dekomposisi berlebihan"
  • Fungsi-fungsi kecil pada akhirnya tidak melakukan apa-apa
  • Jika ingin menulis kode yang baik, bacalah kode yang baik dan kembangkan selera yang cocok untuk diri sendiri

• Ada keluhan tentang nama Clean Code

  • Kebersihan kode tidak bisa diukur secara objektif
  • Unsur bawah sadar bahwa menulis "kode bersih" tentu adalah hal baik justru menimbulkan masalah
  • Fondasi "Uncle Bob" sudah rusak sejak awal