Komuniti pembangunan perisian sedang terlibat dalam perdebatan hangat mengenai saiz dan struktur optimum bagi pull request ( PR ), yang dicetuskan oleh cadangan daripada ceramah persidangan baru-baru ini yang menyokong semakan kod yang lebih kecil dan didorong oleh cerita.
 |
|---|
| Seorang penceramah berinteraksi dengan penonton di persidangan mengenai strategi pull request |
Standard Semakan 5-10 Minit
Pergerakan yang semakin berkembang mencadangkan bahawa pull request sepatutnya boleh disemak dalam masa hanya 5-10 minit, dengan perubahan terhad kepada sekitar 300 baris kod. Penyokong berhujah pendekatan ini membawa kepada semakan berkualiti tinggi dan kitaran pembangunan yang lebih pantas. Mereka percaya bahawa apabila perubahan adalah kecil dan tertumpu, pengulas boleh memberikan maklum balas yang lebih berfikiran daripada sekadar mengesahkan penyerahan yang besar dan kompleks dengan mudah menggunakan Looks Good To Me ( LGTM ).
Walau bagaimanapun, ramai pembangun berpengalaman menentang pendekatan yang tegar ini. Mereka berhujah bahawa memecahkan ciri-ciri kepada bahagian-bahagian kecil secara buatan sebenarnya boleh menjadikan semakan lebih sukar dengan mengaburkan gambaran yang lebih besar dan mewujudkan kerumitan yang tidak perlu dalam menguruskan pelbagai perubahan yang saling bergantung.
Garis Panduan PR yang Disyorkan:
- Saiz: 300 baris kod (500+ baris dianggap tidak boleh disemak)
- Masa semakan: 5-10 minit untuk penyemak biasa
- Struktur commit: 13 commit untuk 152 baris perubahan kod (contoh kes)
- Fokus: Maksimum satu perubahan kontroversi setiap PR
Kontroversi Cerita Commit
Satu lagi perkara yang menimbulkan perbalahan melibatkan penghasilan commit yang menceritakan cerita yang koheren tentang bagaimana kod berkembang. Penyokong mencadangkan bahawa setiap commit sepatutnya mewakili langkah logik dalam proses pembangunan, menjadikannya lebih mudah bagi pengulas untuk mengikuti proses pemikiran pembangun. Pendekatan ini menganggap commit sebagai bab dalam buku, setiap satu membina berdasarkan yang sebelumnya.
Pengkritik mendapati amalan ini memakan masa dan mempersoalkan nilai dunia sebenarnya. Ramai pembangun melaporkan bahawa pengulas jarang membaca mesej commit individu semasa semakan PR , menjadikan usaha untuk mencipta cerita commit yang sempurna terasa seperti pembaziran masa.
Tiada siapa yang membaca mesej commit perantaraan satu demi satu pada PR , sudah pasti. Saya bekerja dalam pasukan di mana ketua sangat berkeras tentang perkara ini dan mula menulis mesej dalam nada 'jika anda membaca mesej ini, saya akan beri anda lima dolar'. Saya tidak pernah membayar sesiapa pun satu dolar.
Alat Pembangunan Alternatif:
- Jujutsu (jj): Sistem kawalan versi yang direka untuk cawangan bertindan
- Graphite: Alat untuk menguruskan PR bertindan di atas Git
- Git-branchless: Sambungan untuk pengurusan cawangan yang lebih baik
- Sapling: Sistem kawalan versi Meta dengan sokongan timbunan
Semakan Kendiri sebagai Penyelesaian
Satu bidang di mana pembangun nampaknya mendapat lebih banyak persetujuan ialah amalan menyemak sendiri pull request sebelum menyerahkannya. Ramai melaporkan bahawa menambah komen dan penjelasan mereka sendiri kepada PR meningkatkan pengalaman semakan dengan ketara bagi rakan sekerja mereka. Pendekatan ini membantu menangkap pepijat awal dan memberikan konteks penting yang mungkin tidak jelas daripada kod sahaja.
Semakan kendiri juga menangani kebimbangan yang semakin meningkat tentang penyerahan kod yang dijana oleh AI , di mana pembangun mungkin tidak memahami sepenuhnya perubahan yang mereka cadangkan. Dengan memaksa pengarang memeriksa kerja mereka sendiri secara kritikal, pasukan boleh mengekalkan kualiti kod walaupun amalan pembangunan berkembang.
Amalan Terbaik Semakan Kendiri:
- Tambahkan komen penjelasan sebelum meminta semakan
- Gunakan sistem komen GitHub / GitLab untuk memberikan konteks
- Terangkan keputusan kod yang tidak jelas secara sebaris
- Sertakan bukti ujian dan rasional pendekatan
- Tangani soalan pengkaji semak yang berpotensi secara proaktif
Cabaran Peralatan
Perdebatan ini mendedahkan geseran yang ketara dengan alat pembangunan semasa, terutamanya antara muka Git dan GitHub untuk menyemak commit secara individu. Ramai pembangun yang ingin mencipta sejarah commit yang lebih baik mendapati diri mereka bergelut dengan alat yang tidak direka untuk aliran kerja ini. Sistem kawalan versi alternatif seperti Jujutsu dan alat khusus seperti Graphite sedang muncul untuk menangani batasan ini.
Perbincangan ini menyerlahkan ketegangan asas dalam pembangunan perisian moden antara bergerak pantas dan mengekalkan kualiti. Walaupun tiada penyelesaian universal, komuniti nampaknya bersetuju bahawa kunci terletak pada menyesuaikan amalan untuk memenuhi keperluan pasukan daripada mengikut secara tegar mana-mana pendekatan tunggal. Pasukan yang paling berjaya nampaknya adalah mereka yang mengutamakan komunikasi yang jelas dan saling menghormati berbanding mematuhi had saiz PR atau format mesej commit yang ketat.