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

Mengapa code review penting:

• Menemukan bug sebelum sampai ke production
• Menyebarkan knowledge tentang codebase ke tim
• Menjaga kualitas dan konsistensi kode
• Kesempatan belajar dari rekan kerja

Checklist saat me-review kode orang lain:

1. Readability — apakah mudah dibaca?

// Cek:
// - Nama variable/fungsi deskriptif?
// - Fungsi tidak terlalu panjang (> 30 baris = perlu perhatian)?
// - Nesting tidak terlalu dalam (> 3 level)?
// - Kode bisa dipahami tanpa komentar?

// RED FLAG
const res = await fn(d, t, u);

// BETTER
const orderSummary = await createOrderSummary(date, total, user);

2. Logic — apakah logicnya benar?

// Cek:
// - Edge cases ditangani? (null, undefined, array kosong, string kosong)
// - Off-by-one errors?
// - Race conditions di async code?

// RED FLAG: bagaimana kalau items kosong?
function getAverage(items) {
  const sum = items.reduce((a, b) => a + b, 0);
  return sum / items.length; // Division by zero!
}

// BETTER
function getAverage(items) {
  if (items.length === 0) return 0;
  const sum = items.reduce((a, b) => a + b, 0);
  return sum / items.length;
}

3. DRY — ada duplikasi?

// Cek:
// - Kode yang copy-paste dari tempat lain?
// - Logic yang sama ditulis lebih dari 2 kali?
// - Magic numbers yang sama di beberapa tempat?

4. Error Handling

// Cek:
// - try/catch di tempat yang tepat?
// - Tidak ada catch kosong?
// - Error message informatif?
// - Async errors ditangani?

// RED FLAG
async function loadData() {
  try { return await fetchData(); }
  catch (e) { return null; } // Error ditelan!
}

5. Security

// Cek:
// - Input sudah di-sanitize?
// - Tidak ada user input langsung di SQL/HTML?
// - Secrets tidak di-hardcode?
// - Auth/authorization di tempat yang tepat?

// RED FLAG
const query = `SELECT * FROM users WHERE name = "${userInput}"`; // SQL injection!

// BETTER
const query = "SELECT * FROM users WHERE name = ?";
db.query(query, [userInput]);

6. Performance

// Cek:
// - Tidak ada N+1 query?
// - Tidak fetch data yang tidak perlu?
// - Loops yang bisa di-optimasi?
// - Re-render yang tidak perlu di React?

// RED FLAG: fetch di dalam loop
for (const userId of userIds) {
  const user = await fetchUser(userId); // N requests!
}

// BETTER: batch fetch
const users = await fetchUsers(userIds); // 1 request

7. Testing

// Cek:
// - Ada test untuk happy path?
// - Ada test untuk edge cases?
// - Test benar-benar menguji behavior, bukan implementasi?
// - Test names deskriptif?

// RED FLAG: test name tidak jelas
test("test1", () => { ... });

// BETTER
test("should return empty array when no products match filter", () => { ... });

Tips memberi feedback code review:

1. Jelaskan mengapa, bukan hanya "ubah ini"
2. Bedakan blocking vs non-blocking — mana yang harus diperbaiki, mana yang saran
3. Berikan contoh solusi alternatif
4. Puji kode yang bagus — code review bukan hanya mencari kesalahan
5. Tanyakan, jangan perintah — "Bagaimana kalau kita...?" bukan "Ubah ini"

Saat kode kamu di-review:

1. Jangan tersinggung — feedback tentang kode, bukan tentang kamu
2. Jelaskan konteks jika reviewer tidak paham
3. Jangan push back tanpa alasan — review itu untuk meningkatkan kualitas
4. Ucapkan terima kasih — reviewer menghabiskan waktu untuk membantu kamu

🎭 Analogi sehari-hari

Code review itu kayak ngecek dokumen sebelum kirim ke klien penting. Kamu tulis proposal — sebelum kirim, mintain rekan kerja baca cepat. Mereka catch typo, logika gak nyambung, klaim yang gak didukung data, gambar yang gak match teks. Tanpa second pair of eyes, dokumen kerennya dirimu BISA jadi awkward di mata orang lain. Code review sama persis — author "blind" ke kode sendiri (familiar bias), reviewer fresh perspective lihat hal yang author miss. Tapi awas: review yang dilakuin sambil ngebatin / asal "approve" tanpa baca = useless. Review yang detail TAPI dengan tone arrogant = bikin author defensive, gak produktif. Best review = teliti + collaborative + fokus ke KODE, bukan ke author.

⚠️ Jebakan yang sering ditemui

• "LGTM" tanpa baca — review autopilot useless. Minimal scan logic + spot check tests.
• Nitpicking minor style — let vs const, indent 2 vs 4 = bukan blocker. Pakai linter/formatter automated, biar review fokus ke logic.
• Tone arrogant / personal — "Kenapa kamu nulis seperti ini?" → bikin author defensive. Pakai "Bagaimana kalau kita coba pendekatan ini?".
• Review PR raksasa (1000+ line) — gak mungkin teliti. Push back: minta pecah PR.
• Block PR untuk preference — "Saya lebih suka if/else daripada ternary" = bukan correctness issue. Approve unless ada bug/security/standard violation.
• Skip review buat senior developer — siapapun bisa bug. Review semua PR equal.
• Author defensive — push back tiap feedback = ego. Reviewer kasih waktu untuk bantu, hargai.
• Review tanpa konteks — gak tau ticket/spec → asal-asalan. Baca PR description + issue dulu.

Checklist Cepat — 5 Menit Code Review

1. Jalanin di local — apakah benar-benar work?
2. Cek PR description — sesuai dengan apa yang di-claim?
3. Logic — ada edge case yang miss? Off-by-one? null handling?
4. Naming — variable/fungsi self-explanatory?
5. Test — ada test untuk new code? Test cover happy path + error path?
6. Security — input validated? SQL injection / XSS / auth bypass?
7. Performance — loop dalam loop? N+1 query? leak memory?
8. Komentar — komentar yang outdated atau redundant?

Tone yang Baik untuk Feedback

❌ "Ini gak bener, ubah."

✓ "Saya lihat fungsi ini handle null case di line 45, tapi line 50 mungkin
   bisa kena undefined. Bagaimana kalau pakai optional chaining? Mau aku
   share contoh?"

❌ "Kenapa kamu pake forEach? Pake map aja."

✓ "Saya rasa map() lebih cocok di sini karena kita transform array. forEach
   biasanya buat side effect. Mau di-explore?"

🎯 Approve, request changes, atau comment?

• Bug pasti (logic salah, security issue, regression) → REQUEST CHANGES (blocking)
• Style preference (preferensi pribadi tapi gak salah) → COMMENT (non-blocking suggestion)
• Ada saran improve tapi PR udah OK → APPROVE + comment dengan suggestion
• Refactor yang luas → COMMENT (suggest scoped follow-up PR), JANGAN block PR ini
• Test missing untuk critical path → REQUEST CHANGES
• Test missing untuk minor utility → COMMENT (suggest tambah)
• Tidak paham konteks → COMMENT (tanya, jangan block)

Aturan: distinguish "blocking" (correctness) vs "non-blocking" (preference). Kalau ragu, comment + approve.

TL;DR: Code review = teliti + collaborative + fokus ke kode (bukan author). Author "blind" ke kode sendiri, reviewer fresh perspective catch bug. Pakai linter/formatter automated biar review fokus ke logic + correctness, bukan style. Tone: tanya jangan perintah ("Bagaimana kalau...?" > "Ubah ini"). Bedain blocking (bug, security) vs non-blocking (preference). PR > 400 line = pecah. Author: gak defensive, jelasin konteks, ucapin terima kasih.