Review Pull Request Menangkap 15-30% Defek. Data Sudah Menyatakan Demikian Selama 50 Tahun.

Angka yang Tidak Ingin Dibicarakan Siapa Pun

Code review informal menangkap antara 15 hingga 30 persen defek yang ada di dalam kode yang ditinjau. Itu bukan pendapat. Itu adalah temuan yang telah direplikasi selama empat dekade, beberapa perusahaan, dan puluhan studi.

Michael Fagan mendokumentasikannya di IBM pada 1976. Sebuah studi tahun 1987 di AT&T Bell Labs menemukan 20 persen. Sebuah studi HP tahun 1996 menemukan 25 persen. Sebuah paper Microsoft Research tahun 2013 tentang code review modern menemukan rentang yang kurang lebih sama. Alatnya berubah dari punched card ke GitHub, tetapi kurva performa manusia tidak bergerak.

Jika tim Anda menganggap pull request review sebagai penjaga kualitas utama, data mengatakan Anda menangkap kira-kira satu bug dari empat. Tiga sisanya terkirim ke produksi.

Dari Mana Angka-angka Itu Berasal

Metodologi asli Fagan sederhana dan brutal. Dia menyuntikkan defek yang diketahui ke dalam kode, menjalankan proses review, dan menghitung berapa banyak yang ditemukan reviewer. Kemudian dia membandingkannya dengan total defek yang akhirnya ditemukan tim melalui pengujian, incident produksi, dan laporan pelanggan. Rasio dari ditemukan-saat-review terhadap total-defek menjadi removal rate.

Wawasan kuncinya adalah bahwa penyebutnya penting. Sebuah review yang menemukan sepuluh defek terdengar bagus sampai Anda tahu ada lima puluh di dalam file tersebut. Fagan mengukur penyebut penuh. Kebanyakan tim saat ini tidak melakukannya.

Studi-studi berikutnya menggunakan desain serupa. Para peneliti menyematkan defek, membandingkan jenis review, atau melacak defek ke belakang dari produksi untuk melihat di mana mereka seharusnya bisa tertangkap. Hasilnya berkumpul rapat:

Jenis review	Defect removal rate	Studi kunci
Tidak ada review	0%	Baseline
Informal / PR review	15-30%	Fagan 1976, Porter 1995, Microsoft 2013
Walkthrough terstruktur	30-50%	Yourdon 1979, Weller 1993
Fagan inspection	60-90%	Fagan 1976, Russell 1991, NASA 2002

Celah antara review informal dan terstruktur tidak kecil. Itu adalah perbedaan 3x dalam defect escape rate.

Mengapa PR Review Berkinerja Sangat Buruk

Masalahnya bukanlah reviewer buruk dalam pekerjaannya. Masalahnya adalah pull request review tidak dirancang untuk menemukan defek. Itu dirancang untuk membuat dua orang setuju bahwa kode bisa di-merge.

Berikut ini yang sebenarnya terjadi dalam PR review yang tipikal. Reviewer membuka diff. Mereka membaca ringkasan, memindai penambahan, memeriksa apakah tes lulus, dan mencari sesuatu yang jelas salah. Ini memakan waktu lima hingga lima belas menit. Kemudian mereka approve.

Prosesnya dioptimalkan untuk kecepatan, bukan ketelitian. Tidak ada waktu persiapan. Reviewer belum membaca kode di sekitarnya, melacak stream data, atau membangun model mental dari perubahan tersebut. Mereka bereaksi terhadap diff di layar, dan otak manusia sangat buruk dalam menemukan bug dalam format tersebut.

Sebuah studi tahun 2015 oleh Bacchelli dan Bird di Microsoft menemukan bahwa kategori komentar review yang paling umum sama sekali tidak terkait defek. Kategori teratas adalah pertanyaan tentang niat, permintaan klarifikasi, dan saran perbaikan. Temuan defek yang sebenarnya adalah minoritas dari komentar. Alat tersebut berfungsi sebagai saluran komunikasi, bukan quality gate.

Ini baik-baik saja jika Anda tahu apa yang dilakukan alat tersebut. Ini berbahaya jika Anda mengira ia melakukan sesuatu yang lain.

Apa yang Dilakukan Review Terstruktur Secara Berbeda

Fagan inspection dan metode review terstruktur lainnya mencapai removal rate yang lebih tinggi dengan mengubah desain proses, bukan orangnya.

Tuas terbesar adalah persiapan individual. Dalam Fagan inspection, setiap reviewer menghabiskan waktu fokus dengan materi sebelum ada diskusi kelompok. Fagan menemukan bahwa inspector yang telah mempersiapkan diri menemukan kira-kira dua kali lebih banyak defek dibandingkan mereka yang masuk tanpa persiapan. Model PR secara default adalah model masuk-tanpa-persiapan.

Tuas kedua adalah kecepatan. Fagan merekomendasikan 100 hingga 125 baris kode per jam review. Kebanyakan reviewer PR memproses sepuluh kali kecepatan itu. Kecepatan membunuh deteksi. Otak Anda mengisi pola yang diharapkan alih-alih membaca apa yang sebenarnya ada di sana.

Tuas ketiga adalah fokus. Rapat Fagan memiliki satu tujuan tunggal: mencatat defek. Tidak ada perdebatan desain. Tidak ada usulan solusi. Tidak ada diskusi gaya. Thread PR secara rutin menyimpang ke opini arsitektur, yang mengonsumsi anggaran kognitif yang sama yang bisa menemukan null dereference.

Tuas keempat adalah peran pembaca. Meminta seseorang yang tidak menulis kode untuk memparafrasekannya dengan lantasan memaksa grup untuk memproses pada kecepatan pemahaman alih-alih kecepatan pemindaian. Sebuah diff di layar membuat mata Anda melewati bagian-bagian membosankan. Seseorang yang berbicara tidak melewatinya.

Argumen Biaya Justru Terbalik

Keberatan biasa terhadap review terstruktur adalah biaya. Sebuah Fagan inspection memakan empat hingga enam jam-orang untuk beberapa ratus baris kode. Sebuah PR review memakan lima belas menit waktu satu orang. Perhitungannya terlihat jelas.

Itu jelas, dan itu salah.

Fagan juga mengukur biaya menemukan defek pada tahap yang berbeda. Sebuah defek yang ditemukan selama inspection dikenakan biaya sekitar sepersepuluh dari biaya menemukannya selama pengujian. Ketika lolos ke produksi, rasio meningkat menjadi dua puluh atau tiga puluh banding satu. Studi NASA tahun 2002 menemukan bahwa setiap jam yang dihabiskan untuk inspection mencegah rata-rata 33 jam pekerjaan pemeliharaan kemudian.

Penghematannya tidak terlihat. Anda tidak bisa mengukur bug yang Anda cegah. Biaya rapat langsung dan jelas. Itulah sebabnya organisasi mengoptimalkan kecepatan yang terlihat daripada kualitas yang tidak terlihat, bahkan ketika data mengatakan hal itu pada akhirnya membuat mereka lebih mahal.

Jalan Tengah yang Didorong Data

Anda tidak membutuhkan budaya rapat IBM untuk mendapatkan sebagian besar manfaatnya. Anda perlu meminjam fitur-fitur proses yang benar-benar menggerakkan angka, dan membuang yang tidak.

Berikut ini yang dikatakan data sebagai penting:

1. Waktu persiapan. Wajibkan reviewer untuk menghabiskan waktu dengan kode sebelum berkomentar. Bahkan sepuluh menit membaca yang fokus mengalahkan sekadar melirik.

2. Batas kecepatan. Untuk file kritis, tegakkan kecepatan review maksimum. Jika seorang reviewer menyetujui perubahan 500 baris dalam lima menit, itu adalah data, bukan ketelitian.

3. Fokus hanya defek. Pisahkan feedback gaya dan arsitektur dari pencarian defek. Gunakan formatter otomatis untuk yang pertama. Cadangkan perhatian manusia untuk yang kedua.

4. Checklist. Fagan menemukan bahwa reviewer yang didorong checklist menemukan defek yang dilewati reviewer yang didorong intuisi. Checklist ada karena keahlian menciptakan titik buta.

Berikut adalah skrip ringan yang mengukur kedalaman review dari riwayat Git. Ini memperkirakan apakah sebuah review memiliki cukup waktu untuk menjadi teliti:

#!/usr/bin/env python3
"""Estimate review depth from git history."""

import subprocess
import sys
from datetime import datetime, timezone


def get_commit_info(commit_hash: str) -> dict:
    """Return author, committer, and timestamps for a commit."""
    fmt = "%H|%an|%cn|%ad|%cd"
    result = subprocess.run(
        ["git", "log", "-1", f"--format={fmt}", commit_hash],
        capture_output=True,
        text=True,
        check=True,
    )
    parts = result.stdout.strip().split("|")
    return {
        "hash": parts[0],
        "author": parts[1],
        "committer": parts[2],
        "author_date": datetime.strptime(parts[3], "%a %b %d %H:%M:%S %Y %z"),
        "commit_date": datetime.strptime(parts[4], "%a %b %d %H:%M:%S %Y %z"),
    }


def get_lines_changed(commit_hash: str) -> int:
    """Count total lines added + deleted in a commit."""
    result = subprocess.run(
        ["git", "diff", f"{commit_hash}^", commit_hash, "--stat"],
        capture_output=True,
        text=True,
        check=True,
    )
    # Last line of --stat contains totals like "3 files changed, 42 insertions(+), 7 deletions(-)"
    for line in reversed(result.stdout.strip().splitlines()):
        line = line.strip()
        if "insertions" in line or "deletions" in line:
            # Extract numbers roughly
            parts = line.split(",")
            total = 0
            for part in parts:
                digits = "".join(ch for ch in part if ch.isdigit())
                if digits:
                    total += int(digits)
            return total
    return 0


def estimate_review_depth(commit_hash: str) -> dict:
    """Estimate whether a commit had time for thorough review.

    Returns lines changed, time between author and commit dates
    (a rough proxy for review duration), and a verdict.
    """
    info = get_commit_info(commit_hash)
    lines = get_lines_changed(commit_hash)

    # Time between author date and commit date is a proxy for review time
    # In many workflows, commit date reflects when the merge happened
    review_seconds = (info["commit_date"] - info["author_date"]).total_seconds()
    review_hours = review_seconds / 3600

    # Fagan recommended 100-125 lines/hour for thorough review
    fagan_rate = 125
    needed_hours = lines / fagan_rate if lines else 0

    verdict = "insufficient"
    if review_hours >= needed_hours:
        verdict = "adequate"
    if review_hours >= needed_hours * 2:
        verdict = "thorough"

    return {
        "hash": commit_hash[:8],
        "lines": lines,
        "review_hours": round(review_hours, 2),
        "needed_hours": round(needed_hours, 2),
        "verdict": verdict,
    }


if __name__ == "__main__":
    commit = sys.argv[1] if len(sys.argv) > 1 else "HEAD"
    result = estimate_review_depth(commit)
    print(f"Commit:       {result['hash']}")
    print(f"Lines:        {result['lines']}")
    print(f"Review time:  {result['review_hours']} hours")
    print(f"Fagan time:   {result['needed_hours']} hours")
    print(f"Verdict:      {result['verdict']}")

Simpan sebagai review_depth.py dan jalankan:

python review_depth.py abc1234

Outputnya akan memberi tahu Anda apakah sebuah commit memiliki cukup waktu review untuk menjadi teliti menurut standar Fagan. Sebagian besar commit akan mengatakan insufficient. Itulah intinya. Data telah memberi tahu kita hal ini selama puluhan tahun, dan kita terus membangun pipeline yang lebih cepat alih-alih yang lebih baik.

Apa Artinya Ini untuk Tim Anda

Pull request review tidak sia-sia. Ini membangun konteks bersama, menyebarkan pengetahuan, dan menangkap kesalahan yang jelas. Tetapi data jelas tentang apa yang tidak dilakukannya. Ini tidak menangkap sebagian besar defek.

Jika strategi kualitas Anda bergantung pada PR review sebagai filter utama, Anda menyaring dengan ayakan. Removal rate 15-30% bukanlah kegagalan reviewer Anda. Itu adalah sifat dari prosesnya.

Tim-tim yang mengalahkan angka ini tidak mempekerjakan orang yang lebih pintar. Mereka mengubah prosesnya. Mereka menambahkan waktu persiapan, menegakkan batas kecepatan, memisahkan pencarian defek dari diskusi desain, dan menggunakan checklist untuk mengarahkan perhatian ke tempat di mana intuisi meleset.

Anda tidak membutuhkan Fagan inspection penuh untuk setiap diff. Anda perlu mengetahui apa yang sebenarnya dicapai oleh proses Anda saat ini, dan berhenti berpura-pura bahwa itu mencapai lebih banyak.

FAQ

Apa yang dikatakan data tentang efektivitas pull request review?

Banyak studi di IBM, AT&T, HP, dan Microsoft secara konsisten menemukan bahwa code review informal menangkap 15-30% defek yang ada di dalam kode. Rentang ini tetap stabil dari tahun 1970-an hingga penelitian modern tentang workflow berbasis GitHub.

Mengapa review pull request menangkap begitu sedikit defek?

PR review dioptimalkan untuk kecepatan dan persetujuan merge, bukan deteksi defek yang sistematis. Reviewer biasanya menghabiskan 5-15 menit per review, tidak memiliki waktu persiapan, memproses kode pada kecepatan 10x dari yang direkomendasikan penelitian, dan formatnya mendorong pembacaan cepat alih-alih analisis mendalam.

Seberapa jauh lebih baik review terstruktur seperti Fagan inspection?

Fagan inspection secara konsisten melaporkan defect removal rate 60-90%, kira-kira 3-4x lebih baik daripada review informal. Perbedaannya berasal dari persiapan individual, batas kecepatan yang ditegakkan, pemisahan peran, fokus yang didorong checklist, dan rapat yang mencatat defek alih-alih memperdebatkan solusi.

Apa cara termurah untuk meningkatkan efektivitas PR review?

Wajibkan persiapan individual sebelum berkomentar, gunakan checklist yang disesuaikan dengan jenis defek umum tim Anda, pisahkan feedback gaya dari pencarian defek, dan batasi kecepatan review untuk file kritis. Bahkan perubahan kecil pada persiapan dan fokus dapat menggerakkan angka secara signifikan tanpa menambahkan overhead rapat.

Bagaimana cara mengukur defect removal rate aktual tim saya?

Lacak defek yang ditemukan saat review versus defek yang ditemukan kemudian saat pengujian atau produksi. Rasio dari tertangkap-dini terhadap total-ditemukan adalah removal rate Anda. Kebanyakan tim tidak melacak ini, itulah sebabnya mereka melebih-lebihkan efektivitas review. Mulailah mencatat di mana setiap defek ditemukan, lalu hitung rasio setiap bulan.