Code Review Feedback: Naikkan Kualitas Tanpa Merusak Trust

Daftar Isi

• Pendahuluan
• Code Review Bukan Sekadar Mencari Kesalahan
• Kenapa Cara Menyampaikan Feedback Itu Penting?
• Prinsip Feedback Code Review yang Membangun
• Format Komentar yang Mudah Ditindaklanjuti
• Contoh Komentar: Sebelum dan Sesudah
• Membedakan Blocking, Suggestion, dan Nitpick
• Cara Menerima Feedback Tanpa Defensif
• Kebiasaan Tim yang Membuat Review Lebih Sehat
• Checklist Code Review untuk Reviewer dan Author
• FAQ
• Kesimpulan

Pendahuluan

Code review sering diperlakukan sebagai gerbang terakhir sebelum kode di-merge. Reviewer mencari bug, mengecek konsistensi, lalu meninggalkan komentar untuk diperbaiki. Namun, ada satu bagian yang mudah terlupakan: setiap komentar juga membentuk cara anggota tim bekerja sama.

Komentar seperti “ini salah” mungkin menyampaikan masalah, tetapi belum tentu membantu author memahami alasan dan solusi yang lebih baik. Sebaliknya, feedback yang terlalu lembut tetapi tidak spesifik juga membuat orang bingung tentang apa yang harus dilakukan.

Code review yang sehat membutuhkan dua hal sekaligus: standar teknis yang kuat dan komunikasi yang menghargai manusia di balik kode. Artikel ini membahas cara menyeimbangkan keduanya agar review bukan menjadi ajang mencari siapa yang keliru, melainkan proses membangun kode dan tim yang lebih baik.

Code Review Bukan Sekadar Mencari Kesalahan

Tujuan code review memang mencakup menemukan defect sebelum masuk ke production. Tetapi nilainya jauh lebih besar dari itu. Review yang dilakukan dengan baik membantu tim:

• Sharing pengetahuan tentang domain dan codebase
• Menjaga keputusan arsitektur tetap konsisten
• Menemukan asumsi yang belum tertulis
• Meningkatkan kemampuan engineer melalui diskusi antar tim
• Mengurangi ketergantungan pada satu orang
• Membangun standar kualitas yang baik untuk jangka panjang

Karena itu, reviewer bukan “polisi kode” dan author bukan peserta ujian. Keduanya sedang berkolaborasi menyelesaikan masalah yang sama. Kode adalah objek yang ditinjau; kemampuan atau harga diri pembuatnya bukan objek yang ditinjau.

Perubahan sudut pandang ini mungkin terlihat kecil, tetapi sangat memengaruhi bahasa yang dipakai. “Kenapa kamu membuatnya seperti ini?” terasa seperti interogasi. “Apa pertimbangan di balik pendekatan ini?” membuka ruang untuk konteks yang mungkin belum diketahui reviewer.

Kenapa Cara Menyampaikan Feedback Itu Penting?

Saat memberikan feedback, kita perlu mempertimbangkan kondisi orang yang menerimanya. Author mungkin sudah menghabiskan beberapa hari mengerjakan perubahan tersebut, sedang menghadapi deadline, atau belum mengenal bagian codebase itu dengan baik. Karena itu, komentar yang tidak jelas atau terkesan merendahkan dapat membuat pembahasan kode berubah menjadi konflik personal.

Cara penyampaian yang baik memberi beberapa manfaat nyata:

1. Masalah lebih cepat diselesaikan

Komentar yang menjelaskan letak masalah, risikonya, dan arah perbaikannya dapat mengurangi diskusi bolak-balik. Author pun tidak perlu menebak maksud reviewer.

2. Rasa aman di dalam tim tetap terjaga

Anggota tim yang merasa aman lebih berani mengakui ketidaktahuan, bertanya, dan menawarkan ide. Ini penting karena banyak bug serius justru lahir dari asumsi yang tidak pernah dipertanyakan.

3. Pengetahuan bertahan lebih lama

Perintah hanya memberi tahu seseorang tentang apa yang harus diubah. Penjelasan yang disertai alasan membantunya mengambil keputusan lebih baik saat mengerjakan perubahan berikutnya.

4. Review tidak bergantung pada senioritas

Jika setiap komentar dinilai berdasarkan bukti dan dampaknya, engineer junior pun dapat menemukan masalah penting dalam kode engineer senior. Dengan begitu, kualitas diskusi tidak ditentukan oleh jabatan.

Prinsip Feedback Code Review yang Membangun

1. Kritik kode, bukan orangnya

Hindari kalimat yang seolah-olah mengaitkan masalah pada kode dengan kemampuan author.

• Kurang baik: “Kamu tidak memahami siklus hidup komponen ini.”
• Lebih baik: “Subscription ini belum dihentikan saat komponen dilepas, sehingga jumlah listener bisa terus bertambah setiap kali halaman dibuka.”

Kalimat kedua berfokus pada perilaku kode yang dapat diamati dan risiko yang perlu diperbaiki, bukan pada kemampuan orang yang menulisnya.

2. Jelaskan alasan, bukan hanya preferensi

Komentar “ubah ini” tidak memberikan konteks yang cukup. Jelaskan alasan perubahan tersebut, misalnya karena ada risiko race condition, masalah konsistensi API, aksesibilitas, performa, atau kemudahan pemeliharaan.

Jika alasannya hanya selera pribadi, pertimbangkan kembali apakah komentar itu benar-benar diperlukan. Preferensi yang sering muncul sebaiknya dijadikan aturan dalam formatter, linter, atau panduan tim agar tidak perlu diperdebatkan di setiap review.

3. Buat komentar yang spesifik dan mudah ditindaklanjuti

“Kode ini membingungkan” terlalu luas. Tunjukkan bagian yang sulit dipahami dan tindakan yang mungkin membantu:

Kondisi ini menangani tiga status sekaligus sehingga alur ketika terjadi error sulit diikuti. Bagaimana kalau validasi expired dipindahkan ke bagian awal sebagai guard clause, sebelum proses utama dijalankan?

Dengan komentar tersebut, author dapat memahami masalahnya sekaligus mengetahui salah satu cara untuk memperbaikinya.

4. Bedakan fakta, pertanyaan, dan preferensi

Jangan menyamarkan perintah sebagai pertanyaan. Jika perubahan wajib dilakukan karena ada bug, sampaikan dengan jelas. Sebaliknya, jika Kamu belum memahami sesuatu, tanyakan lebih dahulu tanpa langsung menganggap implementasinya salah.

• Fakta: “Endpoint ini mengembalikan data pengguna tanpa memeriksa tenant.”
• Pertanyaan: “Apakah middleware pada route ini sudah memastikan tenant diperiksa?”
• Preferensi: “Aku lebih suka memakai early return di sini karena alurnya lebih mudah dibaca, tetapi perubahan ini tidak wajib dilakukan.”

5. Akui bagian yang sudah baik

Code review tidak harus hanya berisi daftar masalah. Komentar positif yang spesifik membantu tim mengenali pola yang patut dipertahankan:

Pemisahan parser dan validator pada perubahan ini membuat skenario error jauh lebih mudah diuji. Pola ini bagus jika diterapkan pada endpoint lain juga.

Pujian umum memang terasa ramah, tetapi pujian yang spesifik juga menunjukkan praktik seperti apa yang dihargai oleh tim.

6. Tawarkan opsi, jangan mengambil alih

Reviewer perlu memberikan arah tanpa mengambil alih dan menulis ulang seluruh solusi milik author. Untuk masalah yang tidak kritis, tawarkan satu atau dua alternatif beserta kelebihan dan kekurangannya, lalu beri author ruang untuk memilih.

Format Komentar yang Mudah Ditindaklanjuti

Format sederhana berikut membuat komentar lebih jelas:

Observasi → Dampak → Saran atau pertanyaan

Contohnya:

Query ini dijalankan berulang kali untuk setiap order. Pada akun yang memiliki banyak order, jumlah query akan ikut bertambah dan membuat endpoint menjadi lambat. Bisakah seluruh data relasinya diambil sekaligus menggunakan eager loading?

Tiga bagian tersebut menjawab pertanyaan utama author:

1. Bagian mana yang sedang dibahas?
2. Kenapa bagian itu bermasalah?
3. Apa langkah berikutnya?

Tidak semua komentar harus panjang. Untuk masalah yang jelas dan sudah punya standar tim, komentar singkat cukup:

Wajib diperbaiki: Token ini ikut tercatat di log. Tolong samarkan token sebelum merge karena log tersebut dapat diakses oleh sistem observability eksternal.

Label di awal komentar membantu author memahami tingkat urgensinya tanpa harus menebak dari nada tulisan.

Contoh Komentar: Sebelum dan Sesudah

Contoh 1: Terlalu menghakimi

Sebelum:

Ini desain yang buruk. Pakai service saja.

Sesudah:

Handler ini menangani validasi, akses database, dan pengiriman email sekaligus. Jika proses bisnisnya dipindahkan ke service, kegagalan pengiriman email akan lebih mudah diuji dan dicoba ulang. Menurutmu, apakah logika tersebut bisa dipisahkan sebelum PR ini di-merge?

Contoh 2: Terlalu samar

Sebelum:

Tolong diperbaiki.

Sesudah:

Wajib diperbaiki: Saat items kosong, reduce() ini tidak memiliki nilai awal sehingga akan memunculkan error. Tambahkan nilai awal 0 atau tangani kondisi kosong sebelum fungsi tersebut dipanggil.

Contoh 3: Preferensi dianggap aturan

Sebelum:

Ganti nama variabel ini. Aku tidak suka singkatan.

Sesudah:

Saran kecil: Bagaimana kalau cfg diubah menjadi paymentConfig? Nama yang lebih jelas akan membantu karena fungsi ini memakai beberapa konfigurasi lain. Perubahan ini tidak wajib.

Contoh 4: Pertanyaan yang terdengar menyalahkan

Sebelum:

Kenapa kamu tidak pakai cache?

Sesudah:

Apakah data ini harus selalu diperbarui secara real-time? Jika data yang terlambat satu menit masih dapat diterima, cache dengan masa berlaku singkat mungkin bisa mengurangi beban pada API sumber.

Perbedaannya bukan sekadar pilihan kata yang lebih sopan. Versi “sesudah” memberikan konteks teknis yang lebih lengkap sehingga diskusi dapat langsung mengarah pada penyelesaian.

Membedakan Blocking, Suggestion, dan Nitpick

Salah satu sumber frustrasi terbesar adalah author tidak tahu komentar mana yang wajib diselesaikan sebelum merge. Gunakan label yang disepakati tim.

Blocking

Komentar jenis ini harus ditangani sebelum merge karena menyangkut kebenaran fungsi, keamanan, risiko kehilangan data, kebutuhan produk, atau risiko operasional yang nyata.

Wajib diperbaiki: Pembaruan saldo dan pencatatan transaksi tidak dijalankan dalam satu database transaction. Jika proses kedua gagal, jumlah saldo dan catatan pada ledger dapat berbeda.

Suggestion

Perbaikan ini bermanfaat, tetapi masih terbuka untuk didiskusikan atau dikerjakan secara terpisah.

Saran: Proses penyusunan response yang sama muncul di tiga controller. Kita bisa memindahkannya ke serializer agar formatnya konsisten. Perubahan ini boleh dikerjakan dalam PR sekarang atau PR lanjutan.

Nitpick

Ini adalah perubahan kecil terkait keterbacaan atau gaya penulisan kode yang tidak seharusnya menghambat merge.

Saran kecil: Nama result bisa dibuat lebih spesifik menjadi eligibleInvoices. Perubahan ini tidak wajib.

Tim juga dapat memakai awalan seperti pertanyaan:, apresiasi:, atau todo:. Sistem labelnya tidak perlu rumit; yang penting semua anggota tim memahami arti setiap label.

Cara Menerima Feedback Tanpa Defensif

Budaya code review yang sehat bukan hanya tanggung jawab reviewer. Author juga perlu melihat komentar sebagai masukan terhadap kode yang sedang dikerjakan, bukan sebagai penilaian terhadap dirinya.

Beberapa kebiasaan yang membantu:

• Tunggu sejenak sebelum membalas komentar yang terasa tajam
• Minta klarifikasi jika dampak atau ekspektasinya belum jelas
• Jelaskan konteks serta kelebihan dan kekurangan solusi, bukan sekadar membela pilihan sendiri
• Akui masalah dengan singkat jika reviewer benar
• Pindahkan diskusi yang panjang ke panggilan singkat, lalu tulis kesimpulannya di PR
• Jangan menutup thread sebelum kedua pihak sepakat bahwa masalahnya sudah ditangani

Jawaban seperti “Benar juga, aku sudah menambahkan pengecekan untuk kondisi kosong” sudah cukup. Tidak semua komentar membutuhkan penjelasan atau pembelaan panjang.

Author juga boleh berbeda pendapat. Respons yang sehat bisa berbunyi:

Aku setuju duplikasi ini perlu diperhatikan. Namun, untuk PR ini aku memilih mempertahankannya karena kedua alur tersebut akan berubah secara terpisah bulan depan. Aku sudah menambahkan komentar yang menjelaskan alasannya. Apakah itu sudah menjawab kekhawatiranmu?

Tujuannya bukan untuk selalu menyetujui reviewer, melainkan memastikan keputusan akhir dibuat setelah mempertimbangkan alasan dan risikonya.

Kebiasaan Tim yang Membuat Review Lebih Sehat

Feedback yang baik tidak akan banyak membantu jika proses code review tim masih buruk. Karena itu, tim perlu menciptakan kebiasaan yang mendukung review berkualitas.

Buat pull request tetap kecil

PR yang kecil lebih mudah dipahami sehingga reviewer dapat memberikan feedback dengan lebih teliti. Sebaliknya, PR yang berisi ribuan baris perubahan sering ditinjau secara terburu-buru dan hanya mendapatkan komentar di permukaan.

Berikan konteks sejak awal

Deskripsi PR sebaiknya menjelaskan tujuan perubahan, keputusan penting, cara pengujian, tangkapan layar jika diperlukan, serta bagian yang membutuhkan perhatian khusus. Jangan membuat reviewer menebak tujuan perubahan hanya dari diff.

Otomatiskan perdebatan mekanis

Format kode, urutan import, dan aturan gaya dasar sebaiknya diperiksa secara otomatis oleh tool. Waktu reviewer akan lebih bermanfaat jika digunakan untuk membahas kebenaran fungsi, desain, keamanan, dan kemudahan pemeliharaan.

Tetapkan waktu respons yang realistis

Kesepakatan seperti “review pertama diberikan dalam satu hari kerja” membantu mencegah PR terlupakan. Di sisi lain, reviewer tidak perlu meninggalkan pekerjaan yang sedang membutuhkan fokus setiap kali notifikasi masuk.

Beralih ke percakapan langsung jika tulisan tidak cukup

Jika diskusi tidak mengalami kemajuan setelah beberapa kali saling membalas komentar, lanjutkan melalui percakapan langsung selama 10–15 menit. Setelah itu, tulis keputusan beserta alasannya di PR agar tetap terdokumentasi.

Evaluasi pola, bukan menyalahkan individu

Jika komentar yang sama terus muncul, akar masalahnya mungkin terletak pada dokumentasi, tool, proses onboarding, atau arsitektur. Perbaiki sumber masalah tersebut agar tim tidak perlu mengulang diskusi yang sama di setiap PR.

Checklist Code Review untuk Reviewer dan Author

Untuk reviewer

• Apakah aku memahami tujuan perubahan sebelum mengomentari implementasi?
• Apakah komentar ini membahas kode, bukan pribadi pembuatnya?
• Apakah alasan dan dampaknya sudah jelas?
• Apakah author tahu komentar ini wajib ditangani atau sekadar saran?
• Apakah saran ini standar tim atau hanya preferensi pribadi?
• Apakah ada bagian yang layak diapresiasi secara spesifik?
• Apakah diskusi ini akan lebih cepat diselesaikan lewat percakapan langsung?

Untuk author

• Apakah deskripsi PR memberi konteks yang cukup?
• Apakah aku sudah memeriksa sendiri PR ini dan membersihkan perubahan yang tidak perlu?
• Apakah pengujian dan langkah validasi sudah disertakan?
• Apakah aku sudah memahami masalah yang disampaikan sebelum menjawab?
• Apakah keputusan dari diskusi lisan sudah ditulis kembali?
• Apakah semua komentar yang wajib ditangani benar-benar sudah diselesaikan?

Checklist ini bukan birokrasi tambahan. Gunakan sebagai pengingat sampai kebiasaan yang baik terbentuk, kemudian sesuaikan isinya dengan kebutuhan tim.

FAQ

Apakah reviewer harus selalu menawarkan solusi?

Tidak. Reviewer perlu menjelaskan masalah beserta dampaknya, tetapi tidak harus selalu mengetahui solusi terbaik. Pertanyaan yang jelas sering kali lebih berguna daripada saran implementasi yang diberikan sebelum masalahnya benar-benar dipahami.

Bagaimana menghadapi komentar code review yang terasa kasar?

Mulailah dengan meminta penjelasan lebih lanjut mengenai masalah teknisnya, dan hindari membalas saat emosi masih tinggi. Jika cara berkomunikasi seperti itu terus berulang, bicarakan secara pribadi atau libatkan engineering manager. Menjaga standar komunikasi adalah tanggung jawab tim, bukan beban author seorang diri.

Kapan diskusi sebaiknya dipindahkan dari PR ke meeting?

Pindahkan diskusi ketika percakapan di thread mulai berulang, terdapat perbedaan asumsi yang mendasar, atau penjelasannya membutuhkan diagram dan konteks yang lebih luas. Setelah pertemuan, tulis ringkasan keputusan di PR.

Bolehkah approve PR yang masih memiliki nitpick?

Boleh, selama label dan harapannya jelas. Saran kecil seharusnya tidak tiba-tiba berubah menjadi syarat merge. Reviewer tetap dapat menyetujui PR sambil meninggalkan saran yang tidak wajib dikerjakan.

Bagaimana jika reviewer dan author tidak sepakat?

Kembalikan pembahasan pada tujuan produk, standar tim, data, serta kelebihan dan kekurangan setiap pilihan yang dapat diuji. Jika masih menemui jalan buntu, mintalah keputusan dari maintainer atau penanggung jawab area tersebut, lalu dokumentasikan hasilnya.

Apakah AI bisa menggantikan feedback manusia dalam code review?

AI dapat membantu menemukan pola bug, merangkum perubahan, dan menangani pemeriksaan yang berulang. Namun, konteks bisnis, pertimbangan arsitektur, proses mentoring, dan kepekaan dalam berkomunikasi tetap membutuhkan penilaian manusia.

Kesimpulan

Code review yang baik tidak hanya menghasilkan kode yang lebih aman. Proses ini juga membantu menyebarkan pengetahuan, memperjelas alasan di balik keputusan teknis, dan membuat anggota tim lebih percaya diri untuk berdiskusi secara terbuka.

Feedback yang membangun bukan berarti menghindari kritik atau menurunkan standar. Justru sebaliknya, setiap masalah perlu disampaikan secara spesifik, jelas, disertai alasan, dan tetap menghargai orang yang menerimanya. Ketika reviewer dan author melihat satu sama lain sebagai rekan yang sedang menyelesaikan masalah bersama, code review tidak lagi terasa seperti gerbang yang menegangkan. Proses tersebut menjadi salah satu sarana belajar paling efektif bagi tim engineering.

Seperti apa komentar code review yang paling membantu Kamu berkembang? Bagikan pola feedback yang berhasil dipakai di timmu.