Bagian 3: Melakukan Code Review

Kursi berpindah ke Budi, dan cara membacanya ikut berpindah. Chapter Code Review menetapkan alurnya empat lapis berurutan: deskripsi PR dulu — apa yang dijanjikan — lalu daftar commit sebagai kerangka pengerjaan, lalu diff keseluruhan dari base ke compare, dan terakhir baris-baris kritis dibaca dengan kecepatan setengahnya. Bagian ini menjalankan keempat lapis itu sungguhan di clone budi, memakai checklist yang pemilik proyek tetapkan sejak rintisan, lalu menutupnya dengan keputusan yang berbentuk tertulis. Hasilnya: satu temuan nyata, satu komentar bergaya platform, dan satu putaran feedback yang menunggu Siti.

Membaca Daftar Commit #

Budi masih di clone budi dengan branch kandidat sudah ter-fetch. Lapis kedua alur review — kerangka pengerjaan:

git log --oneline main..fork/review/pencarian

Output yang Dihasilkan:

c17159e feat: terapkan fungsi pencarian
84f5f89 feat: tulis kerangka fitur pencarian

Rentang main..fork/review/pencarian menghitung commit yang dimiliki kandidat dan belum dimiliki main — persis isi pull request. Dua commit, dua langkah bernama: riwayat yang sudah dirapikan Siti terbaca sebagai cerita, bukan derau. Lapis ketiga: potret akhir yang akan hidup di main bila PR diterima.

Membaca Diff Keseluruhan #

git diff main..fork/review/pencarian

Output yang Dihasilkan:

diff --git a/src/feature.txt b/src/feature.txt
index 2586bd3..3c16aef 100644
--- a/src/feature.txt
+++ b/src/feature.txt
@@ -6,3 +6,13 @@ Fitur Pencarian Catatan
 - catatan 1: belajar Git setiap pagi
 - catatan 2: resep rendang keluarga
 - catatan 3: daftar belanja mingguan
+
+## Fungsi Pencarian
+
+cari(kata_kunci):
+    cocok = catatan yang memuat "belanja"
+    kembalikan cocok
+
+## Hasil Uji
+
+cari("belanja") → catatan 3: daftar belanja mingguan

Hunk tunggal @@ -6,3 +6,13 @@ memuat seluruh usulan: tiga baris catatan sebagai konteks, sepuluh baris baru di bawahnya. Dua seksi ditambahkan — fungsi dan hasil uji — dan tidak satu baris lama dihapus. Sekali lirik, PR ini sehat. Baris-baris kritisnya kemudian dibaca pelan, dan di sanalah deskripsi PR mulai bekerja: Siti berjanji fungsi cari(kata_kunci) mencari kata kunci apa pun. Sekarang bandingkan dua baris ini dari diff di atas:

cari(kata_kunci):
    cocok = catatan yang memuat "belanja"

Tanda tangan fungsi menerima kata_kunci, tetapi baris badannya tidak pernah membacanya — kata yang dicari selalu "belanja", huruf demi huruf. Parameter dijanjikan, lalu diabaikan. Seksi hasil uji pun kini terbaca berbeda: satu-satunya kata kunci yang diuji adalah belanja — kebetulan persis kata yang di-hardcode, sehingga uji itu lulus bukan karena fungsi benar, melainkan karena cocok secara kebetulan.

Checklist Milik Proyek #

Lapis keempat alur review adalah menimbang temuan terhadap kriteria — dan proyek catatan menetapkannya tertulis. Checklist hidup di repository sejak rintisan Bagian 1; Budi membacanya dari clone:

cat docs/review-checklist.md

Output yang Dihasilkan:

# Checklist Review

Lima pertanyaan yang diperiksa reviewer pada setiap pull request
proyek ini. Tandai jawaban tiap baris dan catat buktinya pada
komentar review.

| Aspek   | Pertanyaan kunci                          | Bukti yang dicari                       |
|---------|-------------------------------------------|-----------------------------------------|
| Benar    | Apakah hasil sesuai janji deskripsi PR?    | logika, kasus kosong, batas             |
| Terbaca  | Apakah niat tiap bagian langsung terbaca?  | penamaan, struktur seksi                |
| Aman     | Apakah ada input atau data yang rawan?     | input tidak tepercaya, data pribadi     |
| Teruji   | Apakah perilaku baru terbukti dijalankan?  | hasil uji untuk kata kunci berbeda      |
| Konsisten| Apakah pola berkas sekitarnya diikuti?     | konvensi nama dan format                |

Cara pakai: baca deskripsi PR, baca diff dari base ke compare,
lalu jawab kelima baris di atas sebelum menulis keputusan review.

Lima aspeknya adalah lima pertanyaan telaah dari chapter Code Review : benar, terbaca, aman, teruji, konsisten. Checklist menjalankannya per pull request, supaya review tidak bergantung pada suasana hati reviewer.

Menjalankan Checklist pada Kandidat #

Budi menimbang diff di atas baris per baris:

Dua baris gagal dan akarnya sama: parameter yang diabaikan. Perbaikannya satu kalimat teknis — jadikan kata kunci itu benar-benar dipakai — ditambah bukti bahwa kata kunci lain juga berhasil.

Menulis Temuan sebagai Komentar PR #

Review yang baik menyerahkan temuan dalam bentuk yang bisa ditindaklanjuti. Di platform, komentar review menempel pada baris diff tertentu — pengulas mengklik barisnya, menulis komentarnya, dan platform mencatat lokasinya sebagai berkas:baris. Budi menulis temuan untuk baris badan fungsi:

src/feature.txt:13

Fungsi cari menerima kata_kunci, tetapi baris badannya selalu
mencari "belanja" — parameter yang diterima tidak pernah dipakai.
Bisakah badan fungsi membaca kata_kunci, dan seksi Hasil Uji
ditambah kata kunci lain (mis. "rendang") supaya perilakunya
terbukti?

Baris pertama adalah lokasi menempelnya komentar; sisanya isinya. Isi komentar itu memegang empat prinsip dari chapter Code Review : kritik menyasar kode bukan orang, pertanyaan dibuat mengundang jawaban, solusi ditawarkan bersama diagnosis, dan bukti — nama parameter plus contoh kata kunci — disertakan supaya saran bisa diverifikasi. Perilaku komentar review di GitHub terdokumentasi di panduan review pull request .

Keputusan: Request Changes #

Platform menyediakan dua tombol keputusan. Approve menyatakan perubahan boleh digabungkan; request changes menyatakan ada yang harus dibereskan dulu. Karena dua baris checklist gagal dan perbaikannya jelas, Budi menekan request changes — pull request #8 kembali ke meja Siti dengan status yang terbaca jelas, temuan tertulis menunggu jawaban. Perintah Git Budi sepanjang bagian ini hanya dua: git log dan git diff. Seluruh keputusannya lahir dari membaca, bukan dari menunggu galat.

Kini kursi kembali ke Siti dengan satu komentar bergantung di baris 13: Bagian 4: Menindaklanjuti Feedback .