Komunitas pengembangan perangkat lunak sedang terlibat dalam perdebatan sengit tentang ukuran dan struktur optimal dari pull request (PR), yang dipicu oleh rekomendasi dari presentasi konferensi terbaru yang mengadvokasi code review yang lebih kecil dan berbasis cerita.
 |
|---|
| Seorang pembicara yang melibatkan audiens dalam konferensi tentang strategi pull request |
Standar Review 5-10 Menit
Sebuah gerakan yang berkembang menyarankan bahwa pull request seharusnya dapat direview hanya dalam 5-10 menit, dengan perubahan dibatasi sekitar 300 baris kode. Para pendukung berargumen bahwa pendekatan ini menghasilkan review berkualitas tinggi dan siklus pengembangan yang lebih cepat. Mereka percaya bahwa ketika perubahan kecil dan terfokus, reviewer dapat memberikan feedback yang lebih thoughtful daripada sekadar menyetujui submission besar dan kompleks dengan sederhana Looks Good To Me (LGTM).
Namun, banyak developer berpengalaman menolak pendekatan yang kaku ini. Mereka berargumen bahwa membagi fitur secara artifisial menjadi potongan-potongan kecil sebenarnya dapat membuat review lebih sulit dengan mengaburkan gambaran besar dan menciptakan kompleksitas yang tidak perlu dalam mengelola beberapa perubahan yang saling bergantung.
Pedoman PR yang Direkomendasikan:
- Ukuran: 300 baris kode (500+ baris dianggap tidak dapat direview)
- Waktu review: 5-10 menit untuk reviewer rata-rata
- Struktur commit: 13 commit untuk 152 baris perubahan kode (contoh kasus)
- Fokus: Maksimal satu perubahan kontroversial per PR
Kontroversi Commit Story
Poin kontroversial lainnya melibatkan pembuatan commit yang menceritakan kisah koheren tentang bagaimana kode berkembang. Para advokat menyarankan bahwa setiap commit harus mewakili langkah logis dalam proses pengembangan, membuatnya lebih mudah bagi reviewer untuk mengikuti proses berpikir developer. Pendekatan ini memperlakukan commit sebagai bab dalam sebuah buku, masing-masing membangun di atas yang sebelumnya.
Para kritikus menganggap praktik ini memakan waktu dan mempertanyakan nilai dunia nyatanya. Banyak developer melaporkan bahwa reviewer jarang membaca pesan commit individual selama PR review, membuat upaya untuk membuat commit story yang sempurna terasa seperti membuang waktu.
Tidak ada yang membaca pesan commit menengah satu per satu pada PR, titik. Saya bekerja di tim di mana lead sangat bersikeras tentang ini dan mulai menulis pesan dengan nada 'jika kamu membaca pesan ini, saya akan memberimu $5'. Saya tidak pernah membayar siapa pun satu dolar.
Alat Pengembangan Alternatif:
- Jujutsu (jj): Sistem kontrol versi yang dirancang untuk stacked branches
- Graphite: Alat untuk mengelola stacked PR di atas Git
- Git-branchless: Ekstensi untuk manajemen branch yang lebih baik
- Sapling: Sistem kontrol versi Meta dengan dukungan stack
Self-Review sebagai Solusi
Satu area di mana developer tampaknya menemukan lebih banyak kesepakatan adalah praktik self-review pull request sebelum mengirimkannya. Banyak yang melaporkan bahwa menambahkan komentar dan penjelasan mereka sendiri ke PR secara signifikan meningkatkan pengalaman review untuk rekan-rekan mereka. Pendekatan ini membantu menangkap bug lebih awal dan memberikan konteks penting yang mungkin tidak jelas dari kode saja.
Self-review juga mengatasi kekhawatiran yang berkembang tentang submission kode yang dihasilkan AI, di mana developer mungkin tidak sepenuhnya memahami perubahan yang mereka usulkan. Dengan memaksa penulis untuk memeriksa pekerjaan mereka sendiri secara kritis, tim dapat mempertahankan kualitas kode bahkan ketika praktik pengembangan berkembang.
Praktik Terbaik Self-Review:
- Tambahkan komentar penjelasan sebelum meminta review
- Gunakan sistem komentar GitHub / GitLab untuk memberikan konteks
- Jelaskan keputusan kode yang tidak jelas secara inline
- Sertakan bukti pengujian dan alasan pendekatan
- Atasi pertanyaan potensial reviewer secara proaktif
Tantangan Tooling
Perdebatan ini mengungkapkan friksi signifikan dengan tools pengembangan saat ini, khususnya antarmuka Git dan GitHub untuk mereview commit secara individual. Banyak developer yang ingin menciptakan riwayat commit yang lebih baik menemukan diri mereka berjuang melawan tools yang tidak dirancang untuk workflow ini. Sistem version control alternatif seperti Jujutsu dan tools khusus seperti Graphite muncul untuk mengatasi keterbatasan ini.
Diskusi ini menyoroti ketegangan fundamental dalam pengembangan perangkat lunak modern antara bergerak cepat dan mempertahankan kualitas. Meskipun tidak ada solusi universal, komunitas tampaknya setuju bahwa kuncinya terletak pada mengadaptasi praktik untuk memenuhi kebutuhan tim daripada mengikuti secara kaku pendekatan tunggal apa pun. Tim yang paling sukses tampaknya adalah mereka yang memprioritaskan komunikasi yang jelas dan saling menghormati daripada kepatuhan ketat pada batas ukuran PR tertentu atau format pesan commit.
Referensi: The Theatre of Pull Requests and Code Review