Code Review

Tidak ada satu penulis kode pun yang melihat kesalahannya sendiri dengan jelas — otak kita sudah tahu maksud kode itu, jadi mata membaca apa yang seharusnya ada, bukan apa yang sebenarnya tertulis. Code review menghadirkan pasangan mata kedua: rekan tim membaca perubahan Anda sebelum merge, mencari cacat, dan — sama pentingnya — mempelajari bagian sistem yang belum sentuh. Chapter ini membahas praktik review yang sehat: apa yang diperiksa, bagaimana memberi dan menerima umpan balik, dan mengapa PR kecil adalah fondasi semuanya.

Untuk Apa Review Sebenarnya #

Review yang buruk terasa seperti gerbang tol: pemeriksa mencari alasan menolak, penulis bertahan, keduanya kalah waktu. Review yang sehat bekerja sebaliknya:

Review sebagai gerbang	Review sebagai kolaborasi
tujuannya menemukan kesalahan penulis	tujuannya menghasilkan kode terbaik
pengetahuan tetap di kepala pemeriksa	pengetahuan menyebar ke seluruh tim
penulis merasa diadili	penulis belajar pola baru
ditunda sampai akhir sprint	singkat, rutin, berkecepatan tinggi

Sisi berbagi pengetahuan ini bukan bonus — anggota tim baru paling cepat belajar arsitektur proyek lewat review PR orang lain.

Checklist Review #

Periksa tiap PR dengan urutan yang sama agar tidak ada aspek yang terlewat. Checklist ringkas:

Aspek	Pertanyaan kunci
Correctness	apakah logika benar untuk kasus batas (list kosong, nilai `None`, angka nol)?
Test	apakah perubahan diiringi test yang gagal bila kode ini salah?
Naming	apakah nama `total_belanja` dan `hitung_diskon` menjelaskan isinya?
Error handling	apakah exception yang bisa terjadi sudah ditangani atau didelegasikan sadar?
Security	apakah ada `eval()` berbahaya, query string mentah, atau secret yang ikut tercommit?
Complexity	apakah ada function 40 baris atau percabangan bersarang tiga tingkat yang layak dipecah?

Daftar ini bukan formulir bakar lampu. Reviewer yang baik membaca diff sambil mengecek mental: “kalau saya yang memanggil function ini dengan input jahat, apa yang terjadi?”

Mesin Dulu, Manusia Kemudian #

Waktu reviewer adalah sumber daya paling mahal di proses ini — jangan habiskan untuk hal yang bisa dicek mesin. Sebelum PR sampai ke rekan tim, jalankan dulu pemeriksaan otomatis. Chapter Linting dan Formatting membahas ruff secara mendalam; di sini kita cukup melihat sikap pemakaiannya. Untuk file pesanan.py beserta test-nya:

python
"""Menghitung total pesanan."""


def total_pesanan(harga_satuan: list[float], pajak: float = 0.11) -> float:
    """Hitung total pesanan termasuk pajak."""
    return sum(harga_satuan) * (1 + pajak)

Dan file test-nya, test_pesanan.py:

python
from pesanan import total_pesanan


def test_total_dengan_pajak_default():
    assert total_pesanan([10_000, 5_000]) == 16_650.0


def test_total_tanpa_pajak():
    assert total_pesanan([10_000, 5_000], pajak=0) == 15_000.0

Dua perintah, dua sinyal:

bash

ruff check .
python3 -m pytest -q

Output yang Dihasilkan:

text

All checks passed!

text

..                                                                       [100%]
2 passed in 0.12s

Dua titik pada baris pertama berarti dua test lulus — durasinya bervariasi antar mesin. Setelah linter dan test hijau, energi manusia bisa difokuskan pada hal yang tidak bisa dijalankan mesin: apakah pendekatan ini tepat, apakah nama pas, apakah ada kasus batas yang terlewat.

Memberi Umpan Balik #

Kode dinilai, penulis dihormati. Bedanya tajam sekali di dua contoh ini:

text

Sloppy banget, kayaknya lo gak baca style guide.

text

Function hitung_diskon() mengabaikan diskon member di atas
Rp500.000. Bagaimana kalau cek BATAS_DISKON sebelum tarif?

Komentar pertama menyerang orang dan tidak bisa ditindaklanjuti. Komentar kedua menyebut objek konkret (hitung_diskon(), BATAS_DISKON), menjelaskan masalah, lalu menawarkan arah — penulis bebas menyetujui atau membantah dengan alasan. Etika praktisnya:

Prinsip	Wujudnya
Bicarakan kode, bukan orang	“cabang ini sulit diikuti”, bukan “kok kamu nulis begini”
Sarankan, jangan komando	“bagaimana kalau ekstrak function?” bukan “refactor ini”
Puji pola yang baik	“pemakaian dataclass di sini rapi sekali”
Beri alasan, bukan selera	“Pylint menandai ini” atau “kasus list kosong akan gagal”, bukan “aku kurang suka”
Bedakan blocker dan saran	“wajib: cek None” vs “opsional: boleh diganti constant”

Saran dan blocker yang berbeda label membuat penulis tahu mana yang menahan merge dan mana yang cuma ide.

Menerima Umpan Balik, PR Kecil, dan Self-Review #

Sisi penerima punya tugas: baca semua komentar, jawab dengan alasan bila tidak setuju, dan jangan menganggap kritik sebagai penilaian pribadi. Pertanyaan yang tepat untuk tiap komentar adalah “apa yang bisa saya pelajari dari sudut pandang ini?” — bukan “bagaimana membela kode saya?”

Dua kebiasaan terakhir menaikkan mutu seluruh proses. Pertama, PR kecil: perubahan 60 baris direview teliti dalam sepuluh menit; 600 baris di-skip sambil lalu. Kecilkan cakupan PR sampai reviewer nyaman menelusurinya baris per baris. Kedua, self-review sebelum menugaskan reviewer: buka diff Anda sendiri, baca seperti orang asing, perbaiki yang jelas (debug print, komentar usang, file tercampur). Reviewer yang selalu menerima diff bersih akan membalas dengan review yang juga teliti — standar itu menular.

Review adalah tempat keputusan desain diuji bersama. Untuk prinsip desain yang lebih besar — SOLID hingga coupling — lanjutkan ke Chapter Design Principles.