Clean Code: 10 Rules I Actually Follow (And 5 I Ignore)

Saya telah melihat kode orang lain selama 14 tahun sekarang sebagai arsitek perangkat lunak senior di sebuah perusahaan fintech menengah, dan saya bisa memberi tahu Anda tepatnya kapan saya berhenti menjadi seorang penganut kode bersih: itu adalah pukul 2:47 AM pada hari Selasa di bulan Maret 2019, ketika sistem pemrosesan pembayaran kami mati karena seseorang telah menghabiskan tiga hari untuk merombak modul yang berfungsi sempurna untuk mengikuti setiap aturan dalam buku Uncle Bob. Ironisnya? Bug itu muncul selama "pembersihan."

Malam itu mengubah cara saya berpikir tentang kualitas kode. Saya tidak mengatakan prinsip kode bersih itu salah—jauh dari itu. Tetapi setelah meninjau lebih dari 10.000 permintaan tarik, membimbing 47 pengembang, dan mengirimkan 23 rilis produk utama, saya telah belajar bahwa kepatuhan dogmatis terhadap kumpulan aturan apapun hanyalah bentuk utang teknis lainnya. Beberapa aturan kode bersih adalah emas mutlak. Yang lainnya? Mereka tergantung konteks paling baik, dan secara aktif berbahaya paling buruk.

Inilah yang sebenarnya saya lakukan dalam kode produksi, dan yang lebih penting, mengapa saya melakukannya.

Aturan yang Saya Ikuti #1: Fungsi Harus Melakukan Satu Hal (Tapi Saya Mendefinisikan "Satu Hal" Berbeda)

Prinsip tanggung jawab tunggal untuk fungsi mungkin merupakan aturan paling berharga yang saya ikuti secara religius. Tetapi inilah di mana saya menyimpang dari buku teks: saya tidak mengukur "satu hal" dengan baris kode atau jumlah operasi. Saya mengukurnya dengan kohesi konseptual.

Kuartal lalu, saya meninjau sebuah fungsi yang terdiri dari 8 baris tetapi secara spektakuler melanggar SRP. Itu memvalidasi input pengguna DAN mencatat hasil validasi DAN memperbarui cache. Tiga tanggung jawab berbeda diisi ke dalam 8 baris. Bandingkan itu dengan fungsi 45 baris yang saya tulis bulan lalu yang mengatur transaksi basis data yang kompleks—itu melakukan "satu hal" (menyelesaikan transaksi pembayaran), tetapi satu hal itu memerlukan beberapa langkah yang saling terkait.

Inilah tes litmus saya: Dapatkah saya menjelaskan apa yang dilakukan fungsi ini dalam satu kalimat tanpa menggunakan kata "dan"? Jika saya perlu mengatakan "fungsi ini memvalidasi input DAN mengirim email," itu melakukan dua hal. Tetapi jika saya mengatakan "fungsi ini memproses permintaan pengembalian uang," dan itu secara alami melibatkan validasi, pembaruan basis data, dan pemberitahuan—itu masih satu hal pada tingkat abstraksi yang tepat.

Dalam praktiknya, ini berarti fungsi saya rata-rata 25-30 baris daripada 10-15 yang direkomendasikan oleh penganut murni. Tetapi tingkat bug kami untuk fungsi-fungsi ini adalah 40% lebih rendah daripada kode yang diekstraksi berlebihan yang kami miliki sebelumnya. Mengapa? Karena menjaga operasi terkait bersama-sama mengurangi beban kognitif untuk memahami sistem. Ketika semuanya dipisahkan menjadi fungsi kecil-kecil, Anda menghabiskan lebih banyak waktu melompat di antara file daripada memahami logika bisnis.

Keuntungan sebenarnya di sini adalah keterujian. Fungsi yang melakukan satu hal konseptual mudah untuk diuji, bahkan jika panjangnya 40 baris. Anda memmock ketergantungan, memanggil fungsi, dan memastikan hasilnya. Selesai. Ketika Anda telah mengekstrak semuanya menjadi fungsi 5 baris, Anda akhirnya berakhir dengan pengujian integrasi karena pengujian unit menjadi tidak berarti.

Aturan yang Saya Ikuti #2: Nama yang Berarti Tidak Dapat Ditawar

Saya akan mati di atas bukit ini: nama variabel dan fungsi adalah dokumentasi terpenting yang akan Anda tulis. Saya telah menolak permintaan tarik hanya karena penamaan yang buruk, dan saya akan melakukannya lagi.

"Kepatuhan dogmatis terhadap kumpulan aturan apapun hanyalah bentuk utang teknis lainnya. Kode terbaik bukanlah yang paling bersih—itu adalah kode yang dapat dikirim dengan andal dan dapat dipelihara oleh tim Anda."

Dua bulan yang lalu, seorang pengembang junior menyerahkan kode dengan fungsi bernama `processData()`. Saya mengirimnya kembali dengan video Loom selama 10 menit yang menjelaskan mengapa. Fungsi itu secara khusus memvalidasi nomor kartu pembayaran terhadap algoritma Luhn. Nama yang benar adalah `validateCardNumberChecksum()`. Ya, itu lebih panjang. Ya, itu lebih spesifik. Itulah intinya.

Inilah hierarki penamaan saya, disempurnakan selama ribuan tinjauan kode:

• Variabel Boolean: Selalu mulai dengan is/has/can/should. Bukan `active`, tetapi `isActive`. Bukan `permission`, tetapi `hasPermission`.
• Fungsi: Kata kerja untuk tindakan, kata benda untuk kueri. `calculateTotalPrice()` bukan `totalPrice()`. `getUserById()` bukan `user()`.
• Kelas: Kata benda yang mewakili konsep, bukan tindakan. `PaymentProcessor` bukan `ProcessPayments`.
• Konstanta: SCREAMING_SNAKE_CASE untuk konstanta sejati, camelCase untuk konfigurasi yang mungkin berubah.

Dampaknya dapat diukur. Setelah menerapkan konvensi penamaan ketat di tim kami 18 bulan yang lalu, waktu tinjauan PR rata-rata kami turun dari 3,2 jam menjadi 1,8 jam. Mengapa? Karena peninjau menghabiskan lebih sedikit waktu untuk menguraikan apa yang dilakukan kode dan lebih banyak waktu untuk mengevaluasi apakah itu dilakukan dengan benar.

Saya juga menegakkan aturan "tidak ada singkatan" dengan tepat tiga pengecualian: `id`, `url`, dan `api`. Semua yang lain dieja. `usr` menjadi `user`. `btn` menjadi `button`. `calc` menjadi `calculate`. Keystrokes tambahan itu sepadan ketika seseorang sedang melakukan debug pada pukul 11 malam dan tidak perlu menebak apa arti `tmpBfr`.

Aturan yang Saya Ikuti #3: Komentar Menjelaskan Mengapa, Bukan Apa

Saya telah melihat dua ekstrem dalam karir saya: basis kode tanpa komentar dan basis kode di mana setiap baris memiliki komentar. Keduanya salah, tetapi kode yang terlalu banyak komentar sebenarnya lebih buruk karena menciptakan beban pemeliharaan dan sering kali berbohong.

Aturan saya sederhana: jika Anda sedang menjelaskan apa yang dilakukan kode, kode itu mungkin buruk. Jika Anda sedang menjelaskan mengapa Anda membuat keputusan tertentu, itu adalah komentar yang baik. Inilah contoh nyata dari o