Code Review Anda Kemungkinan Rusak

Sebagian besar code review menangkap antara 15 hingga 30 persen dari defect yang seharusnya ditemukan. Itu bukan tebakan. IBM mengukurnya pada tahun 1970-an, dan studi di AT&T, HP, serta Microsoft telah mengonfirmasi rentang yang sama dari dekade ke dekade.

Review informal murah, asinkron, dan dapat diterima secara sosial. Namun juga sebagian besar tidak efektif dalam menemukan bug. Engineer membaca terlalu cepat, melewati error path, dan menghindari menunjukkan masalah nyata karena tidak ada yang ingin menjadi orang yang menahan merge.

Ada alternatif yang secara konsisten melaporkan tingkat penghapusan defect 60 hingga 90 persen. Itu ditemukan di IBM pada tahun 1976 oleh Michael Fagan. Tidak memerlukan tool, AI, maupun anggaran. Yang dibutuhkan adalah sesuatu yang kebanyakan tim engineering menolak untuk memberikan: struktur.

Apa Itu Fagan Inspection?

Fagan inspection adalah proses review multi-tahap yang didefinisikan secara formal dengan peran spesifik, timeout, kriteria masuk, dan checklist. Berbeda dengan pull request review biasa, ini bukan percakapan antara author dan reviewer. Ini adalah pertemuan terstruktur dengan moderator, reader, inspector, dan author.

Author sebagian besar diam. Pertemuan dibatasi waktu secara ketat. Dan satu-satunya tujuan adalah menemukan defect.

Prosesnya mengikuti enam langkah:

  1. Planning. Moderator memilih materi, memverifikasi entry criteria, menetapkan peran, dan menjadwalkan pertemuan. Entry criteria ada alasannya. Anda tidak menginspeksi draft. Dokumen harus lengkap, dapat dikompilasi, dan telah diuji sebelum layak menghabiskan waktu empat orang.

  2. Overview. Opsional. Author menjelaskan konteks jika inspector tidak familier dengan domainnya.

  3. Preparation. Setiap inspector meninjau materi secara sendiri sebelum pertemuan. Ini tidak bisa ditawar. Anda tidak datang tanpa persiapan. Inspector menggunakan checklist yang disesuaikan dengan tipe defect umum dan memberi anotasi issue secara pribadi.

  4. Inspection. Pertemuan itu sendiri. Reader, yang tidak menulis kode, membacanya baris per baris dan men parafrasekan dengan suara keras. Inspector mengangkat issue ketika menemukan ketidaksesuaian. Author mendengarkan. Tidak ada yang mengusulkan fix. Moderator menegakkan timeout dan memastikan pertemuan tetap fokus pada identifikasi defect saja.

  5. Rework. Author memperbaiki defect.

  6. Follow-up. Moderator memverifikasi setiap defect telah ditangani. Jika terlalu banyak defect ditemukan, dilakukan reinspection.

Empat peran menjaga proses tetap jujur. Moderator merencanakan dan mengendalikan. Author membuat pekerjaan dan hanya menjawab pertanyaan jika diminta. Reader memparafrasekan kode selama pertemuan, memaksa pemahaman yang lebih lambat dan cermat. Inspector, biasanya dua hingga empat orang, menemukan defect.

Mengapa Review Informal Gagal di Tempat Fagan Inspection Berhasil

Perbedaannya bukan bakat. Itu adalah desain proses.

Dalam pull request review yang biasa, reviewer membaca diff di browser, membaca sekilas happy path, meninggalkan beberapa komentar, dan menyetujui. Tidak ada waktu persiapan. Tidak ada checklist. Tidak ada mekanisme yang memaksa reviewer untuk memeriksa error handling atau boundary condition. Dinamika sosial menghargai kecepatan dan kesopanan, bukan ketelitian.

Fagan inspection membalik insentif tersebut.

Persiapan individual berarti setiap inspector benar-benar telah membaca kode sebelum pertemuan dimulai. Parafrase dari reader memaksa kelompok untuk memproses kode dengan kecepatan pemahaman alih-alih kecepatan membaca sekilas. Checklist mengarahkan perhatian ke kategori defect yang diketahui alih-alih apa pun yang menarik perhatian. Tekanan waktu mencegah pertemuan menyimpang ke perdebatan desain. Dan memisahkan penemuan defect dari perbaikan defect mencegah kelompok berlabuh pada solusi pertama yang diusulkan seseorang.

Hasilnya adalah Fagan inspection menangkap sebagian besar defect sebelum mencapai testing atau production.

Biayanya dimuat di depan dalam person-hours.

Trade-off Nyata: Person-hours vs. Defect Escape

Inilah mengapa kebanyakan tim tidak menggunakan Fagan inspection.

Satu inspection membutuhkan empat hingga enam orang dalam satu ruangan selama hingga dua jam untuk meninjau sekitar 250 baris kode. Itu 8 hingga 12 person-hours untuk perubahan kecil. Dalam workflow CI/CD modern di mana tim mengirimkan beberapa kali sehari, ini terlihat absurd.

Prosesnya juga terasa birokratis. Entry criteria, peran formal, checklist cetak, verifikasi follow-up. Sebagian besar engineer akan membencinya secara prinsip. Dan tidak dapat diskalakan untuk diff besar. Sebuah refactor dua ribu baris akan memerlukan delapan pertemuan inspection terpisah.

Namun perhitungannya berubah ketika Anda melihat total biaya alih-alih biaya pertemuan.

Data asli IBM menunjukkan bahwa menemukan dan memperbaiki defect selama inspection menghabiskan biaya sekitar sepersepuluh dari biaya menemukan dan memperbaiki defect yang sama selama testing. Ketika lolos ke production, rasio meningkat menjadi dua puluh atau tiga puluh banding satu.

Jadi ya, inspection mahal. Namun tetap lebih murah daripada debugging production incident, membakar kapasitas sprint untuk perbaikan reaktif, dan kehilangan kepercayaan pelanggan.

Masalahnya adalah penghematannya tidak terlihat. Anda tidak dapat mengukur bug yang telah dicegah. Biaya pertemuan segera dan jelas. Itulah mengapa review informal menang di sebagian besar organisasi. Ini mengoptimalkan kecepatan yang terlihat daripada kualitas yang tidak terlihat.

Menjalankan Fagan Inspection Ringan pada 2026

Anda tidak perlu mengadopsi seluruh ceremony. Kebanyakan tim bisa mendapatkan tujuh puluh persen manfaat dengan dua puluh persen overhead dengan menjaga core mechanics dan membuang paperwork.

Berikut adalah urutan praktis:

Wajibkan persiapan individual sebelum review sinkron apa pun. Jika Anda belum membaca kodenya, Anda tidak hadir.

Tetapkan reader yang tidak menulis kode untuk membacakan logikanya dengan suara keras. Jangan biarkan author memimpin. Parafrase memaksa kelompok untuk memproses setiap branch.

Gunakan checklist yang disesuaikan dengan tipe defect paling umum di tim Anda. Mulai dengan daftar di bawah dan tambahkan item seiring Anda belajar dari defect yang lolos.

Timebox selama sembilan puluh menit. Akhiri tepat waktu, bahkan jika belum selesai. Jadwalkan sesi kedua alih-alih membiarkan kelelahan menghancurkan kualitas.

Pertahankan author dalam posisi pasif. Mereka hanya menjawab pertanyaan klarifikasi. Tanpa membela pilihan desain.

Catat defect, bukan solusi. Perbaiki defect setelah pertemuan.

Untuk membuatnya konkret, berikut adalah skrip Python kecil yang merencanakan inspection, memperkirakan waktu, dan mencetak checklist khusus peran:

#!/usr/bin/env python3
"""
Plan a Fagan-style inspection: estimate time and emit checklists.
"""

import argparse


def count_lines(filepath):
    """Count non-blank lines."""
    try:
        with open(filepath, "r") as f:
            return sum(1 for line in f if line.strip())
    except Exception:
        return 0


def plan_inspection(files, rate=125):
    """
    rate: reviewable lines per hour. Fagan recommended 100-125 for code.
    """
    total = sum(count_lines(f) for f in files)
    hours = total / rate
    minutes = hours * 60

    print(f"Total reviewable lines: {total}")
    print(f"At {rate} lines/hour, schedule: {hours:.1f} hours ({minutes:.0f} min)")

    if hours > 2:
        sessions = int(hours / 2) + 1
        print(f"WARNING: exceeds 2-hour limit. Split into {sessions} sessions.")

    print("\n--- ROLE: Reader ---")
    print("Paraphrase each block aloud. Do not just read variable names.")
    print("Pause at every conditional, loop boundary, and API call.")

    print("\n--- ROLE: Inspector ---")
    checklist = [
        "Off-by-one in loops and array or slice access",
        "Null, None, or undefined dereferences",
        "Resource leaks: files, connections, locks, contexts",
        "Error paths: are they handled, returned, and tested?",
        "Return values: are they checked before use?",
        "Shared mutable state and thread safety",
        "Boundary conditions and input validation",
        "Invariant violations: what should stay true, and does it?",
    ]
    for item in checklist:
        print(f"  [ ] {item}")

    print("\n--- ROLE: Moderator ---")
    print("Start on time. End on time.")
    print("No design debates. No solution proposals.")
    print("Record each defect with: file, line, severity, type.")


if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Plan a Fagan inspection")
    parser.add_argument("files", nargs="+", help="Source files to inspect")
    parser.add_argument("--rate", type=int, default=125, help="Lines per hour")
    args = parser.parse_args()

    plan_inspection(args.files, args.rate)

Simpan sebagai inspect.py, jalankan python inspect.py src/auth.py src/orders.py, dan Anda memiliki perkiraan waktu dan checklist.

Pertanyaan yang Sering Diajukan

Apa itu Fagan inspection?

Fagan inspection adalah proses review terstruktur enam langkah dengan peran yang ditentukan, entry criteria, dan checklist. Dikembangkan oleh Michael Fagan di IBM pada tahun 1976 untuk menemukan defect dalam work product software sebelum testing.

Apa bedanya Fagan inspection dengan pull request review?

Pull request review biasanya asinkron, informal, dan didorong oleh author. Fagan inspection adalah pertemuan sinkron dengan peran yang ditetapkan, persiapan individual wajib, timeout ketat, dan aturan bahwa author tetap diam sementara orang lain menemukan defect.

Mengapa Fagan inspection tidak lebih umum?

Karena mahal dalam person-hours, terasa birokratis bagi tim modern, dan tidak diskalakan dengan baik untuk perubahan besar dan sering. Biayanya terlihat dan segera. Defect yang dicegah tidak terlihat.

Apakah Fagan inspection bisa bekerja dalam lingkungan agile atau CI/CD?

Ya, tetapi dengan modifikasi. Kebanyakan tim menggunakan versi ringan: persiapan individual wajib, reader yang memparafrasekan, checklist, dan timebox ketat. Proses formal lengkap biasanya dicadangkan untuk module kritis atau berisiko tinggi.

Cobalah pada Satu Module

Anda tidak perlu menulis ulang proses Anda. Pilih satu module yang memiliki defect lolos dalam sebulan terakhir. Kumpulkan tiga engineer yang tidak menulisnya. Berikan mereka kode dan checklist dua puluh empat jam sebelumnya. Jadwalkan sembilan puluh menit. Tetapkan reader. Buat author mendengarkan.

Ukur apa yang Anda temukan. Kemudian putuskan apakah pertemuan itu lebih mahal daripada bug yang akan terjadi.

Jika Anda menginginkan data asli, makalah Fagan tahun 1976 “Design and Code Inspections to Reduce Errors in Program Development” masih menjadi referensi terbaik. Usianya lima puluh tahun, dan kebanyakan tim masih belum menyusul.