Budaya Code Review yang Sehat

Dari pengalaman saya berpindah dari kontributor individu jadi Kepala IT yang mengurus tim dengan latar belakang berbeda-beda, saya melihat satu pola berulang: tim yang code review-nya sehat mengirim fitur lebih cepat, bukan lebih lambat. Yang bikin lambat itu bukan review-nya, tapi review yang jadi ajang debat ego, atau sebaliknya, review yang asal approve tanpa dibaca. Dua-duanya sama-sama mahal, cuma beda bentuk kerugiannya. Yang satu bikin kontributor jera dan takut push kode, yang satu lagi bikin bug lolos ke production dan baru ketahuan pas ada yang komplain.

Kritik kode, bukan kritik orang

Prinsip paling dasar yang saya pegang: komentar review harus soal kode, bukan soal orang yang menulisnya. Ini kedengarannya klise, tapi praktiknya gampang meleset kalau tidak sadar. Bandingkan dua kalimat ini:

"Kenapa kamu pakai query di dalam loop? Ini kan udah dibahas kemarin."

"Query ini jalan di dalam loop, jadi kalau datanya besar bisa N+1. Coba eager load relasinya, misalnya dengan with('relasi') sebelum loop-nya."

Kalimat kedua tidak menyebut siapa yang salah, langsung ke masalah teknis, dan memberi arah solusi. Saya juga membiasakan diri menulis komentar dalam bentuk pertanyaan kalau memang belum yakin, misalnya "apakah ada alasan khusus pakai pendekatan ini dibanding X?" daripada langsung menuduh salah. Kadang penulis kode punya konteks yang reviewer tidak tahu, dan pertanyaan membuka ruang diskusi tanpa membuat orang defensif duluan.

Hal lain yang sering dilupakan: kasih pujian juga, bukan cuma catatan perbaikan. Kalau ada pendekatan yang rapi atau solusi yang elegan, sebutkan. Ini bukan basa-basi, tapi sinyal bahwa reviewer benar-benar membaca kode, bukan sekadar cari-cari kesalahan.

Beri label pada tingkat keseriusan komentar

Salah satu kebiasaan yang paling membantu tim saya adalah memberi prefix pada setiap komentar review sesuai urgensinya, semacam konvensi yang cukup umum dipakai banyak tim:

• blocking: harus diperbaiki sebelum merge, biasanya soal bug, keamanan, atau data yang bisa rusak.
• nit: hal kecil soal gaya penulisan atau preferensi pribadi, boleh diabaikan kalau kontributor tidak setuju.
• question: sekadar ingin tahu alasannya, bukan tuntutan perubahan.

Tanpa label seperti ini, kontributor sering kesulitan membedakan mana komentar yang wajib diselesaikan dan mana yang cuma opini reviewer. Efeknya, satu PR bisa bolak-balik berkali-kali untuk hal yang sebenarnya tidak krusial, atau sebaliknya, hal yang krusial malah terlewat karena tenggelam di antara komentar-komentar kecil.

Kapan cukup cepat, kapan harus mendalam

Tidak semua perubahan butuh porsi review yang sama. Saya biasa membagi berdasarkan dua hal: seberapa besar dampaknya kalau salah, dan seberapa reversibel perubahannya.

Perubahan kecil yang mudah dibalik, misalnya perbaikan teks di UI, penyesuaian style, atau refactor lokal yang tidak menyentuh logika bisnis, cukup dicek sekilas: apakah masuk akal, apakah ada test yang relevan, lalu approve. Menahan PR seperti ini demi review mendalam justru kontraproduktif, karena risikonya kecil dan biaya menunggu justru lebih besar dari biaya salahnya.

Sebaliknya, perubahan yang menyentuh alur data penting, autentikasi, pembayaran, atau apa pun yang sulit dibatalkan setelah di-deploy, pantas mendapat perhatian lebih. Di sini saya biasanya benar-benar menjalankan kodenya secara lokal, bukan cuma membaca diff-nya, dan mengecek skenario edge case: apa yang terjadi kalau input kosong, kalau request gagal di tengah jalan, kalau dua proses jalan bersamaan. Sebagai ilustrasi, tim yang menerapkan pembagian seperti ini biasanya merasa review jadi lebih cepat secara keseluruhan, karena energi tidak habis dipakai rata di semua PR.

Satu penanda praktis yang saya pakai: kalau saya butuh lebih dari sekali baca untuk paham maksud PR-nya, itu tanda perubahannya perlu dipecah lebih kecil, bukan tanda saya harus baca lebih teliti. PR besar cenderung dapat review dangkal justru karena reviewer kelelahan di tengah jalan, bukan karena PR-nya memang aman.

Takeaway

Review yang sehat itu kritik ke kode bukan ke orang, komentar diberi konteks urgensi supaya jelas mana yang wajib dan mana yang opsional, dan porsi kedalaman review disesuaikan dengan risiko serta reversibilitas perubahan, bukan dipukul rata. Tujuannya sederhana: kontributor tetap berani push kode, sekaligus kualitas tetap terjaga sebelum sampai ke production.