Komentar “ini salah” pada pull request mungkin tepat, tetapi tidak cukup membantu orang membaikinya. Sebaliknya, menyembunyikan isu penting kerana takut kedengaran keras juga merugikan produk. Code review yang baik mencari keseimbangan: jelas tentang risiko, jelas tentang cadangan, dan hormat kepada orang yang menulis kod.
Nyatakan kesan kepada pengguna atau sistem
Contohnya: “Jika API lambat, butang ini boleh dihantar dua kali dan mencipta dua rekod. Boleh kita disable sementara request berjalan?” Itu memberi sebab serta arah. Untuk pilihan gaya yang tidak wajib, tandakan sebagai cadangan dan jangan menyamakannya dengan pepijat produksi. Pasukan boleh menetapkan konvensyen formatter supaya perbincangan tentang jarak dan tanda baca tidak memenuhi review.
Penulis kod juga berperanan. Terangkan tujuan PR, langkah menguji dan bahagian yang anda sendiri kurang pasti. PR kecil lebih mudah diberi perhatian. Jika perbualan bertulis menjadi panjang atau nada mula kabur, panggilan singkat mungkin lebih cepat; ringkaskan keputusan semula pada PR selepas itu.
Cuba bezakan komentar wajib dan cadangan ringan dengan perkataan yang jelas. “Perlu dibaiki kerana boleh menyimpan data dua kali” berbeza daripada “Cadangan: nama ini mungkin lebih mudah dibaca.” Penulis PR boleh menyusun respons berdasarkan risiko, dan reviewer tidak perlu mengulang penjelasan dalam mesyuarat lain.
Review bukan peperiksaan untuk mencari siapa lebih pandai. Ia peluang berkongsi konteks yang mungkin tidak diketahui seorang pembangun. Apabila cadangan ditolak dengan alasan baik, kedua-dua pihak belajar tentang sistem. Kod akhir lebih kuat kerana keputusan dibuat secara terbuka.