Code review: yang dicari, yang diabaikan

Kebanyakan review mati di "nit: rename variable" — 20 komentar, nol bug ketemu. Review yang bagus bukan yang paling banyak komentar, tapi yang paling tahu apa yang layak dikomentari.

Urutan prioritas (dari atas ke bawah)

Correctness — logic salah, off-by-one, null/undefined, race condition, error path gak ke-handle.
Security — input dari luar gak divalidasi, secret ke-commit, query string concat (SQLi), authz dicek di UI doang bukan di server.
Data — migration reversibel? backfill aman? query bisa jadi full-scan di tabel 10 juta baris?
Test — apakah test-nya beneran nangkep bug, atau cuma nge-assert expect(true).toBe(true)? Test yang gak bisa gagal = dokumentasi, bukan test.
Design/API — nama fungsi bohong? parameter kelewat banyak? coupling baru yang gak perlu?
Style — biarkan linter/formatter. Kalau kamu ngomentarin spasi, berarti tooling tim kamu kurang.

Kalau 1–3 bersih, review bisa selesai dalam 2 menit. Itu bukan malas — itu tepat sasaran.

Contoh komentar: buruk vs berguna

❌ "Ini salah."
✅ "Kalau `user` null (baris 42), `user.id` throw. Kasus ini kejadian waktu
   token expired — lihat handler di auth.ts:88. Saran: early return 401."

❌ "Kenapa gak pakai map aja?"
✅ "Loop ini O(n²) karena `includes` di dalam `for`. Di 10k item = ~50M
   compare. Set bikin O(n). Blocking? Kalau gak, skip aja."

❌ "nit: rename x → userId"
✅ (gak dikomentari — linter ESLint `id-length` atau IDE rename)

Pola: masalah → bukti/skenario → saran. Bukan penilaian orangnya.

Checklist reviewer (5 menit pertama)

[ ] Baca deskripsi PR dulu — kalau gak ada, itu temuan pertama
[ ] Lihat diff test sebelum diff kode — test kasih tahu maksud perubahan
[ ] Cek file yang "gak seharusnya ada": .env, lockfile random, config prod
[ ] Cari catch kosong, TODO, console.log, any/unknown cast
[ ] Tanya: "kalau ini rollback jam 3 pagi, gampang?"
[ ] Kalau PR >400 baris: minta dipecah. Review besar = review dangkal, guaranteed

Anti-pattern yang sering kejadian

Anti-pattern	Kenapa busuk
Rubber stamp "LGTM 👍"	Approve tanpa baca = bug lolos + trust rusak
Review 3 hari kemudian	Context hilang, author udah pindah task
Nitpick tsunami	Author males baca komentar penting, kelelep di noise
"Kenapa gak gini?" tanpa alasan	Debat selera, bukan engineering
Reviewer jadi gatekeeper tunggal	Bus factor 1, author gak belajar
Author defensif	Review jadi ajang menang, bukan cari bug

Aturan praktis: komentar harus punya label — blocking:, suggestion:, question:, nit:. Author langsung tahu mana yang wajib. Ini satu perubahan kecil yang nyelametin banyak PR.

Satu hal yang bisa langsung dipakai

Pasang template PR minimal 3 baris di repo:

## Apa yang berubah
## Kenapa (link issue/konteks)
## Cara verifikasi (command / langkah manual)

Reviewer yang dapat "kenapa" 60% lebih cepat nemu masalah nyata — karena dia gak lagi nebak maksud kode.

Takeaway

Review bukan cari yang bisa dikomentari. Review cari yang bisa bikin production jam 3 pagi. Sisanya — serahkan ke linter.