Pertama kali Pull Request-mu mendapat belasan komentar bisa terasa tidak menyenangkan. Rasanya seperti semua yang kamu kerjakan salah. Padahal di tim engineering yang sehat, code review adalah hal paling biasa — bahkan engineer senior pun PR-nya dikomentari.

Artikel ini menjelaskan apa itu code review, apa yang biasanya diperiksa, dan bagaimana menanggapi feedback dengan cara yang membuatmu cepat berkembang.

Apa itu code review?

Code review adalah proses memeriksa perubahan kode oleh orang lain sebelum perubahan itu digabungkan ke codebase utama. Di tim yang memakai GitHub, code review biasanya terjadi di dalam Pull Request: reviewer membaca diff, memberi komentar di baris tertentu, lalu menyetujui atau meminta perubahan.

Tujuan code review bukan mencari kesalahan orang, melainkan:

menjaga kualitas codebase dalam jangka panjang,
menemukan masalah lebih awal, saat masih murah diperbaiki,
menyebarkan pengetahuan tentang kode ke lebih banyak orang,
menyamakan standar cara menulis kode di tim.

Apa saja yang diperiksa reviewer?

Setiap tim punya fokus berbeda, tetapi beberapa hal ini hampir selalu diperhatikan.

1. Kebenaran (correctness)

Apakah kode melakukan apa yang seharusnya? Apakah kasus tepi sudah ditangani — data kosong, input tidak valid, atau error dari layanan lain?

2. Keterbacaan

Apakah nama variabel dan fungsi menjelaskan maksudnya? Apakah fungsi terlalu panjang? Kode lebih sering dibaca daripada ditulis, jadi keterbacaan sangat penting.

3. Desain dan struktur

Apakah tanggung jawab kode dipisahkan dengan jelas? Apakah perubahan ini mengikuti pola yang sudah dipakai di codebase? Apakah ada duplikasi yang seharusnya digabungkan?

4. Performa

Apakah ada pola yang akan lambat saat datanya banyak? Contoh klasik adalah N+1 query: mengambil daftar data, lalu menjalankan satu query tambahan untuk setiap item di dalam loop.

// N+1: 1 query untuk daftar pesanan + 1 query per pesanan
const orders = await db.select().from(ordersTable);
for (const order of orders) {
  order.customer = await getCustomer(order.customerId);
}

Kalau ada 1.000 pesanan, kode ini menjalankan 1.001 query. Reviewer biasanya akan menyarankan mengambil data terkait sekaligus, misalnya dengan join atau satu query IN (...).

5. Keamanan

Apakah input pengguna divalidasi? Apakah ada data sensitif yang ikut tercatat di log? Apakah akses ke data sudah dibatasi sesuai hak pengguna?

6. Type safety dan penanganan error

Apakah tipe data didefinisikan dengan jelas, atau banyak any? Apakah error ditangani, atau diam-diam ditelan?

7. Pengujian

Apakah perubahan ini punya test yang sesuai? Apakah test lama masih relevan?

Contoh komentar review

Komentar review yang baik biasanya spesifik dan menjelaskan alasan. Contohnya:

"Fungsi ini menangani validasi sekaligus menyimpan ke database. Bagaimana kalau validasinya dipisah supaya bisa di-test sendiri?"
"Query di dalam loop ini akan dijalankan sekali per item. Bisa diambil sekaligus dengan join?"
"Kalau user null di sini, halaman akan error. Perlu ditangani?"
"Nit: nama data2 kurang menjelaskan isinya — mungkin paidOrders?"

Awalan "nit" (dari nitpick) biasa dipakai untuk saran kecil yang tidak wajib. Membedakan mana yang wajib dan mana yang opsional membantu pembuat PR memprioritaskan.

Cara menanggapi code review

Pisahkan kode dari dirimu

Komentar review menilai kode, bukan kemampuan atau nilai dirimu sebagai orang. Semakin cepat kamu memisahkan keduanya, semakin cepat kamu belajar.

Pahami dulu sebelum membalas

Baca komentar sampai benar-benar paham maksudnya. Kalau belum jelas, tanyakan: "Maksudnya kasus saat X, ya? Boleh contoh singkatnya?"

Tanggapi setiap komentar

Balas komentar dengan tindakan yang kamu ambil:

"Sudah diperbaiki di commit abc123."
"Setuju, sudah dipisah jadi fungsi validateOrder."
"Saya pertahankan karena Y — bagaimana menurutmu?"

Menandai komentar yang sudah ditangani membantu reviewer memeriksa ulang dengan cepat.

Boleh tidak setuju — dengan alasan

Kalau kamu punya alasan kuat untuk pendekatanmu, jelaskan dengan tenang dan terbuka. Diskusi teknis yang sehat justru menghasilkan keputusan terbaik. Kalau tidak menemukan titik temu, ikuti konvensi tim atau minta pendapat orang ketiga.

Catat pola yang berulang

Kalau komentar yang sama muncul di beberapa PR, itu tanda ada kebiasaan yang perlu diubah. Catat, lalu periksa sendiri sebelum membuka PR berikutnya.

Checklist sebelum meminta review

Sebelum menekan tombol Request review, periksa hal ini:

Saya sudah membaca ulang seluruh diff seperti seorang reviewer.
Tidak ada sisa console.log, kode yang dikomentari, atau file yang tidak sengaja ikut.
Kasus tepi utama sudah ditangani.
Test dan pengecekan otomatis lulus.
Deskripsi PR menjelaskan apa, kenapa, dan cara menguji.

Kalau tidak punya reviewer

Belajar sendiri membuat code review sulit didapat. Beberapa alternatif:

Review diri sendiri dengan jeda. Baca kodemu lagi keesokan harinya; kamu akan melihatnya dengan mata yang lebih segar.
Komunitas dan open source. Kontribusi ke proyek open source memberi review dari maintainer.
Alat otomatis. Linter, type checker, dan review berbasis AI bisa menangkap banyak masalah umum. Kelebihan dan batasannya dibahas di AI dalam Software Development.
Program berbasis review. Beberapa program menjadikan review setiap Pull Request sebagai inti latihannya.

Kesimpulan

Code review adalah bagian normal dan penting dari kerja engineer. Reviewer biasanya memeriksa kebenaran, keterbacaan, desain, performa, keamanan, type safety, dan pengujian. Cara terbaik menanggapinya adalah memisahkan kode dari diri sendiri, memahami sebelum membalas, menanggapi setiap komentar, dan belajar dari pola yang berulang.

Kalau kamu ingin terbiasa dengan code review sebelum pekerjaan pertama, simulasi kerja software engineer di KodingCamp mereview setiap Pull Request-mu — termasuk hal-hal seperti N+1 query, type safety, dan struktur kode.

Code Review untuk Pemula: Apa yang Diperiksa dan Cara Menanggapinya