KAL
Menu

Praktik code review

Apa yang dicari dalam code review dan mengapa PR kecil lebih mudah ditinjau.

Daftar isi

Code review adalah pembacaan yang disengaja atas perubahan seseorang sebelum perubahan itu masuk branch utama, dan kualitasnya ditentukan oleh dua sisi sekaligus, yaitu apa yang dicari pemeriksa dan bagaimana hasil pencarian itu disampaikan. Topik ini membahas daftar pemeriksaan yang lazim, alasan PR kecil lebih mudah ditinjau, dan alat Git yang dipakai pemeriksa untuk melihat perubahan dari sudut pandangnya sendiri.

Apa yang dicari pemeriksa#

Daftar pemeriksaan yang sehat bergerak dari yang paling mahal kesalahannya ke yang paling ringan. Yang pertama adalah kebenaran, yaitu apakah perubahan benar-benar menyelesaikan apa yang diklaimnya dan tidak merusak yang lain. Yang kedua adalah pengujian, yaitu apakah perilaku baru dilindungi kasus uji dan apakah kasus gagal yang relevan ditambahkan. Yang ketiga adalah keterbacaan, yaitu penamaan, struktur, dan keterangan yang membuat pembaca berikutnya tidak perlu menebak.

Daftar yang tersisa lebih ringan namun tetap berdampak. Cakupan perubahan diperiksa agar tidak ada pekerjaan lain yang terselip tanpa sengaja, keamanan diperiksa pada titik-titik yang menyentuh masukan dan kredensial, dan konsistensi dengan pola proyek diperiksa agar kode baru tidak menambah gaya yang kedua. Pemeriksa yang membedakan mana yang menghalangi penggabungan dan mana yang sekadar selera menjaga diskusi tetap sehat, dan topik pull request menempatkan perbedaan itu pada etika review-nya.

Alasan PR kecil#

Ukuran permintaan menentukan kualitas tinjauannya secara langsung. Permintaan yang berisi ratusan baris dapat ditinjau dengan saksama dalam satu sesi, sedangkan permintaan ribuan baris cenderung diperiksa sepintas, karena perhatian pemeriksa habis sebelum akhir diff tercapai. Konsekuensinya tidak terasa pada hari itu, tetapi kesalahan yang lolos dari tinjauan sepintas justru paling mahal, karena ditandai sebagai sudah diperiksa.

Permintaan kecil juga menyeimbangkan biaya lainnya. Konflik dengan pekerjaan lain lebih kecil, pengujian otomatis berjalan lebih cepat, dan pembatalan bila ternyata keliru lebih murah. Trik praktis untuk mencapainya adalah memecah pekerjaan secara vertikal, yaitu berdasarkan lapisan yang berurutan, alih-alih memecah berkas secara acak, sehingga setiap permintaan tetap masuk akal sebagai satu unit yang dapat dibangun dan diuji sendiri.

Melihat perubahan dari sudut pemeriksa#

Pemeriksa tidak pernah membaca seluruh proyek, melainkan selisih dua titik, dan Git menyediakan bentuk perbandingannya secara langsung. Siapkan branch dengan dua commit di atas main, lalu lihat apa yang dilihat pemeriksa.

bash 
# tanggal commit ditetapkan agar keluaran contoh dapat direproduksi secara persis
export GIT_AUTHOR_DATE="2026-11-01T09:00:00+07:00"
export GIT_COMMITTER_DATE="2026-11-01T09:00:00+07:00"
bash 
rm -rf /tmp/lab-review
mkdir /tmp/lab-review
cd /tmp/lab-review
git init -b main
git config user.name "Budi"
git config user.email "[email protected]"
printf "Panduan proyek.\n" > panduan.md
git add panduan.md
git commit -m "Panduan proyek"
git switch -c feature/ringkasan
printf "Panduan proyek.\nRingkasan proyek.\n" > panduan.md
git commit -am "Tambah ringkasan proyek"
printf "Panduan proyek.\nRingkasan proyek.\nRingkasan tim.\n" > panduan.md
git commit -am "Ringkas tujuan tim"
git merge-base main feature/ringkasan
git log --oneline main..feature/ringkasan
text Keluaran 
Initialized empty Git repository in /tmp/lab-review/.git/
[main (root-commit) f4ac75f] Panduan proyek
 1 file changed, 1 insertion(+)
 create mode 100644 panduan.md
Switched to a new branch 'feature/ringkasan'
[feature/ringkasan 0f1527c] Tambah ringkasan proyek
 1 file changed, 1 insertion(+)
[feature/ringkasan a7c5e1d] Ringkas tujuan tim
 1 file changed, 1 insertion(+)
f4ac75fd34ad41ecf8c2f9baac310487fec36730
a7c5e1d Ringkas tujuan tim
0f1527c Tambah ringkasan proyek

Perintah git merge-base menemukan titik terakhir tempat kedua branch identik, yaitu commit dasar tinjauan, dan log dengan notasi dua titik menampilkan commit yang akan ditinjau. Keduanya menjawab pertanyaan batas: di mana pekerjaan dimulai, dan apa saja yang dibawanya.

bash 
git diff main...feature/ringkasan --stat
text Keluaran 
 panduan.md | 2 ++
 1 file changed, 2 insertions(+)

Notasi tiga titik pada git diff membandingkan branch pekerjaan terhadap titik dasarnya, bukan terhadap ujung main saat ini, sehingga hasilnya tidak terganggu oleh perubahan lain yang masuk ke main di tengah tinjauan. Bentuk inilah yang ditampilkan platform pada halaman pull request, dan --stat memberi ringkasan besar perubahan sebelum diff penuh dibaca.

Menindaklanjuti hasil review#

Tinjauan yang menghasilkan catatan ditindaklanjuti dengan commit baru pada branch yang sama, sehingga pemeriksa dapat melihat perbedaan sejak tinjauan sebelumnya tanpa membaca ulang semuanya. Catatan yang diterima diselesaikan, catatan yang ditolak dijawab dengan alasannya, dan pengiriman ulang memicu pengujian berjalan lagi.

Dua kebiasaan menjaga tahap ini tetap efisien. Yang pertama adalah menunggu seluruh catatan terkumpul sebelum mulai menyunting, karena memperbaiki sambil menunggu membuat percakapan menjadi sulit diikuti. Yang kedua adalah menahan force-push pada branch yang sedang ditinjau, karena pembacaan ulang seluruh diff memaksa pemeriksa mengulang pekerjaannya, dan catatan yang sudah dijawab kehilangan titik jangkarnya.

Ringkasan#

  • Pemeriksaan bergerak dari kebenaran, pengujian, dan keterbacaan menuju cakupan, keamanan, dan konsistensi.
  • Permintaan kecil diperiksa lebih saksama dan memperkecil konflik, biaya pengujian, serta risiko pembatalan.
  • git merge-base, log dua titik, dan git diff main...branch memberi pemeriksa batas dan isi perubahan secara tepat.
  • Tindak lanjut dilakukan dengan commit baru pada branch yang sama, dan force-push ditahan selama tinjauan berlangsung.

Referensi#