7 Kebiasaan Clean Code yang Realistis Buat Developer Sibuk

Daftar Isi

Mengapa Clean Code Sering Jadi Slogan, Bukan Praktik
Kebiasaan 1: Nama yang Berbicara Sendiri
Kebiasaan 2: Fungsi Kecil dengan Satu Tujuan
Kebiasaan 3: Refactor di Jalur yang Kamu Lewati
Kebiasaan 4: Komentar untuk Alasan, Bukan Terjemahan
Kebiasaan 5: Singkirkan Duplikasi Sedikit demi Sedikit
Kebiasaan 6: Struktur File yang Konsisten dan Bisa Ditebak
Kebiasaan 7: Review Kode Sendiri Sebelum Push
Mulai dari Mana Tanpa Mengorbankan Deadline

Mengapa Clean Code Sering Jadi Slogan, Bukan Praktik

Kata “clean code” sering terdengar seperti jargon yang bagus dipamerkan di slide deck, tapi sulit diterapkan sehari-hari. Di tim yang sibuk, prioritas sering pada pengiriman fitur, bukan kerapihan kode. Selain itu, ekspektasi “sempurna dulu” membuat developer menunda perbaikan kecil yang sebenarnya mudah. Artikel ini fokus pada kebiasaan praktis dan realistis — langkah kecil yang bisa kamu lakukan tanpa mengorbankan deadline, tapi berbuah peningkatan kualitas jangka panjang.

Kebiasaan 1: Nama yang Berbicara Sendiri

Nama variabel, fungsi, dan kelas harus menjawab “kenapa” dan “apa” tanpa perlu komentar panjang. Contoh: lebih baik calculateMonthlyRevenue() daripada doCalc(); isValidEmail() lebih jelas daripada check(). Saat memberi nama, bayangkan rekan yang baru bergabung harus mengerti maksudnya dalam 3 detik. Jika butuh penjelasan panjang, pertimbangkan ekstraksi fungsi dengan nama yang menjelaskan maksud.

Kebiasaan 2: Fungsi Kecil dengan Satu Tujuan

Buat fungsi yang melakukan satu hal dan lakukan itu dengan baik. Fungsi kecil lebih mudah diuji, dibaca, dan digabungkan ulang. Jika sebuah fungsi lebih panjang dari 20–30 baris, cari bagian yang bisa diekstrak jadi helper yang bernama jelas. Gunakan parameter yang sedikit dan hindari efek samping tersembunyi — ini membuat debugging dan refactor jauh lebih aman.

Kebiasaan 3: Refactor di Jalur yang Kamu Lewati

Jangan menunggu waktunya longgar untuk refactor besar; terapkan prinsip “Boy Scout Rule”: tinggalkan kode sedikit lebih bersih daripada saat kamu menemukannya. Saat kamu menyentuh file untuk fitur atau bug, luangkan 5–15 menit untuk perbaikan kecil (perbaiki nama, singkatkan fungsi, hapus duplikasi). Perbaikan kecil bertumpuk menjadi perubahan signifikan tanpa mengganggu pengiriman fitur.

Kebiasaan 4: Komentar untuk Alasan, Bukan Terjemahan

Komentar yang bagus menjelaskan “mengapa” — bukan menerjemahkan apa yang sudah jelas dari kode. Jika kamu merasa perlu komentar untuk menjelaskan apa yang terjadi, pertimbangkan refactor supaya kode itu sendiri jelas. Gunakan komentar untuk mencatat trade-off, asumsi, atau keputusan desain yang tidak langsung terlihat dari implementasi.

Kebiasaan 5: Singkirkan Duplikasi Sedikit demi Sedikit

Duplikasi mudah menyebabkan bug. Tapi jangan lakukan ekstraksi besar-besaran sekaligus — mulai dari kasus yang paling sering muncul. Saat menemukan pola yang sama di 2–3 tempat, ekstrak fungsi kecil atau util yang jelas namanya. Dokumentasikan tempat penggunaan dan periksa pengujian agar refactor aman.

Kebiasaan 6: Struktur File yang Konsisten dan Bisa Ditebak

Aturan struktur file yang konsisten membuat hidup tim lebih mudah. Tentukan konvensi sederhana (mis. components/, services/, pages/) dan ikuti, sehingga siapa pun bisa menebak di mana mencari kode tertentu. Sederhana lebih baik daripada sempurna: pilih struktur yang mudah dipertahankan, dokumentasikan, dan perbaiki konsistensi saat bertemu ketidaksesuaian.

Kebiasaan 7: Review Kode Sendiri Sebelum Push

Sebelum membuat PR, lakukan tinjau sendiri singkat dengan checklist: 1) Apakah nama sudah jelas? 2) Ada duplikasi yang mudah dihilangkan? 3) Fungsi terlalu panjang? 4) Perlu komentar yang menjelaskan alasan? 5) Tes yang relevan sudah ada? Tinjau sendiri mengurangi waktu review rekan dan mempercepat merge.

Mulai dari Mana Tanpa Mengorbankan Deadline

Mulai dari langkah-langkah kecil yang bisa dicicil: alokasikan 10–15 menit setiap hari untuk refactor terjadwal, terapkan aturan nama di PR, dan tambahkan daftar periksa tinjau sendiri di template PR. Prioritaskan area yang sering diubah atau rawan bug. Dorong budaya perbaikan kecil di tim — konsistensi kecil dalam banyak PR lebih berdampak daripada refactor besar sekali-sekali.

Referensi

Robert C. Martin — Clean Code: A Handbook of Agile Software Craftsmanship
Martin Fowler — Refactoring: Improving the Design of Existing Code
Google Engineering Practices: Code Review
The Boy Scout Rule — Uncle Bob’s Blog