One PR, One Purpose #
One PR, One Purpose adalah prinsip dalam software engineering yang menyarankan bahwa satu Pull Request (PR) seharusnya hanya memiliki satu tujuan utama yang jelas.
Artinya:
- Satu PR fokus pada satu perubahan logis
- Tidak mencampur berbagai konteks yang berbeda dalam satu PR
- Reviewer dapat memahami why dan what dari PR tersebut tanpa kebingungan
Contoh:
- ✅ PR untuk menambah validasi input pada endpoint login
- ❌ PR yang berisi refactor auth, ubah UI, update dependency, dan fix bug random sekaligus
Prinsip ini bukan soal ukuran baris kode semata, tapi soal kejelasan niat (intent) dari perubahan.
Dasar Berpikir: Kenapa Satu PR Harus Punya Satu Tujuan? #
PR Adalah Media Komunikasi, Bukan Sekadar Pengiriman Kode #
Pull Request bukan hanya alat untuk merge code, tapi:
- Media diskusi teknis
- Media transfer konteks
- Media audit perubahan
Jika satu PR memiliki banyak tujuan, maka pesan yang ingin disampaikan menjadi kabur.
Otak Manusia Membaca Konteks, Bukan Diff #
Reviewer tidak membaca baris per baris seperti compiler. Mereka mencoba memahami:
- Masalah apa yang ingin diselesaikan?
- Kenapa solusi ini dipilih?
- Apa dampak perubahan ini?
Ketika satu PR berisi banyak tujuan:
- Beban kognitif meningkat
- Reviewer cepat lelah
- Review menjadi dangkal atau sekadar LGTM
Perubahan Seharusnya Bisa Dijelaskan dalam Satu Kalimat #
Ciri PR yang sehat:
“PR ini dibuat untuk X”
Jika Anda butuh paragraf panjang untuk menjelaskan tujuan PR, kemungkinan besar PR tersebut sudah terlalu banyak isi.
Kenapa One PR, One Purpose Itu Penting? #
Review Lebih Cepat dan Lebih Berkualitas #
PR yang fokus:
- Lebih cepat dipahami
- Diskusi lebih tajam
- Feedback lebih relevan
Reviewer bisa benar-benar memikirkan kualitas solusi, bukan sibuk memilah konteks.
Risiko Bug dan Regressi Lebih Rendah #
Jika PR hanya punya satu tujuan:
- Dampak perubahan lebih terisolasi
- Lebih mudah dites
- Lebih mudah di-rollback jika terjadi masalah
Bandingkan:
- Revert 1 PR kecil ❌
- Revert 1 PR besar yang menyentuh banyak area ❌❌❌
Git History Lebih Bersih dan Bermakna #
Git log yang baik adalah dokumentasi hidup.
Dengan PR yang fokus:
- Setiap commit / PR punya cerita jelas
- Mudah melakukan blame atau bisect
- Mudah memahami evolusi sistem
CI/CD dan Testing Lebih Terpercaya #
PR dengan satu tujuan:
- Test failure lebih mudah dilacak
- Root cause lebih cepat ditemukan
- Pipeline tidak menjadi noise generator
Membentuk Budaya Engineering yang Dewasa #
Prinsip ini secara tidak langsung melatih engineer untuk:
- Berpikir terstruktur
- Memecah masalah besar menjadi bagian kecil
- Menghargai waktu reviewer
Ini bukan sekadar aturan teknis, tapi nilai profesionalisme.
Best Practice Menerapkan One PR, One Purpose #
Definisikan Tujuan PR Sebelum Menulis Kode #
Sebelum coding, jawab satu pertanyaan:
“Perubahan apa yang ingin saya kirimkan lewat PR ini?”
Jika jawabannya lebih dari satu, pertimbangkan memecahnya.
Pisahkan Refactor dari Perubahan Perilaku #
Aturan emas:
- Refactor saja → PR sendiri
- Feature / bug fix → PR sendiri
Kenapa?
- Refactor mengubah struktur
- Feature/bug fix mengubah perilaku
Mencampur keduanya menyulitkan review dan debugging.
Jangan Campur Housekeeping dengan Perubahan Fungsional #
Contoh housekeeping:
- Formatting
- Rename variabel massal
- Update dependency
- Reorganisasi folder
Jika tidak berkaitan langsung dengan tujuan PR, keluarkan dari PR tersebut.
Gunakan Branch dan PR Secara Disiplin #
Praktik yang disarankan:
- Satu branch → satu PR → satu tujuan
- Hindari long-lived branch yang isinya bercampur
Branch adalah alat isolasi, manfaatkan sepenuhnya.
PR Kecil Lebih Baik daripada PR Besar #
Tidak ada ukuran pasti, tapi guideline umum:
- Reviewer masih nyaman membaca PR dalam sekali duduk
- Perubahan masih bisa dipahami tanpa context switching
Jika PR terasa berat untuk direview, kemungkinan sudah melanggar prinsip ini.
Tulis Judul dan Deskripsi PR yang Tegas #
Judul PR yang baik:
- Menyebutkan tujuan, bukan sekadar aksi
Contoh:
- ❌ “Update auth service”
- ✅ “Fix token refresh logic to prevent premature logout”
Deskripsi PR seharusnya memperkuat satu tujuan tersebut, bukan menambahkan tujuan baru.
Jika Terlanjur Besar, Jangan Takut Memecah PR #
Memecah PR:
- Bukan tanda kegagalan
- Justru tanda kedewasaan engineering
Lebih baik terlambat sedikit daripada mewariskan PR sulit dipahami ke tim.
Penutup #
One PR, One Purpose bukan aturan kaku, tapi prinsip yang membantu tim:
- Bekerja lebih rapi
- Berkomunikasi lebih jelas
- Mengurangi risiko jangka panjang
Jika tim Anda sering menghadapi:
- PR lama tidak direview
- Review asal-asalan
- Bug yang sulit dilacak
Besar kemungkinan masalahnya bukan di orangnya, tapi di cara kita mengemas perubahan.
Mulailah dari satu hal sederhana:
Satu PR. Satu tujuan. Selesai dengan baik.