Code Review

Pull request menyediakan panggungnya — diff, komentar, tombol keputusan — tetapi mutu keputusan akhirnya bergantung pada isi kepalanya: siapa yang membaca, dan bagaimana ia membaca. Code review yang dijalankan dengan benar adalah dua investasi sekaligus: bug ketemu sebelum sampai produksi, dan pemahaman tentang codebase menyebar ke seluruh tim alih-alih mengendap di satu orang. Chapter ini membedah prosesnya dari kursi reviewer — membaca kandidat dari terminal, menulis komentar yang membangun, lalu menanggapi ulasan dari kursi kontributor.

Alur Kerja Reviewer #

Review yang terburu-buru biasanya melompat ke diff dan mengomentari baris pertama yang terlihat. Alur yang sehat membaca empat lapis berurutan:

1. Deskripsi PR dulu — apa yang dijanjikan. Tanpa kontrak ini, reviewer tidak tahu kode mana yang menyimpang dan mana yang memang disengaja.
2. Daftar commit — kerangka pengerjaan; satu commit satu langkah yang semestinya bercerita.
3. Diff keseluruhan dari base ke compare — potret akhir yang akan hidup di main.
4. Baris-baris kritis dengan kecepatan setengahnya: validasi input, penanganan galat, batas loop, perubahan schema.

Keputusan reviewer di platform berbentuk dua tombol: approve (perubahan boleh digabungkan) atau request changes (ada hal yang harus dibereskan dulu). Komentar bisa juga dikirim netral — sekadar bertanya — tanpa memblokir.

Membaca Kandidat dari Terminal #

Seluruh bahan telaah bisa ditarik ke terminal — pola yang dikenal dari chapter Pull Request , kini dengan dua putaran: review pertama, umpan balik, lalu review kedua. Skenarionya: Budi pemilik toko-review.git, Siti mengusulkan branch fitur/harga. Budi menyiapkan repository dan mendorong kerangkanya:

mkdir budi && cd budi
git init -b main
git config user.name "Budi Santoso"
git config user.email "[email protected]"
printf 'beranda\n' > situs.md
git add situs.md
git commit -m "Buat kerangka toko"
git init --bare ../toko-review.git
git remote add origin ../toko-review.git
git push -u origin main

Siti menyalin, membuat branch, lalu mengirim versi pertama:

cd ..
git clone toko-review.git siti
cd siti
git switch -c fitur/harga
printf 'kopi 2000\ngula 7000\n' > harga.md
git add harga.md
git commit -m "Tambah halaman harga"
git push -u origin fitur/harga

Output yang Dihasilkan (dua perintah terakhir):

[fitur/harga be37672] Tambah halaman harga
 1 file changed, 2 insertions(+)
 create mode 100644 harga.md

To ../toko-review.git
 * [new branch]      fitur/harga -> fitur/harga
branch 'fitur/harga' set up to track 'origin/fitur/harga'.

Di meja Budi, review dibuka dengan menarik branch kandidat:

cd ../budi
git fetch origin

Output yang Dihasilkan:

From ../toko-review
 * [new branch]      fitur/harga -> origin/fitur/harga

git log --oneline main..origin/fitur/harga

Output yang Dihasilkan:

be37672 Tambah halaman harga

git diff main...origin/fitur/harga

Output yang Dihasilkan:

diff --git a/harga.md b/harga.md
new file mode 100644
index 0000000..df90e8b
--- /dev/null
+++ b/harga.md
@@ -0,0 +1,2 @@
+kopi 2000
+gula 7000

Satu commit, satu berkas — PR yang sehat. Tetapi baca pelan baris kritisnya: kopi 2000. Daftar harga di seluruh materi toko ini memakai kopi 20000; satu nol hilang. Di platform, Budi menempelkan komentar pada baris itu — bagaimana menulisnya kita bahas setelah ini — dan menekan request changes.

Siti menanggapi bukan dengan menyunting commit lama, melainkan dengan commit perbaikan di atasnya — riwayat diskusi ikut tercatat:

cd ../siti
printf 'kopi 20000\ngula 7000\n' > harga.md
git add harga.md
git commit -m "Perbaiki harga kopi"
git push origin fitur/harga

Output yang Dihasilkan (perintah terakhir):

[fitur/harga 8acebd8] Perbaiki harga kopi
 1 file changed, 1 insertion(+), 1 deletion(-)

To ../toko-review.git
   be37672..8acebd8  fitur/harga -> fitur/harga

Budi menarik putaran kedua dan membaca ulang — daftar commit dulu, lalu potret akhir, lalu commit perbaikannya sendiri:

cd ../budi
git fetch origin

Output yang Dihasilkan:

From ../toko-review
   be37672..8acebd8  fitur/harga -> origin/fitur/harga

git log --oneline main..origin/fitur/harga

Output yang Dihasilkan:

8acebd8 Perbaiki harga kopi
be37672 Tambah halaman harga

git diff main...origin/fitur/harga

Output yang Dihasilkan:

diff --git a/harga.md b/harga.md
new file mode 100644
index 0000000..7b88b4a
--- /dev/null
+++ b/harga.md
@@ -0,0 +1,2 @@
+kopi 20000
+gula 7000

git show origin/fitur/harga

Output yang Dihasilkan:

commit 8acebd834e86a42ad153fbd431d0fd64f6d2dafa
Author: Siti Rahma <[email protected]>
Date:   Thu Oct 29 09:40:00 2026 +0700

    Perbaiki harga kopi

diff --git a/harga.md b/harga.md
index df90e8b..7b88b4a 100644
--- a/harga.md
+++ b/harga.md
@@ -1,2 +1,2 @@
-kopi 2000
+kopi 20000
 gula 7000

Tiga keluaran, tiga pertanyaan terjawab: daftar commit membuktikan perbaikan datang sebagai commit baru (8acebd8 di atas be37672); diff akhir menunjukkan harga kembali benar; git show membuka isi commit perbaikan persis — hanya baris kopi yang tersentuh, penulis dan tanggalnya tercatat. Hash di mesin pembaca berbeda; pola bacaannya tidak. Budi menandai komentar lama “selesai” dengan balasan singkat di platform, lalu menekan approve. Riwayat yang perlu dibaca bisa digali lebih dalam lagi dengan opsi-opsi dari Git Log dan Opsi dan git blame .

Fokus Telaah: Lima Pertanyaan #

Diff yang sama dibaca lima cara — dan kelima pertanyaan ini bekerja untuk review kode apa pun, bukan hanya Markdown toko:

Pertanyaan “benar?” menelan porsi terbesar dan paling lambat — di sanalah review menghasilkan uangnya. “Konsisten?” tampak paling kecil tetapi sering paling mengundang komentar; pertimbangan sosialnya: keputusan gaya sebaiknya dirujuk ke konvensi tim atau linter, bukan selera pribadi reviewer.

Komentar yang Membangun #

Komentar review adalah pesan yang akan dibaca manusia sedang mempertahankan harga dirinya di depan pekerjaannya. Frasa menentukan apakah ia membaca saran atau serangan:

Empat pasang frasa di atas memegang empat prinsip yang sama. Kritik menyasar kode, bukan orang — “fungsi ini panjang” aman; menyebut penulisnya ceroboh tidak. Bertanya sebelum menghakimi — banyak “kesalahan” ternyata keputusan yang konteksnya belum sampai ke reviewer. Menawarkan solusi, bukan hanya diagnosis — komentar berpasangan usulan perbaikan bergerak dua kali lebih cepat. Menyertakan bukti — baris, kasus uji, atau tautan membuat saran bisa diverifikasi, bukan sekadar dipercaya.

Menanggapi Ulasan #

Dari kursi kontributor, tiga kebiasaan menutup lingkaran dengan sehat. Pertama, balas setiap komentar — “selesai di commit 8acebd8” atau “saya tidak setuju, alasannya begini” — keduanya sah; yang tidak sah adalah diam. Kedua, kirim perbaikan sebagai commit baru seperti Siti barusan, bukan amend yang menimpa commit lama: jejak diskusi di halaman PR tetap terbaca dan rekan tidak perlu me-review ulang dari nol. Ketiga, jangan rebase branch yang sedang dalam review aktif — penulisan-ulang riwayat mengganti hash dan memaksa force push; batas amannya sudah dipetakan di Aturan Aman Mengubah Riwayat , dan merapikan commit paling tepat dilakukan sebelum PR dibuka atau setelah review selesai.

Budaya review lintas peran — bagaimana maintainer besar menerima kontribusi ratusan orang asing dengan cara serupa — dirangkum panjang lebar di Pro Git: Contributing to a Project .

Checklist Sebelum Menekan Approve #

• Deskripsi PR sudah dibaca, janji dan hasil disandingkan.
• Branch di-build dan tes dijalankan lokal, bukan hanya diff dibaca.
• Diff dibaca dua putaran: sekali cepat untuk bentuk umum, sekali pelan untuk baris kritis.
• Semua komentar tertempel pada baris yang dimaksud, bukan umum di halaman.
• Keputusan akhir ditulis jelas — approve atau request changes, tanpa setengah-setengah.

Satu bangunan belum berdiri: semua latihan sejauh ini masih menggabungkan branch secara manual. Workflow berikutnya merangkai seluruh siklus — branch, review, merge, hapus, tarik — menjadi tarian lengkap antara dua meja, dibuktikan dari nol di sandbox.