Dua Reviewer, Satu Diff, Nol Tumpang Tindih

Dua engineer senior me-review pull request yang sama. Satu menandai null check yang hilang. Yang lain menemukan race condition di cleanup path. Tidak satu pun dari mereka menemukan keduanya.

Jika Anda hanya menugaskan satu reviewer, salah satu bug tersebut akan terkirim. Ini bukan kesenjangan skill. Ini adalah sifat prediktabil dari perhatian manusia, dan Michael Fagan mendokumentasikannya di IBM pada 1976.

Fagan mengukur tingkat deteksi defect di pipeline software IBM. Datanya menunjukkan sesuatu yang tidak nyaman: bahkan inspector berpengalaman hanya menangkap sebagian kecil dari total defect yang akhirnya ditemukan oleh grup. Nilai sebenarnya tidak terletak pada keahlian satu orang. Ia terletak pada kombinasi terstruktur dari berbagai perspektif.

Sebagian besar tim saat ini tidak menyusun kombinasi tersebut. Seorang engineer senior membaca diff di antara meeting, menyadari issue style, menyetujui, dan melanjutkan. Reviewer berikutnya melakukan hal yang sama. Keduanya melewatkan error off-by-one yang merusak data produksi Selasa depan.

Fagan menyebut ini sebagai sindrom review tidak terstruktur. Grup tersebut memiliki mata, tetapi tidak memiliki proses.

Apa Sebenarnya Fagan Inspection Itu

Fagan Inspection bukanlah meeting di mana orang membaca kode bersama dan berbagi perasaan. Ini adalah proses formal dengan peran yang ditentukan, kriteria masuk, dan output yang terukur. Fagan merancangnya karena review tidak terstruktur membuang-buang waktu dan membiarkan defect bocor pada tingkat yang kurang lebih sama dengan tidak melakukan review sama sekali.

Wawasan intinya adalah pemisahan peran. Setiap orang memiliki tepat satu tugas:

  • Moderator menjalankan meeting dan menegakkan aturan. Mereka tidak melakukan inspeksi.
  • Reader menafsirkan kode dengan keras. Ini memaksa grup untuk menghadapi apa yang sebenarnya dilakukan kode, bukan apa yang dimaksudkan oleh author.
  • Tester memikirkan execution path, boundary condition, dan coverage gap.
  • Author menjawab pertanyaan tetapi tidak membela kode.

Pemisahan ini mencegah failure mode paling umum dari group review: author membujuk semua orang untuk mengabaikan kekhawatiran mereka.

Ketika author juga menjadi penjelas, mereka menghaluskan ambiguitas. “Oh, variabel itu selalu diatur oleh caller.” Grup mengangguk. Tidak ada yang memeriksa. Peran reader ada untuk memutuskan kebiasaan ini. Jika reader tidak dapat menafsirkan fungsi dalam satu kalimat, fungsi tersebut belum siap untuk dikirim.

Mengapa Checklist Mengalahkan Intuisi

Fagan juga memperkenalkan inspection checklist. Ini bukan standar pengkodean generik yang disalin dari style guide. Mereka disesuaikan dengan jenis artefak spesifik yang sedang di-review.

Checklist untuk state machine bertanya: apakah Anda menangani setiap transisi? Checklist untuk resource allocator bertanya: apakah setiap allocation dipasangkan dengan deallocation di setiap path?

Checklist ada karena perhatian manusia tidak merata. Seorang ahli yang telah menulis sepuluh ribu database query akan secara mental melewati blok BEGIN TRANSACTION. Otak mereka menganggapnya benar secara otomatis. Fagan menemukan bahwa inspector yang didorong oleh checklist menemukan defect yang dilewati oleh reviewer yang didorong oleh intuisi, bukan karena para ahli ceroboh, tetapi karena keahlian menciptakan blind spot.

Berikut adalah checklist lightweight untuk satu fungsi Python:

CHECKLIST = [
    "Can a non-author paraphrase what this function does in one sentence?",
    "Does every execution path return or raise predictably?",
    "What happens at the minimum and maximum valid inputs?",
    "What happens at exactly one step past the boundary?",
    "Does the function mutate any argument, closure, or global state?",
    "Is every resource acquired also released on the error path?",
    "If this raises, can the caller distinguish recoverable from fatal?",
]

Ini bukan birokrasi. Ini adalah forcing function untuk perhatian sistematis.

Fagan Membagi Inspeksi Menjadi Empat Fase, dan Meeting Adalah yang Terpendek

Sebuah Fagan Inspection yang nyata memiliki empat fase, dan meeting itu sendiri adalah yang terpendek.

Preparation. Setiap inspector meninjau materi sendirian, dengan checklist, sebelum grup bertemu. Fagan menemukan bahwa inspector yang telah mempersiapkan diri menemukan kira-kira dua kali lebih banyak defect dibandingkan mereka yang datang tanpa persiapan. Meeting ada hanya untuk menggabungkan temuan, bukan untuk menghasilkannya.

Meeting. Reader membahas kode. Tester mengajukan pertanyaan what-if. Moderator menjaganya di bawah dua jam. Author mencatat. Tidak ada yang memperbaiki kode selama meeting. Defect dicatat dan grup melanjutkan.

Rework. Author memperbaiki defect yang dicatat sendirian.

Follow-up. Moderator memverifikasi setiap defect telah ditangani. Rework besar dapat memicu inspeksi kedua.

Struktur ini terasa berat untuk pull request modern. Fagan merancangnya untuk software mainframe di mana satu defect dapat memiliki biaya jutaan dolar. Prinsip-prinsipnya masih dapat diadaptasi untuk konteks yang lebih kecil.

Di Mana Ini Menjadi Berlebihan

Fagan Inspection tidak gratis. Waktu preparation saja menambahkan overhead yang signifikan. Untuk bugfix sepuluh baris, Fagan Inspection penuh adalah tidak masuk akal. Anda tidak membutuhkan empat orang dan sebuah checklist untuk menemukan import yang hilang.

Kurva payoff tidak linear. Data Fagan menunjukkan bahwa inspeksi paling menguntungkan untuk module yang kompleks dan berisiko tinggi: state machine, parser, resource manager, apa pun dengan non-local state atau ordering constraint yang halus. Untuk handler CRUD dan test boilerplate, review informal sudah cukup baik.

Kesalahan sebenarnya adalah menerapkan strategi review yang sama untuk setiap perubahan. Typo di pesan log tidak memerlukan Fagan Inspection. Sebuah distributed transaction coordinator mungkin memerlukannya.

Versi Lightweight yang Dapat Anda Gunakan Hari Ini

Anda tidak membutuhkan budaya meeting IBM untuk mendapatkan sebagian besar manfaatnya. Berikut adalah adaptasi lightweight yang berfungsi untuk tim modern:

  1. Mewajibkan review individual sebelum diskusi grup. Setiap reviewer mengirimkan komentar tertulis sebelum ada yang berbicara. Ini mencegah opini pertama yang keras mendominasi.

  2. Mengrotasi peran reader. Minta salah satu reviewer untuk merangkum perubahan dengan kata-kata mereka sendiri sebelum ada yang mengkritiknya. Jika mereka tidak bisa, perubahannya terlalu besar atau terlalu tidak jelas.

  3. Membangun checklist tim. Mulai dengan tujuh pertanyaan di atas. Tambahkan item spesifik domain. Tinjau kembali setiap tiga bulan.

  4. Memisahkan author dan defender. Author menjawab pertanyaan faktual. Mereka tidak berdebat bahwa kode tersebut baik-baik saja. Jika reviewer bingung, itu adalah data, bukan perdebatan.

  5. Mencatat defect, memperbaikinya nanti. Jangan tulis ulang kode selama review. Catat issue-nya, selesaikan, lalu perbaiki.

Berikut adalah skrip sederhana untuk menghasilkan review checklist untuk setiap module Python:

import ast
import sys
from pathlib import Path

def generate_checklist(source_path: str) -> list[str]:
    """Generate a Fagan-style checklist from a Python module."""
    source = Path(source_path).read_text()
    tree = ast.parse(source)

    checklist = [
        f"Module {Path(source_path).name}: {len(tree.body)} top-level statements",
        "Can a non-author state the module's responsibility in one sentence?",
    ]

    for node in ast.walk(tree):
        if isinstance(node, ast.FunctionDef):
            checklist.append(
                f"Function '{node.name}': does every path return or raise?"
            )
            if any(isinstance(n, ast.Try) for n in ast.walk(node)):
                checklist.append(
                    f"Function '{node.name}': is every exception handled explicitly?"
                )

    return checklist

if __name__ == "__main__":
    for item in generate_checklist(sys.argv[1]):
        print(f"[ ] {item}")

Jalankan seperti ini:

python inspection_checklist.py src/transaction.py

Ini tidak akan menemukan bug Anda. Ini memaksa Anda untuk melihat di tempat yang benar.

Merekrut Orang yang Lebih Cerdas Tidak Akan Memperbaiki Masalah Proses

Penelitian Fagan hampir berusia lima puluh tahun, tetapi temuannya tidak berubah. Reviewer individual tidak konsisten. Grup juga tidak konsisten, kecuali Anda menyusunnya. Varians antar reviewer bukanlah masalah yang harus dieliminasi. Ini adalah sumber daya yang harus diatur.

Lain kali satu reviewer menemukan bug yang dilewatkan oleh reviewer lain, jangan tanyakan siapa yang lebih baik. Tanyakan apakah proses Anda cukup terstruktur untuk menggabungkan apa yang keduanya lihat. Fagan sudah mencoba merekrut keluar dari masalah ini. Itu tidak berhasil.

FAQ

Apa itu Fagan Inspection?

Fagan Inspection adalah proses code review formal dan terstruktur yang dikembangkan oleh Michael Fagan di IBM pada 1976. Ini menggunakan peran yang ditentukan (moderator, reader, tester, author), persyaratan preparation, dan checklist untuk memaksimalkan deteksi defect dalam artefak software.

Mengapa reviewer yang berbeda menemukan bug yang berbeda?

Perhatian manusia selektif. Para ahli mengembangkan shortcut mental yang memungkinkan mereka membaca kode dengan cepat, tetapi shortcut yang sama menciptakan blind spot. Reviewer yang berbeda memiliki latar belakang dan pola kognitif yang berbeda, sehingga blind spot mereka tidak tumpang tindih secara sempurna. Penelitian Fagan menunjukkan bahwa nilai inspeksi berasal dari menggabungkan berbagai perspektif yang tidak lengkap, bukan dari menemukan satu reviewer yang sempurna.

Apakah Fagan Inspection masih digunakan saat ini?

Proses formal lengkap jarang di luar industri yang kritis untuk keselamatan seperti aerospace dan perangkat medis. Namun, prinsip-prinsip dasarnya — preparation individual, pemisahan peran, dan review yang didorong oleh checklist — semakin diadopsi oleh tim software high-performing. Ide-ide inti juga mempengaruhi praktik modern seperti structured walkthroughs dan formal technical reviews.

Kapan overhead Fagan Inspection penuh sepadan?

Untuk module di mana defect memiliki konsekuensi yang parah: logika distributed consensus, security boundary, resource lifecycle, dan state machine. Untuk perubahan rutin, adaptasi lightweight biasanya sudah cukup. Cocokkan rigor review dengan risiko aktual, bukan proses yang sama untuk setiap diff.