Setiap Lapisan Review Membuat Tim Kamu Makin Lambat

Sebuah startup merilis bug ke production. Respons manajemen: tambahkan syarat code review. Ada bug lain yang lolos. Respons: wajibkan dua reviewer. Lalu terjadi insiden keamanan. Respons: tambahkan tahap security review. Lalu ada inkonsistensi desain. Respons: tambahkan design review. Dalam dua tahun, setiap perubahan, sekecil apa pun, harus melewati empat tahap review, butuh tiga hari untuk di-merge, dan developer yang dulu merilis setiap hari kini menghabiskan lebih banyak waktu me-review kode daripada menulisnya.

Pola ini begitu umum sampai hampir terasa seperti hukum perilaku organisasi: setiap insiden melahirkan lapisan review baru, dan tidak ada lapisan review yang pernah dihapus. Hasilnya adalah proses review yang dioptimalkan untuk mencegah insiden terakhir, dengan harga mencegah semua kemajuan di masa depan.

Matematika Antrean Review

Setiap lapisan review bukan cuma menambah waktu, tapi melipatgandakannya. Jika satu review rata-rata butuh 4 jam untuk selesai (bukan review-nya yang memakan 20 menit, melainkan waktu PR menunggu di antrean sampai reviewer sempat membukanya), maka dua review berurutan memakan 8 jam. Tiga review memakan 12 jam. Empat review memakan 16 jam.

Tapi kondisinya lebih buruk karena context switching. Developer mengirim PR, lalu mulai mengerjakan hal lain. Ketika feedback review datang berjam-jam kemudian, mereka harus kembali ke pekerjaan lama, memuat ulang konteks, memperbaiki feedback, mengirim ulang, lalu menunggu lagi. Setiap putaran review menambah 30-60 menit overhead context switching di atas waktu antrean.

Lalu ada efek berantai. Jika reviewer A meminta perubahan, developer memperbaikinya dan mengirim ulang. Sekarang reviewer B, yang belum pernah melihat PR ini, me-review dan meminta perubahan yang berbeda. Developer memperbaiki itu juga. Sekarang reviewer A perlu me-review ulang untuk memastikan feedback-nya sudah diterapkan, tapi dia sudah pindah ke pekerjaan lain dan PR itu kembali ke antrean.

Timeline of a PR through a 3-reviewer process:
Day 1 9:00  — Developer submits PR
Day 1 14:00 — Reviewer A reviews, requests changes
Day 1 15:00 — Developer addresses feedback, resubmits
Day 2 10:00 — Reviewer B reviews, requests different changes
Day 2 11:00 — Developer addresses, resubmits
Day 2 16:00 — Reviewer A re-reviews, approves
Day 3 11:00 — Reviewer C reviews, approves
Day 3 11:30 — Reviewer B re-reviews, approves
Day 3 12:00 — PR merges
Elapsed time: ~3 business days
Actual review time: ~90 minutes total
Actual code change time: ~2 hours
Time waiting in queues: ~22 hours
Queue time is 80% of the total elapsed time.

Paradoks Kualitas

Asumsi di balik penambahan lapisan review adalah bahwa review yang lebih banyak menghasilkan kode yang lebih baik. Ini benar sampai titik tertentu, lalu justru berbalik arah.

Satu reviewer yang teliti menangkap masalah nyata: error logika, edge case yang terlewat, masalah keamanan, dan kekhawatiran soal desain API. Reviewer kedua kadang-kadang menangkap hal yang terlewat oleh yang pertama, mungkin 10-20% dari waktu. Reviewer ketiga hampir tidak pernah menemukan apa pun yang tidak ditemukan dua reviewer sebelumnya. Nilai tambah setiap reviewer tambahan turun drastis.

Sementara itu, biaya kualitas dari merge yang lambat itu nyata tapi tidak pernah dihitung. Branch yang hidup lama menyimpang dari main, sehingga butuh rebase yang bisa memunculkan error saat merge. Developer menggabungkan lebih banyak perubahan ke setiap PR untuk menghindari overhead review per PR, sehingga tiap PR makin besar dan makin sulit di-review dengan teliti. Reviewer juga kelelahan: saat antrean review berisi 15 PR, kamu cenderung men-skim alih-alih membaca dengan saksama.

Paradoksnya: menambah lapisan review demi meningkatkan kualitas justru bisa menurunkannya, karena menciptakan insentif (PR yang makin besar, review yang terburu-buru, branch yang basi) yang justru merusak proses review itu sendiri.

Apa Sebenarnya yang Dicegah oleh Proses Review yang Berat

Proses review sering dibenarkan oleh insiden tertentu. 'Kita merilis bug karena tidak ada yang me-review kodenya.' Tapi bertanya apakah review akan menangkap bug spesifik itu berbeda dengan bertanya apakah syarat review secara keseluruhan memperbaiki hasil.

Studi tentang efektivitas code review secara konsisten menemukan bahwa review menangkap sekitar 60% cacat, kebanyakan masalah permukaan seperti penamaan, formatting, dan error logika yang jelas. Bug arsitektur yang dalam, masalah konkurensi, dan kerentanan keamanan jarang tertangkap lewat code review karena butuh pemahaman terhadap seluruh sistem, bukan sekadar diff. Bug yang menyebabkan insiden di production justru didominasi oleh jenis yang tidak tertangkap review.

Yang benar-benar mencegah insiden di production adalah testing, monitoring, dan kemampuan untuk deploy dan rollback dengan cepat. Tim yang merilis dengan cepat dengan test yang bagus, feature flag, dan rollback instan akan mengalami lebih sedikit insiden dibanding tim dengan empat lapis review tapi tanpa integration test dan siklus deploy yang memakan waktu berjam-jam.

Jumlah Review yang Tepat

Code review itu berharga. Satu reviewer per PR, dengan ekspektasi yang jelas tentang apa yang harus diperiksa, adalah titik optimal bagi kebanyakan tim. Begini bentuknya dalam praktik.

• Satu reviewer, bukan dua atau tiga. Reviewer pertama menangkap 80% dari hal yang bisa ditangkap review. Reviewer kedua menambah nilai yang kecil dengan biaya yang besar. Sisakan proses multi-reviewer untuk perubahan yang benar-benar berisiko tinggi (migrasi database, perubahan auth, modifikasi public API).
• Batasi waktu antrean review. Jika PR belum di-review dalam 4 jam, itu kegagalan proses, bukan masalah reviewer yang malas. Tim perlu memprioritaskan kapasitas review atau menerima bahwa jumlah developer mereka melebihi apa yang bisa ditopang proses review mereka.
• PR kecil, bukan yang besar. PR 50 baris mendapat review yang teliti dalam 10 menit. PR 500 baris mendapat review sekilas dalam 30 menit. PR 50 baris justru mendapat review yang lebih baik meski waktunya lebih sedikit. Batas ukuran (maksimal 200-300 baris) lebih efektif meningkatkan kualitas review dibanding menambah reviewer.
• Lewati review untuk perubahan berisiko rendah. Perubahan config, update copy, dependency bump, penambahan test: ini tidak butuh pengawasan seketat perubahan business logic. Tentukan kategori 'risiko rendah' dan izinkan self-merge dengan review setelah merge.
• Otomatiskan apa yang lebih baik dikerjakan mesin. Linting, formatting, type checking, test coverage: ini tugas review yang bisa dikerjakan mesin lebih cepat dan konsisten dibanding manusia. Jangan buang perhatian reviewer untuk hal-hal yang sudah ditangani oleh CI check.

Masalah Budaya

Mengurangi lapisan review itu sulit karena terasa seperti mengurangi keamanan. Tidak ada yang mau jadi orang yang mengusulkan review lebih sedikit tepat sebelum insiden di production. Ini masalah budaya organisasi, bukan masalah teknis.

Cara pandang yang membantu: review hanyalah salah satu mekanisme keamanan, dan hasilnya semakin berkurang. Menambah reviewer keempat untuk mencegah bug itu seperti menambah gembok keempat untuk mencegah pencurian. Gembok pertama sudah mengerjakan sebagian besar pekerjaannya, dan setiap gembok tambahan hanya menambah repot tanpa peningkatan keamanan yang sepadan. Kamu tidak akan memasang empat gembok. Jadi jangan tambah empat reviewer.

Tim yang merilis cepat dan jarang rusak biasanya berinvestasi pada mekanisme yang benar-benar mencegah insiden: automated testing yang komprehensif, feature flag untuk rilis bertahap, monitoring yang andal dengan alerting, rollback satu klik, dan budaya blameless yang memperlakukan insiden sebagai peluang belajar, bukan sasaran menyalahkan. Investasi ini berakumulasi seiring waktu dengan cara yang tidak dimiliki lapisan review.

Menghapus Lapisan Review

Jika tim kamu sudah menumpuk terlalu banyak syarat review, begini cara menguranginya tanpa bikin panik.

Mulailah dengan mengukur proses yang ada. Berapa lama PR dari pengiriman sampai di-merge? Berapa banyak waktu itu dihabiskan di antrean dibanding review aktif? Berapa PR yang ada di antrean review pada waktu tertentu? Angka-angka ini membuat biayanya terlihat. Kebanyakan tim kaget saat tahu rata-rata PR mereka butuh 3 hari untuk di-merge.

Lalu jalankan eksperimen. Selama satu bulan, minta satu reviewer, bukan dua. Lacak metrik yang sama. Apakah tingkat insiden berubah? Apakah kualitas kode (diukur dari tingkat cacat, bukan dari perasaan) berubah? Hampir selalu jawabannya: insiden tidak meningkat, kualitas tetap, dan throughput membaik secara signifikan.

Tujuannya bukan nol review, melainkan review minimum yang tetap menjaga kualitas sambil memaksimalkan throughput. Jumlah minimum itu hampir selalu lebih sedikit dari yang sedang dilakukan tim saat ini, karena lapisan review menumpuk lewat respons insiden tapi jarang dihapus lewat optimasi proses. Seperti kebanyakan hal dalam membangun software yang hebat, jawabannya bukan lebih banyak proses, melainkan proses yang tepat.