Review PR: Diskusi & Approve Kode

Review bukan cari kesalahan, tapi jaga kualitas

Luruskan dulu mindset-nya. Tujuan review: kode benar, mudah dibaca, konsisten dengan codebase. Bukan ajang pamer siapa paling pintar. Tim yang review-nya sehat justru ngoding lebih cepat, karena bug ketangkap sebelum masuk main.

Cepat atau lambat kamu akan ada di dua sisi: diminta me-review PR teman, dan PR-mu di-review orang. Dua-duanya butuh etika yang sama.

Komentar yang baik menjelaskan kenapa, bukan cuma apa:

• Kurang baik: "ganti ini"
• Baik: "Fungsi ini dipanggil di loop 10 ribu kali, bisa kita cache hasilnya? Lihat pola yang dipakai di utils/cache.ts."

Yang pertama bikin bingung dan tersinggung; yang kedua memberi alasan plus solusi.

Contoh 1: menarik PR teman ke laptopmu

Review paling teliti menjalankan kodenya, bukan cuma baca diff di browser. Dengan GitHub CLI:

gh pr checkout 17

Sekarang branch PR-nya ada di laptopmu. Jalankan aplikasinya, coba fiturnya, jalankan test-nya:

npm test

Kamu me-review berdasarkan bukti (kode jalan beneran), bukan tebakan.

Contoh 2: memberi keputusan review dari terminal

Setelah memeriksa, sampaikan keputusanmu. Tiga jenis review di GitHub:

1. Comment: sekadar diskusi, tanpa keputusan.
2. Approve: "kode ini oke, silakan merge".
3. Request changes: "ada yang harus diperbaiki dulu, jangan merge".

gh pr review 17 --approve -b "Sudah dicoba lokal, test hijau semua. LGTM!"

Atau kalau ada yang harus diperbaiki:

gh pr review 17 --request-changes -b "Ada edge case kosong yang belum ditangani di baris 42, lihat komentarku di Files changed."

Di tab Files changed, kamu bisa komentar inline: arahkan ke baris kode, klik ikon + biru. Tombol suggestion (ikon +-) mengusulkan kode pengganti yang bisa di-apply penulis dengan satu klik. Efisien untuk typo atau perbaikan kecil.

Checklist profesional

• Apakah kode ini benar-benar melakukan yang dideskripsikan PR?
• Apakah ada test? Apakah test-nya bermakna atau cuma formalitas?
• Apakah penamaannya jelas tanpa menebak-nebak?
• Apakah ada edge case terlewat (null, kosong, error)?
• Apakah ada duplikasi yang bisa disederhanakan?

Sesuaikan dengan ukuran perubahan; PR satu baris tidak butuh checklist lima poin.

Etika review dua arah

Sebagai reviewer: kritik kodenya, bukan orangnya. Bedakan "harus diubah" vs "preferensi pribadi". Jangan menahan PR berhari-hari demi hal sepele.

Sebagai penulis: jangan defensif. Setiap komentar adalah data: kalau reviewer bingung membaca kodemu, calon pembaca berikutnya juga akan bingung. Jawab tiap thread dan resolve agar tidak menggantung.

Catatan teknis: GitHub bisa mewajibkan minimal 1 approve sebelum merge lewat branch protection rules (Settings > Branches). Banyak tim juga mewajibkan "conversation resolved" dan CI hijau. Aturan ini mencegah merge terburu-buru di repo penting.

Kapan review?

Setiap PR yang meminta review darimu, idealnya dalam 1x24 jam. PR yang menganggur jadi basi: branch ketinggalan main, konflik menumpuk. Review cepat = tim cepat.

Kesalahan umum pemula

SALAH: approve tanpa benar-benar memeriksa ("LGTM" buta).

gh pr review 17 --approve -b "LGTM"

Approve adalah tanda tangan: kamu ikut bertanggung jawab atas kode itu. Kalau ternyata bug, namamu tercatat sebagai approver.

BENAR: periksa dulu (baca diff, jalankan test), baru beri keputusan jujur.

Tidak harus sempurna, tapi harus usaha. Kalau tidak sempat review serius, lebih baik bilang "belum sempat, tolong minta ke orang lain" daripada approve asal-asalan.

Kesalahan kedua: komentar yang menyerang orang, bukan kode. "Kok bisa sih nulis kode sebodoh ini" tidak pernah membantu siapa pun. Tulis ulang jadi: "Bagian ini berpotensi bug saat input kosong, bagaimana kalau kita tambah pengecekan?" Kritik yang sama, tanpa racun.