Code Review yang Gak Bikin Musuhan: 5 Aturan yang Gue Pelajarin

Gue inget code review pertama yang gue kasih ke junior. Ada satu function 200 baris yang nge-handle auth. Gue nulis di comment: "Function ini terlalu panjang, refactor jadi kecil-kecil. Pake early return, jangan nested if. Pindah logic ke service. Dan naming-nya kurang deskriptif."

10 comment. Semua critical. Junior baca, diem 3 hari, terus ngelakuin refactor yang setengah-setengah. Hasilnya: function jadi 4 bagian tapi masih berantakan, karena dia refactor tanpa paham kenapa. Gue frustrated. Dia burned out.

Saat itu gue sadar: code review gue bukan review. Itu critique tanpa solusi. Gue ngasih 10 masalah tanpa context, tanpa contoh, tanpa prioritas. Junior kewalahan, gue kecewa. Code review yang bener harus bikin code lebih baik, bukan bikin dev merasa lebih buruk.

Ini 5 aturan code review yang gue pelajarin keras-keras - dari yang bikin musuhan jadi yang bikin tim tumbuh.

---

Aturan 1: Komen Masalah, Bukan Orangnya

Salah:

"Lo kok nulis kayak gini sih, gak baca dokumentasi ya?"

Bener:

"Approach ini punya potential issue kalau userId null. Mungkin bisa pakai null check sebelum findUser?"

Bedanya: pertama nyerang orang ("lo"). Kedua nyerang masalah ("approach ini"). Junior yang baca yang kedua tau harus ngapin. Junior yang baca yang pertama cuma ngerasa diserang.

Aturan praktis: ganti "lo/kamu" jadi "code ini/function ini/approach ini." Kalau emang musti personal, pakai "kita" - "kita bisa coba approach alternatif." Collective, bukan accusative.

Code review itu tentang code, bukan about coder. Lo review hasil kerja, bukan identitas orang.

---

Aturan 2: Bukan Cuma "Apa Salahnya," Tapi "Kenapa" dan "Gimana Benernya"

Code review yang gak berguna:

"Naming data gak deskriptif."

Code review yang bener:

"Variable data bisa lebih deskriptif. Karena isinya userTransactionHistory, mungkin bisa rename jadi userTransactions biar context-nya jelas. Fungsinya buat apa nih? Kalau buat display di dashboard, mungkin recentTransactions lebih tepat."

Bedanya: yang pertama cuma ngasih tau masalah. Yang kedua ngasih tau masalah + kenapa + solusi + pertanyaan context. Reviewer dan author jadi diskusi, bukan hakim dan terdakwa.

Format yang gue pakai:

[Issue] Variable data gak deskriptif
[Why] Reader gak tau isinya apa tanpa baca code lebih jauh
[Suggestion] Rename jadi userTransactions atau recentTransactions
[Question] Variable ini dipake di mana selain function ini?

4 baris. Lebih panjang dari "rename data" doang. Tapi author dapet context, solusi, dan kesempatan diskusi. Code review jadi dialog, bukan monolog.

---

Aturan 3: Prioritas Masalah - Bukan Semua Setara

Gue dulu kasih 20 comment tanpa bedain mana yang critical, mana yang nitpick. Author baca semua, harus prioritaskan sendiri. Hasilnya: dia fix yang gampang dulu (whitespace, naming), baru yang kritis (logic bug). Urutan salah.

Sekarang gue pakai label:

• [Blocker] - musti fix sebelum merge. Logic bug, security issue, data loss.
• [Important] - should fix, tapi bisa merge dulu + follow-up issue. Performance, edge case gak ke-handle.
• [Nitpick] - optional. Style, naming preference, comment clarification. Boleh skip.

Contoh:

[Blocker] SQL injection di line 45 - query di-string-concat, harus parameterize
[Important] Function ini N+1 query, bisa dioptimasi pake JOIN
[Nitpick] Variable i bisa jadi index biar lebih deskriptif

Author tau: fix Blocker dulu, Important kapan aja, Nitpick kalau sempat. Lo gak nge-forcing 20 fix sekaligus. Lo ngasih roadmap.

Jangan terlalu banyak Blocker. Kalau lo label semua Blocker, author panic. Kalau lo label 3 dari 20 sebagai Blocker, author tau: 3 ini kritis, sisanya bisa nego. Restraint itu skill.

---

Aturan 4: Jangan Nulis Kode Pengganti - Diskusi Dulu

Gue dulu sering nulis kode solusi langsung di comment:

• const data = await fetchUser(id)
• const user = await fetchUser(id)
• if (!user) throw new NotFoundError()

Looks helpful. Tapi masalahnya: author gak paham kenapa. Dia copy-paste, merge, selesai. Next time, dia bikin error sama karena gak belajar.

Sekarang gue diskusi dulu:

"Line 12: fetchUser bisa return null kalau user gak ada. Mau di-handle gimana? Throw error? Return 404? Null object pattern? Aku sih suggest throw NotFoundError biar consistent sama findOrder di file X, tapi lo tau konteks-nya lebih."

Author harus mikir. Lo ngasih option + suggest + reasoning, tapi author yang mutusin. Kalau dia balik nanya "kenapa throw, bukan return null?", lo bisa jelasin trade-off.

Kecuali kalau emergency. Production down, fix cepet, gue nulis kode solusi langsung. Tapi comment: "Ini fix darurat, nanti kita diskusi best approach-nya." Bukan "ini cara bener, lo cara salah."

---

Aturan 5: Pujian Juga Penting - Code Review Bukan Cuma Cari Salah

Code review yang cuma critique bikin author ngerasa kerjaannya gak ada bener. Padahal mungkin 90% code-nya bagus, 10% yang perlu di-fix. Kalau lo cuma komen 10%, author gak tau yang 90% udah bagus.

Sekarang gue selalu kasih pujian spesifik:

[Good] Error handling di line 23 rapi, pake custom error class, log-nya informatif
[Good] Test coverage-nya lengkap, edge case null di-cover
[Good] Function calculateRefund bener-bener kecil dan fokus, nice

Pujian yang spesifik beda sama pujian generic. "Nice code!" gak berguna. "Error handling-nya rapi, pake custom error class" ngasih tau apa yang bagus, jadi author tau pattern itu keep up.

Filosofi: code review tujuannya nge-raise code quality, bukan nge-lower author morale. Kalau author ngerasa kerjaan diapresiasi, dia lebih terbuka ke critique. Kalau author ngerasa diserang, dia defensive. Defensive author = gak nerima feedback = code gak improve.

---

Quick Comparison: Code Review Toxic vs Healthy

| Aspek | Toxic Review | Healthy Review |
|---|---|---|
| Tone | "Lo kok..." (personal) | "Code ini..." (impersonal) |
| Content | Masalah doang | Masalah + kenapa + solusi + diskusi |
| Prioritas | Semua setara (author bingung) | Label Blocker/Important/Nitpick |
| Solusi | "Ini kode bener" (di-push ke author) | Diskusi dulu, author yang mutusin |
| Pujian | Gak ada | Spesifik ke pattern yang bagus |
| Hasil | Author defensive, code gak improve | Author belajar, code makin bagus |
| Tim | Burnout, turnover | Psychological safety, growth |

---

Yang Sering Disalahpahami

"Code review = cari semua bug." - Salah. Code review = make sure code sesuai requirement + identify risk + share knowledge. Kalau lo cari bug doang, lo jadi QA. Reviewer beda sama QA.

"Reviewer harus nemuin minimal 5 comment." - Toxic quota. Kalau code-nya udah bagus, bilang bagus. Jangan nitpick cuma buat quota. Nitpick yang gak penting bikin noise, hide comment yang penting.

"Author musti nerima semua feedback." - Salah. Author boleh nolak dengan reasoning. Code review itu diskusi, bukan decree. Kalau reviewer ngomment "rename data jadi userData" tapi author lebih prefer userTransactions, diskusi. Jangan "gue reviewer, lo author, lo nurut."

"Senior dev gak perlu di-review." - Fatal. Senior dev juga salah. Code review bukan about junior vs senior. Code review about second pair of eyes. Linus Torvalds masih kena review di Linux kernel. Ego = musuh code quality.

---

Penutup yang Jujur

Code review yang gue pelajarin 5 tahun terakhir: bukan tentang nge-judge code orang lain, tapi tentang bikin code dan author sama-sama tumbuh. Lo ngasih feedback yang actionable, author dapet insight, code makin bagus, author makin jago. Win-win.

Filosofi yang gue pelajarin: code review itu dialog, bukan verdict. Reviewer bukan hakim, author bukan terdakwa. Kedua-duanya kontributor yang pengen code makin bagus.

5 aturan yang gue pakai sekarang:
1. Komen masalah, bukan orangnya (ganti "lo" jadi "code ini")
2. Masalah + kenapa + solusi + diskusi (bukan masalah doang)
3. Prioritas label (Blocker/Important/Nitpick)
4. Diskusi dulu, jangan langsung push kode solusi
5. Pujian spesifik ke pattern yang bagus

Kalau lo reviewer yang suka nge-judge, coba inget: pertama kali lo belajar nulis code, lo juga bikin function 200 baris kayak junior itu. Lo gak langsung jago. Senior dev bukan yang gak pernah salah, tapi yang udah salah dan belajar. Kasih junior yang sama kesempatan yang lo dapet dulu.

Kalau lo author yang sering kena review pedas, inget: feedback tentang code, bukan about lo. Ambil yang bermanfaat, skip yang toxic. Tapi kalau reviewernya konsisten toxic, mungkin tim-nya yang harus di-review.

---

Sumber

• Google Engineering Practices: Code Review Standard
• Google Engineering Practices: What to Look For