Buat ulasan singkat.
Sulit untuk tetap terkonsentrasi, terutama selama tinjauan kode, untuk waktu yang lama. Selain itu, tinjauan kode panjang dapat mengindikasikan bahwa ada terlalu banyak hal untuk dikatakan pada kode (lihat dua poin berikutnya) atau bahwa tinjauan menjadi diskusi tentang masalah yang lebih besar, seperti arsitektur.
Juga, ulasan harus tetap review, bukan diskusi. Itu tidak berarti bahwa pembuat kode tidak dapat membalas, tetapi seharusnya tidak berubah menjadi pertukaran pendapat yang panjang.
Hindari meninjau kode yang terlalu buruk.
Meninjau kode berkualitas rendah menyedihkan bagi peninjau dan penulis kode. Jika sepotong kode mengerikan, tinjauan kode tidak berguna. Sebagai gantinya, penulis harus diminta untuk menulis ulang kode dengan benar.
Gunakan checker otomatis sebelum ulasan.
Checker otomatis menghindari pemborosan waktu menunjuk kesalahan yang dapat ditemukan secara otomatis. Misalnya, untuk kode C #, menjalankan StyleCop, metrik Kode dan terutama analisis Kode adalah kesempatan yang baik untuk menemukan beberapa kesalahan sebelum ditinjau. Kemudian, review kode dapat dihabiskan untuk poin yang sangat sulit dilakukan untuk mesin.
Pilih dengan cermat orang-orang yang melakukan tinjauan.
Dua orang yang tidak tahan satu sama lain tidak akan melakukan review yang baik terhadap kode yang lain. Masalah yang sama muncul ketika satu orang tidak menghormati yang lain (tidak peduli apakah itu resensi atau penulis, omong-omong).
Selain itu, beberapa orang tidak dapat melihat kode mereka ditinjau, sehingga mereka memerlukan pelatihan dan persiapan khusus untuk memahami bahwa mereka tidak dikritik dan mereka seharusnya tidak melihatnya sebagai sesuatu yang negatif. Melakukan tinjauan, tidak siap, tidak akan membantu, karena mereka akan selalu bersikap defensif dan tidak akan mendengarkan kritik terhadap kode mereka (menganggap setiap saran sebagai kritik).
Lakukan tinjauan formal dan informal.
Memiliki daftar periksa membantu dalam berkonsentrasi pada satu set kelemahan yang tepat, menghindari beralih ke pengambilan nit. Daftar periksa ini dapat berisi poin-poin seperti:
- Injeksi SQL,
- Asumsi yang salah tentang bahasa yang dapat menyebabkan kesalahan,
- Situasi khusus yang dapat menyebabkan kesalahan, seperti prioritas operator. Misalnya, dalam C #,
var a = b ?? 0 + c ?? 0;mungkin terlihat bagus untuk seseorang yang ingin menambahkan dua angka yang dapat dibatalkan dengan menyatu di nol, tetapi ternyata tidak.
- Deallokasi memori,
- Pemuatan malas (dengan dua risiko: memuat hal yang sama lebih dari satu kali, dan tidak memuatnya sama sekali),
- Meluap,
- Struktur data (dengan kesalahan seperti daftar sederhana alih-alih kumpulan hash, misalnya),
- Input validasi dan pemrograman defensif secara umum,
- Keamanan benang,
- dll.
Saya menghentikan daftar di sini, tetapi ada ratusan poin yang dapat muncul dalam daftar periksa, tergantung pada titik lemah dari penulis yang tepat.
Sesuaikan daftar periksa secara progresif.
Agar tetap konstruktif dan berguna dari waktu ke waktu, daftar periksa yang digunakan dalam tinjauan formal harus disesuaikan dari waktu ke waktu tergantung pada kesalahan yang ditemukan. Sebagai contoh, tinjauan informal pertama dapat mengungkapkan sejumlah risiko SQL Injection. Pemeriksaan SQL Injection akan dimasukkan dalam daftar periksa. Ketika, beberapa bulan kemudian, tampak bahwa penulis sekarang sangat berhati-hati tentang permintaan dinamis vs parametrized, SQL Injection dapat dihapus dari daftar periksa.