Code Review Checklist — Clean Code

Code review adalah proses dimana developer lain memeriksa kode kamu sebelum di-merge. Ini bukan cari kesalahan — ini tentang collaborative quality…

Code review adalah membaca perubahan kode teman satu tim sebelum perubahan itu masuk ke branch utama. Tujuannya bukan mencari siapa yang salah, tapi memastikan kode yang masuk mudah dipahami, aman diubah, dan sesuai standar tim. Bayangin brosur promo Harbolnas Toko Kaos Raka yang mau dicetak seribu lembar. Penulisnya sudah membacanya sepuluh kali, tapi matanya membaca yang ia maksud, bukan yang tertulis. Orang kedua yang membaca dengan daftar cek di tangan menemukan harga yang salah ketik dalam dua menit.

🧪 Tebakan cepat: PR di bawah cuma menambah voucher HEMAT20, dan penulisnya bilang sudah dicoba dengan HEMAT10. Dari empat keranjang test, berapa yang masih OK? Tebak dulu, jawabannya ada di bagian "1. Benar? Jalankan test-nya".

PR #14: Tambah voucher HEMAT20

Deskripsi PR: "Menambah voucher HEMAT20 (potongan 20%) untuk Harbolnas. Voucher sekarang dibaca dari tabel VOUCHERS. Sudah dicoba dengan HEMAT10." Diff-nya, - baris yang dihapus dan + baris yang ditambah:

-const VOUCHER_DISCOUNT = 0.1;
+const VOUCHERS = { HEMAT10: 0.1, HEMAT20: 0.2 };
 const FREE_SHIPPING_MIN = 200000;
 const SHIPPING_FEE = 15000;

 function applyVoucher(amount, voucherCode) {
-  if (voucherCode === 'HEMAT10') return amount - amount * VOUCHER_DISCOUNT;
-  return amount;
+  try {
+    // kurangi amount dengan diskon
+    return amount - amount * VOUCHERS[voucherCode];
+  } catch (e) {
+    return amount;
+  }
 }

 function calculateTotal(cart, voucherCode) {
   let total = calculateSubtotal(cart);
+  const freeShipping = total >= FREE_SHIPPING_MIN;
   total = applyVoucher(total, voucherCode);
-  total = addShipping(total);
+  if (!freeShipping) total += SHIPPING_FEE;
   return 'Total: ' + formatRupiah(total);
 }

Kelihatan rapi. Sekarang baca dengan daftar cek.

Checklist, dari yang paling penting

Urutannya dari yang paling mahal kalau lolos:

1. Benar? Jalankan test-nya. Jangan percaya "sudah dicoba". Empat keranjang dari track ini:

OK   Total: Rp 220.500
BEDA Total: Rp NaN, harusnya Total: Rp 245.000
BEDA Total: Rp NaN, harusnya Total: Rp 90.000
BEDA Total: Rp 189.000, harusnya Total: Rp 204.000

Cuma satu yang masih OK, persis keranjang yang dicoba penulisnya. Itu jawaban tebakannya. Tanpa voucher, VOUCHERS[''] itu undefined, dan amount * undefined hasilnya NaN (Not a Number).

2. Sesuai deskripsi? Deskripsinya bilang "menambah voucher", tapi diff juga mengubah calculateTotal: ongkir sekarang dicek sebelum voucher. Itu sebabnya keranjang D jadi Rp 189.000. Perubahan aturan bisnis yang gak disebut di deskripsi gampang lolos tanpa ada yang memutuskan.

3. Error ditangani dengan benar? try/catch di applyVoucher gak menangkap apa-apa: amount * undefined gak melempar error, cuma menghasilkan NaN. Ia cuma memberi rasa aman palsu, dan kalau suatu hari ada error beneran, ia menelannya.

4. Ada test untuk perubahannya? Gak ada satu pun keranjang dengan HEMAT20. Usulnya: keranjang A dengan HEMAT20, 245.000 dipotong 20% jadi 196.000, di bawah 200.000, jadi kena ongkir: Total: Rp 211.000.

5. Mudah dibaca? Komentar // kurangi amount dengan diskon cuma mengulang barisnya. Di PR lain yang sering ketemu: fungsi 200 baris, nama x, magic number.

Yang gak ada di daftar: spasi, titik koma, tanda kutip. Itu urusan alat seperti Prettier dan ESLint yang jalan otomatis, supaya reviewer fokus ke logika.

Menulis komentar review

Komentar yang membantu itu spesifik, bilang kenapa, dan menawarkan jalan keluar. Tandai mana yang wajib diperbaiki (blocking) dan mana yang cuma saran:

Untuk fungsi 200 baris, "Kok panjang banget?" gak membantu. Tulis yang bisa ditindaklanjuti: "Fungsi ini terlalu panjang (200 baris). Gimana kalau dipecah jadi validasi, hitung harga dan simpan, seperti OrderService di lesson Single Responsibility?"

Di GitHub, review diakhiri dengan salah satu dari tiga: Comment (cuma berkomentar), Approve (setuju di-merge), atau Request changes (minta perbaikan dulu). PR #14 punya tiga temuan blocking, jadi Request changes. Setelah penulisnya memperbaiki, keempat keranjang OK ditambah HEMAT20 Rp 211.000, baru Approve.

PR yang kecil juga lebih gampang direview dengan teliti. SmartBear, dari studi review kode di Cisco, menyarankan gak lebih dari 400 baris sekali review.

⚠️ Jebakan yang sering ketemu

TL;DR: Code review memastikan kode yang masuk mudah dipahami, aman diubah dan sesuai standar tim, bukan mencari siapa yang salah. Baca dengan daftar cek, dari yang paling mahal kalau lolos: benar (jalankan test, jangan percaya "sudah dicoba"), sesuai deskripsi, error ditangani, ada test untuk perubahannya, mudah dibaca; gaya penulisan diserahkan ke formatter dan linter. PR #14 yang "cuma menambah HEMAT20" ternyata bikin keranjang tanpa voucher Rp NaN dan keranjang D Rp 189.000, dengan try/catch yang gak menangkap apa-apa dan tanpa test HEMAT20 (Rp 211.000). Komentar review spesifik, bilang kenapa, menawarkan solusi, dan ditandai blocking atau saran; untuk fungsi 200 baris, bilang terlalu panjang dan usulkan pecahannya. Tiga temuan blocking berarti Request changes; setelah semua OK, Approve.

Yang akan kamu pelajari