Seni Code Review: Lebih dari Sekadar Mencari Bug

Filosofi Code Review

Banyak engineer menganggap code review sebagai gerbang quality control — tugasnya menemukan bug sebelum code masuk production. Pandangan ini tidak sepenuhnya salah, tapi sangat terbatas.

Code review yang baik sebenarnya punya tiga tujuan:

1. Berbagi pengetahuan — reviewer dan author sama-sama belajar
2. Menjaga konsistensi — kode harus bisa dipahami oleh seluruh tim, bukan hanya penulisnya
3. Meningkatkan desain — mendiskusikan alternatif arsitektur sebelum terlalu terikat pada satu pendekatan

Bug adalah bonus, bukan fokus utama.

Apa yang Perlu Diperhatikan

Saat melakukan review, saya menggunakan checklist mental berikut (diurutkan dari prioritas tertinggi):

1. Apakah Kode Ini Benar?

Ini pertanyaan paling mendasar. Baca logikanya, bukan hanya syntax-nya. Coba temukan edge case:

// Reviewer: "Bagaimana jika items kosong?"
function getAveragePrice(items: Item[]) {
  const total = items.reduce((sum, item) => sum + item.price, 0)
  return total / items.length // Division by zero!
}

// Seharusnya:
function getAveragePrice(items: Item[]) {
  if (items.length === 0) return 0
  const total = items.reduce((sum, item) => sum + item.price, 0)
  return total / items.length
}

2. Apakah Kode Ini Bisa Dipertahankan?

Kode yang berfungsi hari ini bisa jadi beban teknis besok. Perhatikan:

• Penamaan — apakah nama fungsi dan variabel menjelaskan maksudnya?
• Duplikasi — apakah ada logika yang bisa di-extract menjadi fungsi reusable?
• Kompleksitas — apakah ada cara lebih sederhana untuk mencapai hasil yang sama?

// Sulit dipahami
const d = u.filter(x => x.a && x.b > 18 && !x.c)

// Lebih jelas
const eligibleUsers = users.filter(
  (user) => user.isActive && user.age > 18 && !user.isBanned
)

3. Apakah Ada Masalah Keamanan?

Perhatikan potensi:

• SQL injection atau XSS
• Secrets yang ter-ekspos di kode
• Data sensitif yang tidak di-sanitize
• Missing authentication/authorization check

4. Apakah Cukup Ditest?

Setiap logika bisnis baru harus disertai test. Saat review, cek:

• Apakah happy path di-test?
• Apakah edge case di-cover?
• Apakah test cukup meaningful atau hanya sekadar ada?

Cara Memberikan Feedback yang Baik

Cara kamu menulis komentar review sama pentingnya dengan isi komentarnya:

// ❌ Buruk: Menyalahkan
"Kenapa kamu buat begini? Ini jelas salah."

// ✅ Baik: Membantu
"Ada edge case yang perlu ditangani di sini — bagaimana jika
items kosong? Kita bisa tambah guard clause di awal."

// ❌ Buruk: Terlalu subjektif
"Saya tidak suka cara ini."

// ✅ Baik: Memberi alasan
"Pendekatan ini works, tapi menggunakan Map bisa lebih
efisien karena lookup-nya O(1) dibanding Array.find() yang
O(n). Apakah worth considering?"

Prinsip komentar code review:

• Tanyakan, jangan menuduh — "Have you considered..." bukannya "You forgot..."
• Beri alasan — jangan hanya bilang "ubah ini", jelaskan mengapa
• Beri alternatif — kalau mengkritik, tawarkan solusi konkret
• Bedakan severity — gunakan prefix seperti nit: untuk minor issues, suggestion: untuk alternatif, tanpa prefix untuk blocking issues

Mengotomasi Apa yang Bisa Diotomasi

Jangan buang waktu reviewer untuk hal yang bisa diotomasi:

• Linter & formatter (ESLint, Prettier) — handle style secara otomatis
• Type checker — pastikan TypeScript build passing sebelum review
• Automated tests — CI harus jalan sebelum reviewer melihat PR
• Danger.js / PR bots — otomasi checklist (ada perubahan DB? Ada migration? Ada perubahan API contract?)

// dangerfile.ts
import { danger, warn, fail } from 'danger'

// Peringatkan jika PR terlalu besar
if (danger.github.pr.additions > 500) {
  warn('PR ini cukup besar. Pertimbangkan untuk dipecah.')
}

// Gagal jika tidak ada perubahan test
const hasTestChanges = danger.git.modified_files.some(
  (f) => f.includes('.test.') || f.includes('.spec.')
)
if (!hasTestChanges) {
  fail('PR ini tidak memiliki perubahan test. Tambahkan test untuk perubahan kamu.')
}

Tips untuk Author PR

Sebagai author, kamu bisa mempermudah hidup reviewer:

1. Tulis PR description yang jelas — jelaskan mengapa perubahan ini dibutuhkan, bukan hanya apa yang berubah
2. Buat PR kecil — di bawah 400 baris idealnya
3. Self-review dulu — baca ulang diff kamu sendiri sebelum request review
4. Tunjukkan area yang perlu perhatian — kalau ada bagian yang tricky, beri komentar di situ

Kesimpulan

Code review adalah investasi terbaik untuk kualitas kode tim kamu dalam jangka panjang. Ini bukan tentang mencari kesalahan, tapi tentang membangun budaya kolaborasi dan pembelajaran bersama. Reviewer yang baik adalah mentor, bukan gatekeeper. Dan author yang baik adalah kolaborator, bukan yang defensif.