Career
Code Review yang Benar-benar Berfungsi: Panduan Proses untuk Developer
Februari 202610 menit baca
Career
Penelitian rekayasa Google menemukan bahwa meninjau lebih dari 200–400 baris kode sekaligus secara tajam mengurangi tingkat deteksi cacat. Begitu PR melampaui 400 baris, reviewer kehilangan fokus dan cenderung melakukan rubber-stamping daripada menemukan bug nyata. PR yang kecil juga lebih mudah di-revert ketika ada yang salah.
Artikel ini merekomendasikan dekomposisi pekerjaan dalam lapisan: PR pertama mencakup model data dan migrasi, kedua lapisan API dan tes, ketiga logika layanan, dan keempat UI. Setiap PR dapat di-merge secara independen di belakang feature flag, sehingga tim bisa menggabungkan fitur yang belum selesai tanpa merilis ke pengguna, sekaligus memungkinkan developer kedua mulai mengerjakan lapisan berikutnya sementara PR pertama masih dalam review.
Gaya, lint, dan format sebaiknya ditangani oleh pre-commit hook dan CI, sehingga reviewer manusia dapat fokus pada hal-hal yang tidak bisa ditangkap otomatisasi: kebenaran logika, kasus tepi (input kosong, nilai null, permintaan bersamaan), keamanan (validasi input, pemeriksaan izin), kinerja (skala kueri, risiko N+1), dan keterpeliharaan jangka panjang. Komentar gaya harus diberi awalan 'nit:' untuk menandainya sebagai non-blocking agar tidak mengalihkan perhatian dari isu yang lebih penting.
Waktu siklus PR — waktu yang berlalu sejak pull request dibuka hingga di-merge — adalah metrik utama yang direkomendasikan karena mencakup kecepatan review, ukuran PR, dan jumlah iterasi review yang diperlukan sekaligus. Artikel ini menargetkan di bawah 24 jam untuk pekerjaan prioritas P2 dan di bawah 4 jam untuk perbaikan mendesak, serta memperingatkan agar tidak melacak jumlah review per individu karena dapat menciptakan insentif yang menyimpang.
Ketika developer senior meninggalkan review yang bijaksana yang menjelaskan mengapa pendekatan tertentu lebih baik, penjelasan itu tersimpan secara permanen dalam komentar PR dan tetap dapat diakses oleh anggota tim masa depan yang membaca riwayat git kode tersebut. Artikel ini mendorong untuk mengajukan pertanyaan ('mengapa kamu memilih pendekatan ini dibanding X?') daripada sekadar menuntut perubahan, karena pertanyaan dapat mengungkap alasan penulis dan sering kali mengungkap kesalahpahaman dari kedua sisi.
Penelitian rekayasa Google menemukan bahwa meninjau lebih dari 200-400 baris kode sekaligus secara tajam mengurangi tingkat deteksi cacat. Namun PR rata-rata di sebagian besar tim melebihi 400 baris — dan komentar review sering kali hanya 'LGTM' setelah pemindaian sepintas. Studi menunjukkan bahwa alat code review AI memotong waktu review PR rata-rata dari 2-3 jam menjadi 20-30 menit. Angka-angka ini menunjuk pada kebenaran yang mendasari yang sama: sebagian besar tim memiliki proses code review yang terlihat ketat tetapi sebenarnya tidak.
Datanya jelas: deteksi cacat turun drastis begitu PR melampaui 400 baris kode yang diubah. Reviewer kehilangan fokus, melewatkan konteks, dan mulai rubber-stamping. PR kecil (di bawah 300 baris) mendapatkan review yang lebih bijaksana, merge lebih cepat, dan lebih mudah untuk di-revert ketika ada yang salah.
Fitur besar tidak harus berarti PR besar. Dekomposisi pekerjaan dalam lapisan: PR pertama adalah model data dan migrasi; kedua adalah lapisan API dan tes; ketiga adalah logika layanan; keempat adalah UI. Setiap PR dapat di-deploy (atau setidaknya di-merge) di belakang feature flag secara independen.
Code Review Process — Healthy Team Flow
Feature Planning
│
┌────▼────────────────────────────────────────────────┐
│ Break feature into reviewable PRs (< 400 LOC) │
│ │
│ PR 1: Data model + migration │
│ PR 2: API routes + validation │
│ PR 3: Business logic + unit tests │
│ PR 4: UI components │
└────┬────────────────────────────────────────────────┘
│
┌────▼────────────────────────────────────────────────┐
│ PR Description: │
│ ✓ What changed (one sentence) │
│ ✓ Why it changed (business reason) │
│ ✓ What I tested │
│ ✓ What is NOT in scope (explicit) │
└────┬────────────────────────────────────────────────┘
│
┌────▼────────────────────────────────────────────────┐
│ Reviewer Checklist (NOT style): │
│ □ Architecture fit │
│ □ Business logic correctness │
│ □ Error handling completeness │
│ □ Security: inputs validated, permissions checked │
│ □ Performance: indexes, N+1 risk │
│ □ Tests cover critical paths │
└────┬────────────────────────────────────────────────┘
│
Target: < 24h review turnaround, < 2 review cyclesDari proses pengembangan saya untuk modul ERP Commsult: tulis deskripsi PR seolah Anda menjelaskan perubahan kepada anggota tim yang baru bangun tanpa konteks. Sertakan: apa yang berubah, mengapa berubah (alasan bisnis, bukan hanya alasan teknis), apa yang Anda uji, dan apa yang Anda tidak ubah jika ruang lingkupnya bisa ambigu.
Code review yang efektif bukan tentang masalah gaya — itulah yang dilakukan linter. Otomatiskan pemeriksaan gaya, lint, dan format dengan pre-commit hook dan CI. Cadangkan kapasitas review manusia untuk hal-hal yang tidak dapat ditangkap otomatisasi: kebenaran, kasus tepi, keamanan, kinerja, dan keterpeliharaan.
## PR Description Template (.github/pull_request_template.md)
### What changed
<!-- One sentence. What does this PR do? -->
### Why it changed
<!-- Business reason, not technical reason.
"Feature X required by finance team" not "added new endpoint" -->
### What I tested
<!-- Describe what you tested manually + what automated tests cover this -->
### Out of scope
<!-- Explicit list of what is NOT in this PR to prevent scope confusion -->
### Documentation
- [ ] I have updated README/API docs for this change
- [ ] New environment variables are in .env.example
- [ ] Database changes are documented in migration file
### Review checklist for reviewer
- [ ] Logic is correct (matches requirements)
- [ ] Error paths are handled
- [ ] No obvious security issues (inputs validated, auth checked)
- [ ] Performance: no N+1 queries, new queries have indexes
- [ ] Tests cover the new behaviorKembangkan checklist mental (atau literal) untuk review: Arsitektur — apakah ini sesuai dengan pola yang ada? Kebenaran — apakah kode cocok dengan persyaratan? Penanganan error — apakah semua jalur error ditangani? Pengujian — apakah jalur kritis tercakup oleh tes? Keamanan — apakah input pengguna divalidasi? Apakah izin diterapkan? Kinerja — apakah kueri database diindeks? Adakah risiko kueri N+1?
Code review di mana setiap komentar adalah preferensi gaya ('Saya akan menggunakan const di sini', 'ganti nama variabel ini menjadi X') bukan review yang berguna — itu adalah micromanagement yang merusak semangat penulis dan melewatkan bug nyata. Awali komentar gaya dengan 'nit:' untuk menandainya sebagai non-blocking. Lebih baik: setujui panduan gaya yang diterapkan oleh ESLint dan Prettier, dan jangan pernah lagi memunculkan masalah gaya dalam code review.
Umpan balik yang cepat menjaga aliran developer tetap tinggi. Pedoman rekayasa merekomendasikan merespons setiap permintaan review dalam satu hari kerja — idealnya dalam beberapa jam. PR yang duduk tidak ditinjau selama tiga hari merusak semangat penulis dan menciptakan konflik merge saat kode lain mendarat.
Code review adalah salah satu mekanisme transfer pengetahuan yang paling berdampak di sebuah tim. Ketika developer senior meninggalkan review yang bijaksana yang menjelaskan mengapa pendekatan tertentu lebih baik, pengetahuan itu tetap ada dalam komentar PR secara permanen — dapat diakses oleh anggota tim masa depan mana pun yang melihat riwayat git kode tersebut.
Ukur waktu siklus PR (waktu dari PR dibuka hingga di-merge) sebagai metrik utama Anda. Target di bawah 24 jam untuk P2 dan di bawahnya, di bawah 4 jam untuk perbaikan mendesak. Lacak densitas komentar review per 100 baris — sangat rendah berarti rubber-stamping; sangat tinggi berarti perang gaya. Lacak tingkat pengerjaan ulang — persentase PR yang memerlukan lebih dari 2 siklus review.