Kualitas Kode yang Terjaga, Bukan Sekadar Rapi

12.6 Kualitas Kode yang Terjaga, Bukan Sekadar Rapi

Saat kode mulai ditulis, senior engineer tidak hanya mengejar fitur selesai, ia juga menjaga kualitas kode secara aktif. Banyak engineer junior menganggap kualitas sebagai sesuatu yang diperiksa saat code review. Mereka menulis dengan cepat, asal jalan, lalu berharap reviewer menemukan semua masalah. Senior engineer tahu bahwa kualitas tidak bisa ditambahkan setelah kode selesai. Kualitas harus ada sejak karakter pertama diketik.

Bayangkan Anda sedang menulis fungsi untuk memproses diskon di sistem e-commerce. Seorang junior mungkin langsung menulis satu fungsi panjang yang menangani semua jenis diskon: persentase, nominal, buy-one-get-one, voucher, dan bundling. Semua bercampur dalam satu metode dengan parameter boolean dan kondisi bersarang. Kode itu mungkin berfungsi, tetapi sulit dibaca, sulit diubah, dan sulit diuji. Senior engineer akan berhenti sejenak, memikirkan bagaimana memisahkan tanggung jawab, lalu menulis fungsi yang lebih kecil dengan nama yang jelas.

Berikut perbandingan langsung antara pendekatan junior dan senior untuk kasus diskon tersebut.

// Pendekatan junior: satu fungsi panjang dengan boolean dan nested if
function applyDiscount(price, type, isVoucher, isBundling) {
  if (type === 'percentage') {
    if (isVoucher) {
      return price * 0.9; // diskon 10%
    } else if (isBundling) {
      return price * 0.85; // diskon 15%
    } else {
      return price * 0.95; // diskon 5%
    }
  } else if (type === 'nominal') {
    if (isVoucher) {
      return price - 5000;
    } else {
      return price - 2000;
    }
  }
  return price;
}

// Pendekatan senior: fungsi kecil dengan nama jelas dan tanggung jawab tunggal
function applyPercentageDiscount(price, percent) {
  return price * (1 - percent / 100);
}

function applyNominalDiscount(price, amount) {
  return Math.max(0, price - amount);
}

function applyVoucherDiscount(price, voucherAmount) {
  return applyNominalDiscount(price, voucherAmount);
}

Readability adalah fondasi pertama. Kode yang baik tidak perlu komentar panjang untuk menjelaskan apa yang dilakukan. Nama fungsi, nama variabel, dan struktur logika sudah cukup bercerita. Jika Anda membaca fungsi applyPercentageDiscount dan langsung paham apa yang terjadi tanpa membaca isinya, Anda sudah berada di jalur yang benar. Jika Anda harus membaca tiga lapis nested if untuk mengerti alurnya, ada yang salah.

Cohesion dan coupling adalah pasangan yang selalu diuji. Cohesion berarti setiap fungsi atau kelas memiliki satu tanggung jawab yang jelas. Fungsi calculateTotal tidak perlu sekaligus mengirim email konfirmasi. Coupling berarti seberapa besar ketergantungan antar modul. Saat Anda mengubah satu kelas, berapa banyak kelas lain yang ikut rusak? Senior engineer selalu waspada terhadap coupling yang terlalu tinggi. Ia tahu bahwa perubahan kecil di satu tempat bisa merembet ke seluruh sistem jika coupling tidak dijaga.

Duplication adalah musuh yang paling licik. Kadang duplikasi tidak terlihat persis sama. Mungkin ada dua fungsi yang melakukan hal mirip tetapi dengan nama parameter berbeda. Atau ada logika perhitungan pajak yang ditulis ulang di tiga tempat dengan sedikit variasi. Setiap duplikasi adalah bom waktu: ketika aturan pajak berubah, seseorang harus ingat mengubah semua tempat. Senior engineer tidak menunggu duplikasi menumpuk. Ia refactor kecil saat menemukannya, bahkan jika itu berarti mengubah kode yang sudah berfungsi.

Naming adalah indikator langsung seberapa baik seseorang memahami kodenya sendiri. Variabel bernama data, temp, result, atau list adalah tanda bahaya. Fungsi bernama processData atau doSomething tidak memberi petunjuk apa pun. Senior engineer memberi nama berdasarkan maksud, bukan berdasarkan implementasi. calculateDiscountedPrice lebih baik dari applyDiscount. pendingOrders lebih baik dari orderList.

Boundary handling adalah pembeda antara kode yang berfungsi di demo dan kode yang bertahan di production. Apa yang terjadi jika input diskon bernilai negatif? Apa yang terjadi jika jumlah barang melebihi kapasitas integer? Apa yang terjadi jika service eksternal mengembalikan response kosong? Senior engineer menulis kode yang memikirkan batas-batas ini sejak awal, bukan menunggu bug muncul.

Refactor kecil adalah kebiasaan yang membedakan kode yang membusuk dan kode yang terus sehat. Refactor tidak harus besar. Mengganti nama variabel, memisahkan satu fungsi menjadi dua, menghapus parameter yang tidak dipakai, atau memindahkan logika ke tempat yang lebih tepat. Senior engineer melakukan refactor kecil setiap hari, tanpa menunggu task khusus. Ia tahu bahwa kode yang tidak dirawat akan menjadi beban, bukan aset.

Kualitas kode yang terjaga bukan tentang kerapian visual. Bukan tentang indentasi yang konsisten atau spasi yang rapi. Itu semua penting, tetapi bukan inti. Intinya adalah kode yang bisa dibaca, diubah, dan dipercaya oleh orang lain—termasuk diri Anda sendiri enam bulan kemudian. Senior engineer tidak menunggu reviewer untuk memperbaiki. Ia menjaga kualitas sejak menulis, karena ia tahu bahwa setiap baris kode adalah keputusan desain yang akan dihadapi timnya di masa depan.