Checklist Code Review

Code review adalah pertahanan kualitas termurah: bug yang tertangkap di meja review berbiaya menit, bug yang lolos ke production berbiaya insiden. Tantangannya, review yang baik butuh fokus — dan fokus paling mudah dijaga lewat daftar periksa agar tidak ada kategori yang terlewat. Chapter ini menyusun sekitar tiga puluh butir pemeriksaan dalam enam kategori, lalu menutup dengan tata cara memberi komentar review yang membangun.

Peta Enam Kategori #

Kebenaran #

Butir pemeriksaan yang memastikan logika berjalan sesuai maksud:

• Semua nilai balik error ditangani, atau diabaikan secara eksplisit dengan alasan di komentar.
• Error yang tidak ditindaklanjuti tetap dicatat ke log, bukan ditelan diam-diam.
• Edge case input diuji: slice kosong, nol, nil, string kosong, dan nilai batas.
• Indeks dan batasan perulangan dicek ulang — waspadai off-by-one dan mutasi slice saat diiterasi.
• Urutan defer dan interaksinya dengan panic/recover sesuai desain.
• Setiap perbaikan bug disertai test yang sebelumnya gagal (test regresi).

Keamanan #

• Query SQL memakai parameter binding, bukan penggabungan string dengan fmt.Sprintf.
• Input pengguna divalidasi (panjang, format, rentang) sebelum dipakai lebih jauh.
• Secret tidak di-hardcode — baca dari environment variable atau secret manager.
• Data sensitif (password, token) tidak pernah masuk ke log.
• Pesan error ke pengguna tidak membocorkan detail internal seperti path server atau stack trace.

Concurrency #

• go test -race lulus untuk seluruh test suite.
• Akses data bersama dilindungi mutex, channel, atau sync/atomic.
• Goroutine dijamin berakhir saat pemanggil membatalkan lewat context — tidak ada goroutine leak.
• Setiap channel penerima memiliki pengirim di semua jalur, termasuk jalur error.
• Sinkronisasi memakai sync.WaitGroup atau context, bukan time.Sleep.

Kinerja #

• Query database tidak berada di dalam perulangan (pola N+1).
• Alokasi di loop panjang diperiksa: append pra-alokasi atau reuse buffer.
• Klaim “lebih cepat” didukung benchmark testing.B sebelum dan sesudah perubahan.
• Operasi yang berpotensi lama (jaringan, disk) memiliki timeout eksplisit.

Kualitas #

• gofmt bersih dan go vet lulus tanpa keluhan.
• Nama mengikuti konvensi Go: MixedCaps, getter tanpa awalan Get, sentinel error ErrXxx.
• Komentar dokumentasi diawali nama identifier dan berupa kalimat lengkap.
• Fungsi baru punya test; kombinasi banyak input memakai pola table-driven.
• Kode duplikat diangkat ke helper, bukan salin-tempel dengan satu huruf beda.
• Package baru benar-benar memberi nilai — bukan lapisan tipis tanpa isi.

API dan Kontrak #

• Perubahan signature tidak memecahkan pemanggil existing, atau dicatat sebagai breaking change.
• Field struct baru tidak mengubah makna zero value yang sudah dipakai pemanggil.
• Error baru dikenali lewat errors.Is/errors.As — sentinel atau tipe kustom.
• Interface didefinisikan di sisi pemakai dan tetap kecil (satu-dua method).

Memberi Komentar Review yang Membangun #

Isi daftar periksa hanya separuh pekerjaan; cara menyampaikannya menentukan apakah review disambut atau dihindari. Empat kebiasaan berikut menjadi patokan:

Contoh komentar konkret di dalam kode — perhatikan label prioritas di awal dan usulan perbaikan di akhir:

// REVIEW (blocking): fmt.Sprintf menyisipkan input mentah ke query,
// berisiko SQL injection. Gunakan parameter binding:
rows, err := db.Query("SELECT id, nama FROM users WHERE email = ?", email)

Review menjaga kode sebelum rilis; pemeriksaan terakhir menjaga aplikasi saat menyentuh production. Daftar periksa untuk momen itu jauh lebih panjang dan teknis — lanjut ke chapter Checklist Production .

Referensi #

• CodeReviewComments — daftar resmi komentar code review komunitas Go.
• Effective Go — patokan idiom yang jadi acuan mayoritas komentar review.
• Package testing — fondasi test regresi, table-driven, dan benchmark yang diminta daftar ini.