Clean Code: 10 Principles That Make You a Better Developer — cod-ai.com

Saya masih ingat hari ketika saya mewarisi codebase sepanjang 50.000 baris yang membuat saya mempertanyakan pilihan karir saya. Itu tahun 2015, saya sudah tiga tahun dalam peran sebagai pengembang senior di sebuah startup fintech, dan insinyur utama kami baru saja pergi tanpa dokumentasi. Kode itu berfungsi—nyaris—tetapi membacanya terasa seperti memecahkan hieroglif kuno yang ditulis oleh seseorang yang benar-benar membenci pengembang di masa depan. Pengalaman itu mengajarkan saya lebih banyak tentang kode yang bersih daripada buku teks manapun yang pernah ada.

Pikirkan sembilan tahun ke depan, dan sekarang saya adalah insinyur utama di sebuah perusahaan yang mengelola sistem yang memproses lebih dari 2 juta transaksi setiap hari. Saya telah meninjau ribuan permintaan tarik, membimbing puluhan pengembang, dan membenahi lebih banyak kode warisan daripada yang ingin saya akui. Melalui semua ini, saya telah menyaring apa yang memisahkan kode yang baik dari yang hebat menjadi sepuluh prinsip dasar yang telah mengubah bukan hanya pekerjaan saya, tetapi juga pekerjaan setiap pengembang yang saya latih.

Kode yang bersih bukanlah tentang menjadi pedan atau mengikuti aturan demi aturan. Ini tentang rasa hormat—rasa hormat untuk diri Anda di masa depan, rekan tim Anda, dan orang berikutnya yang akan memelihara pekerjaan Anda pada pukul 2 pagi saat produksi sedang down. Biarkan saya berbagi apa yang telah saya pelajari.

Biaya Sebenarnya dari Kode Kotor

Sebelum kita membahas prinsip-prinsipnya, mari kita bicarakan mengapa ini penting. Dalam peran saya saat ini, kami melakukan studi internal yang melacak produktivitas pengembang di seluruh tim rekayasa kami. Kami menemukan bahwa pengembang menghabiskan rata-rata 65% dari waktu mereka membaca dan memahami kode yang ada, dibandingkan dengan hanya 35% yang benar-benar menulis kode baru. Rasio itu semakin buruk dengan kode yang ditulis dengan buruk—meloncat menjadi 80/20 di sistem warisan kami.

Inilah yang mengejutkan: kami menghitung bahwa nama variabel yang tidak jelas saja menghabiskan waktu tim kami sekitar 127 jam per kuartal. Itu lebih dari tiga minggu kerja penuh hanya untuk mencari tahu apa yang sebenarnya diwakili oleh x, temp, atau data2. Kalikan itu dengan tim berisi 40 insinyur, dan Anda melihat biaya tahunan enam digit dari sesuatu yang sekadar konvensi penamaan yang buruk.

Saya telah melihat proyek gagal bukan karena ketidakmungkinan teknis, tetapi karena codebase menjadi begitu rumit sehingga bahkan perubahan sederhana memerlukan waktu berminggu-minggu bukan jam. Salah satu klien e-commerce yang saya konsultasikan kehilangan perkiraan $50,000 per hari dalam potensi pendapatan karena sistem checkout mereka begitu rapuh sehingga menambah metode pembayaran baru memerlukan siklus pengembangan selama tiga bulan. Setelah enam minggu sprint refaktorisasi menerapkan prinsip kode yang bersih, perubahan yang sama hanya memerlukan empat hari.

Kasus bisnisnya jelas: kode yang bersih secara langsung mempengaruhi keuntungan Anda, moral tim Anda, dan kemampuan Anda untuk berinovasi. Sekarang mari kita eksplorasi cara untuk mencapainya.

Prinsip 1: Nama yang Bermakna adalah Garis Pertama Dokumentasi Anda

Saya pernah bekerja dengan seorang pengembang yang bersikeras bahwa nama variabel yang pendek membuat kode lebih cepat untuk mengetik. Dia akan menulis hal-hal seperti let u = getUserData() atau const p = calculatePrice(). Ketika saya bertanya kepadanya untuk menjelaskan kodenya tiga bulan kemudian, dia tidak bisa. Dia telah melupakan sistem singkatan miliknya sendiri.

Nama variabel, fungsi, dan kelas Anda harus menceritakan sebuah kisah. Mereka harus mengungkapkan niat tanpa memerlukan komentar. Bandingkan dua contoh ini:

Buruk: const d = 86400;

Baik: const SECONDS_PER_DAY = 86400;

Perbedaannya tampak sepele sampai Anda melakukan debugging tengah malam dan mencoba memahami mengapa sebuah perhitungan salah. Versi kedua segera memberi tahu Anda apa yang diwakili oleh angka ajaib itu.

Inilah daftar periksa penamaan yang saya bagikan kepada setiap pengembang junior yang saya bimbing:

• Gunakan nama yang dapat diucapkan—jika Anda tidak bisa mengatakannya saat tinjauan kode, itu terlalu kriptik
• Gunakan nama yang dapat dicari—variabel dengan satu huruf tidak mungkin ditemukan dengan Ctrl+F
• Hindari pemetaan mental—jangan membuat pembaca menerjemahkan singkatan Anda
• Pilih satu kata per konsep—jangan campur fetch, retrieve, dan get untuk operasi yang sama
• Gunakan nama domain solusi—programmer lain akan membaca kode Anda, jadi AccountVisitor atau JobQueue masuk akal

Dalam praktiknya, saya menemukan bahwa menghabiskan 30 detik ekstra memikirkan nama menghemat rata-rata 15 menit kebingungan di kemudian hari. Itu adalah pengembalian investasi 30x. Ketika Anda mengalikan itu di seluruh ratusan variabel dalam sebuah proyek, penghematan waktu menjadi sangat besar.

Salah satu teknik yang saya gunakan: jika saya tidak bisa menjelaskan apa yang dilakukan sebuah variabel dalam satu kalimat yang jelas, namanya tidak cukup baik. Cobalah sendiri—jika Anda kesulitan memberi nama sesuatu, itu sering kali tanda bahwa hal itu sendiri melakukan terlalu banyak dan perlu dipecah.

Prinsip 2: Fungsi Harus Melakukan Satu Hal dan Melakukannya dengan Baik

Prinsip Tanggung Jawab Tunggal bukan hanya teori akademis—ini adalah strategi bertahan hidup. Saya mempelajari ini dengan cara yang sulit ketika melakukan debug pada fungsi sepanjang 400 baris yang disebut processOrder yang memvalidasi input, menghitung pajak, memperbarui inventaris, mengirim email, mencatat analitik, dan menangani pemrosesan pembayaran. Menemukan bug dalam perhitungan pajak berarti menyelam melalui kode templat email yang tidak terkait.