Me-review — apa itu, bagaimana cara kerja code review dan pemeriksaan PR

Apa itu code review

Code review — adalah pemeriksaan sistematis kode oleh rekan kerja sebelum diintegrasikan. Dalam konteks Git, ini berarti: pengembang membuat pull request dengan perubahan, menunjuk reviewer, dan mereka mempelajari diff, meninggalkan komentar dan memberikan keputusan. Reviewer dapat meminta perubahan (Request Changes), menyetujui PR (Approve) atau meninggalkan komentar umum.

Code review memiliki lima tujuan: meningkatkan kualitas kode (mendeteksi cacat sebelum masuk ke production), menyebarkan pengetahuan (reviewer belajar tentang pendekatan baru, penulis menerima umpan balik), mematuhi standar (memeriksa kesesuaian dengan code style dan keputusan arsitektur), mengurangi bus factor (kode tidak hanya diketahui oleh satu pengembang) dan membangun budaya tanggung jawab (penulis menulis lebih teliti, mengetahui bahwa kode akan diperiksa).

Kebalikan dari code review adalah blind commit: pengembang mendorong perubahan ke cabang bersama tanpa review. Pendekatan ini hanya diizinkan dalam proyek satu pengguna atau untuk hotfix mendesak dengan review setelahnya. Dalam pengembangan tim profesional, code review adalah tahap wajib untuk setiap perubahan, termasuk perbaikan dokumentasi dan konfigurasi.

Apa yang diperiksa dalam code review

Code review harus sistematis, tidak kacau. Reviewer berpengalaman memeriksa kode dalam urutan tertentu: pertama arsitektur dan logika, kemudian tes, lalu keamanan dan kinerja, dan terakhir — gaya dan penamaan. Urutan ini memastikan bahwa masalah kritis terlihat sebelum reviewer lelah.

Arsitektur dan logika: apakah kode menyelesaikan masalah, apakah ada abstraksi yang tidak perlu, apakah prinsip SOLID dan DRY dipatuhi. Kode kompleks yang sulit dipahami saat pertama dibaca — sinyal bahwa perlu refactoring. Reviewer harus memastikan bahwa kode melakukan persis apa yang ditentukan dalam tugas dan tidak memiliki efek samping di luar tanggung jawabnya.

Tes: apakah tes baru mencakup semua skenario — positif, negatif, kasus batas. Apakah tes yang ada lulus setelah perubahan. Apakah ada tes flaky yang gagal tidak stabil. Keamanan: tidak adanya SQL injection, XSS, kebocoran data sensitif melalui log atau respons API. Kinerja: efisiensi algoritma, kueri database yang berlebihan, kebocoran sumber daya.

• Arsitektur — kebenaran solusi, kepatuhan terhadap SOLID, tidak ada over-engineering.
• Logika — penanganan semua skenario, termasuk kesalahan dan kasus batas.
• Tes — cakupan perubahan baru, tidak ada tes lama yang rusak.
• Keamanan — injeksi, XSS, CSRF, kebocoran data melalui log.
• Kinerja — kompleksitas algoritma, kueri N+1, kebocoran memori.

Ukuran review: mengapa 400 baris adalah maksimum

Pembatasan ukuran PR — metrik paling penting dari efektivitas code review. Penelitian Cisco (2015) dan eksperimen selanjutnya oleh SmartBear dan Google menunjukkan: pada volume review lebih dari 400 baris, kemampuan reviewer untuk mendeteksi cacat menurun drastis. Jika PR melebihi 400 baris, kesalahan terdeteksi dengan probabilitas tidak lebih tinggi dari kebetulan.

Ukuran optimal: 200-400 baris untuk satu PR. Volume ini dapat diperiksa oleh reviewer dalam 30-60 menit, dengan tetap menjaga konsentrasi. Google merekomendasikan tidak lebih dari 200 baris untuk satu putaran review dengan konsentrasi penuh. Jika perubahan lebih banyak — tugas harus dipecah menjadi beberapa PR berurutan, yang masing-masing membawa perubahan yang lengkap secara logis.

Waktu review: dalam 24 jam sejak pembuatan PR. Jika review berlarut-larut selama beberapa hari, konteks tugas hilang, dan penulis harus menghabiskan waktu untuk memulihkan konteks saat menanggapi komentar. Tim dengan budaya code review yang tinggi menetapkan SLA untuk review: misalnya, 4 jam untuk perubahan kritis dan 24 jam untuk perubahan biasa.

Cara menulis komentar review yang benar

Nada komentar — sangat penting untuk efektivitas code review. Komentar "Ini salah" memicu reaksi defensif dan tidak memberikan informasi yang berguna kepada penulis. Formulasi terbaik adalah pertanyaan-saran: "Bagaimana pendapatmu tentang pendekatan ini?", "Di sini mungkin terjadi NPE jika user == nil. Mungkin menambahkan guard?". Pertanyaan tidak terlalu menekan dan merangsang diskusi.

Struktur komentar yang baik mencakup tiga bagian: apa yang salah, mengapa itu masalah dan bagaimana memperbaikinya. Contoh: "Dalam loop ini digunakan O(n²) karena contains bersarang, yang dapat memperlambat pada 10k+ record. Coba ganti dengan Set untuk pencarian O(1)". Formulasi seperti ini sekaligus menunjukkan masalah, menjelaskan pentingnya dan menawarkan solusi — penulis tidak perlu menebak.

GitHub dan GitLab mendukung suggestions — saran perubahan kode bawaan. Reviewer dapat menulis: "```suggestion Filter baris kosong sebelum pemrosesan```" — dan penulis menerapkan perubahan dengan satu klik. Ini mempercepat perbaikan kecil dan mengurangi jumlah putaran review. Untuk perbaikan besar, lebih baik menulis komentar umum daripada menempatkan blok besar dalam suggestion.

# Template untuk komentar code review yang baik

# BURUK: "Kode ini salah"
# BAIK: "Kami mungkin kehilangan data pada respons kosong.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# Sintaks saran GitHub:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Workflow code review dalam tim

Workflow review yang efektif didasarkan pada empat tahap. Pertama — penulis menyiapkan PR: menulis nama yang jelas (mis., "feat: add password reset screen"), menambahkan deskripsi perubahan, tautan ke tugas di tracker dan instruksi pengujian. Kedua — penulis menunjuk reviewer melalui auto-assign (berdasarkan CODEOWNERS) atau manual.

Tahap ketiga — reviewer memeriksa kode dan meninggalkan komentar. Keempat — penulis melakukan perbaikan, menanggapi komentar dan meminta review ulang. Siklus berulang hingga mendapatkan persetujuan. Setelah persetujuan, penulis melakukan merge (atau merge dilakukan oleh bot). Otomatisasi melalui Mergify atau GitHub Auto-merge mempercepat tahap akhir.

Elemen penting dari workflow adalah manajemen PR basi. Jika PR tidak direview lebih dari 3 hari, proses terblokir. Solusi: rotasi reviewer (jika reviewer yang ditunjuk tidak tersedia), pemberitahuan melalui Slack/Teams, batas waktu review (SLA). Di beberapa tim, PR tanpa review lebih dari 7 hari secara otomatis ditutup, dan penulis membuat yang baru setelah sinkronisasi dengan main.

• Membuat PR — nama jelas, deskripsi, tautan ke tugas, tangkapan layar untuk perubahan UI.
• Penunjukan — auto-assign melalui CODEOWNERS atau pemilihan manual 1-2 reviewer.
• Review — pemeriksaan dalam urutan: arsitektur → logika → tes → keamanan → gaya.
• Perbaikan — penulis menanggapi semua komentar, memperbaiki blocking issues, meminta re-review.
• Merge — setelah persetujuan dan CI hijau, penulis atau bot melakukan penggabungan.

Kesalahan umum dalam code review

Kesalahan pertama — review dangkal. Reviewer melihat diff secara sekilas, tanpa mendalami logika, dan menekan Approve. Penyebab: PR besar, deadline, kelelahan. Akibat: bug masuk ke production. Solusi: jika tidak punya waktu untuk review berkualitas — tulis dengan jujur "Saya tidak bisa memeriksa hari ini, tunda besok" daripada persetujuan formal.

Kesalahan kedua — kritik berlebihan (nitpicking). Reviewer meninggalkan puluhan komentar tentang gaya format, penamaan variabel, detail sepele. Ini mendemotivasi penulis dan memperpanjang review. Solusi: StyleGuide dan linter harus memeriksa gaya secara otomatis. Manusia dalam review memeriksa logika, arsitektur dan keamanan.

Kesalahan ketiga — review tanpa pertanyaan. Jika reviewer hanya menempatkan Request Changes dan Approve, tetapi tidak mengajukan pertanyaan, ia kehilangan kesempatan untuk mempelajari sesuatu yang baru. Indikator terbaik kesehatan code review adalah adanya diskusi di mana kedua belah pihak belajar sesuatu yang baru. Jika review adalah monolog salah satu peserta — prosesnya rusak.

• Review dangkal — Approve tanpa pendalaman. Solusi: jangan review jika tidak punya waktu.
• Nitpicking — kritik gaya yang diperiksa oleh linter. Solusi: otomatiskan style checks.
• Persepsi pribadi — "saya akan menulis dengan cara berbeda". Solusi: kode harus berfungsi, bukan disukai reviewer.
• Berlarut-larut — review lebih dari 24 jam. Solusi: SLA untuk review, eskalasi saat pelanggaran.
• Mengabaikan konteks — review kode tanpa memahami tugas. Solusi: baca deskripsi PR sebelum diff.