दावा: आदर्श PR 50 पंक्तियों का होता है
इस दावे कि “आदर्श” pull request लगभग 50 कोड पंक्तियों का होता है, और यह तेज़ मर्ज तथा कम रिवर्ट जैसे मेट्रिक्स पर आधारित है, ने इस पर बहस छेड़ दी है कि सॉफ़्टवेयर बदलावों को कैसे संरचित और समीक्षा किया जाना चाहिए। कई इंजीनियर तर्क देते हैं कि पंक्ति-गणना गुणवत्ता का खराब प्रतिनिधि है, क्योंकि वास्तविक फीचर्स, रिफैक्टर और टेस्ट अक्सर सैकड़ों या हज़ारों पंक्तियाँ मांगते हैं, और बहुत छोटे PR संदर्भ को खंडित कर सकते हैं, समन्वय ओवरहेड बढ़ा सकते हैं, और अनावश्यक बहस को जन्म दे सकते हैं। उभरती सहमति यह है कि एक अच्छा PR काम की एक सुसंगत, समीक्षा योग्य इकाई को दर्शाता है जिसे सुरक्षित रूप से तैनात किया जा सके, और आकार को ऑप्टिमाइज़ या लागू किए जाने वाले कठोर लक्ष्य के बजाय एक लचीले मार्गदर्शक की तरह देखा जाना चाहिए।
“50-पंक्ति आदर्श” दावे पर समग्र प्रतिक्रिया
- कई लोगों को यह दावा संदर्भ के बिना अत्यधिक सामान्यीकृत या यहाँ तक कि “मूर्खतापूर्ण” लगता है।
- दूसरों का मानना है कि मूल विचार—छोटे, केंद्रित PR समझने में आसान और सुरक्षित होते हैं—काफी हद तक सही है, लेकिन इसे नियम नहीं, बल्कि एक मार्गदर्शक सिद्धांत की तरह देखना चाहिए।
- कई लोग ध्यान दिलाते हैं कि लेख एक ऐसी कंपनी का है जिसे छोटे/स्टैक्ड PRs से लाभ मिलता है, और इसे आंशिक रूप से उत्पाद विज्ञापन मानते हैं।
छोटे PRs के पक्ष में तर्क
- पूरी तरह समीक्षा करना आसान; रबर-स्टैम्पिंग की संभावना कम।
- उद्धृत डेटा में अक्सर कम रिवर्ट और तेज़ मर्ज समय से जुड़े होते हैं।
- लेखक और समीक्षक दोनों के लिए संज्ञानात्मक बोझ कम; छोटे समय-खंडों में त्वरित समीक्षा शेड्यूल करना आसान।
- व्यवहारिक परिवर्तनों को अलग करने में बेहतर, जिससे रिवर्ट और डिबगिंग सरल हो जाती है।
- “मॉन्स्टर PRs” को रोकने में मदद करते हैं, जिनमें अक्सर बग छूट जाते हैं और जिनके बारे में तर्क करना कठिन होता है।
कड़े पंक्ति-गणना लक्ष्यों के विरुद्ध तर्क
- कोड की पंक्तियों को जटिलता या मूल्य का खराब प्रतिनिधि माना जाता है।
- मनमानी सीमाएँ (जैसे 5- या 50-पंक्ति कैप) संदर्भ नष्ट कर सकती हैं, अजीब तरह से हिस्सों में बाँटने को मजबूर कर सकती हैं, परीक्षणों को छोड़ने के लिए प्रेरित कर सकती हैं, और फीचर्स को समग्र रूप में समीक्षा करना कठिन बना सकती हैं।
- बहुत छोटे PRs अत्यधिक संदर्भ-परिवर्तन, खंडित समझ, और “हज़ारों PRs से मौत” जैसी स्थिति पैदा कर सकते हैं।
- रिफैक्टर, पुनःडिज़ाइन, नए सबसिस्टम, स्कीमा परिवर्तन, या बड़े परीक्षण जोड़ अक्सर वैध रूप से सैकड़ों या हज़ारों पंक्तियों तक फैल सकते हैं।
संदर्भ, सामग्री, और “काम की इकाई”
- कई लोगों का तर्क है कि असली “आदर्श” यह है: प्रति PR व्यवहार की एक सुसंगत, तैनात करने योग्य इकाई, चाहे वह कितनी भी पंक्तियों की हो।
- कमिट्स बनाम PRs: कई लोग एक बड़े PR के भीतर छोटे, तार्किक कमिट्स पसंद करते हैं, जिनसे रिवर्ट और आर्कियोलॉजी के लिए साफ इतिहास मिले।
- कुछ लोग इस बात पर ज़ोर देते हैं कि टेस्ट कोड अक्सर उसी PR में होना चाहिए; कुछ अन्य गैर-आवश्यक टेस्ट जोड़ के लिए अलग PRs का सुझाव देते हैं।
मेट्रिक्स, कारण-परिणाम, और प्रक्रिया
- कई टिप्पणीकार इस बात पर ज़ोर देते हैं कि सहसंबंध ≠ कारण-परिणाम; छोटे PRs बस स्वभावतः सरल/कम जोखिम वाले काम हो सकते हैं।
- चिंता है कि प्रबंधक इसे Goodhart करके लक्ष्य बना देंगे (“PRs लगभग 50 पंक्तियों के होने चाहिए”), जो वास्तविक गुणवत्ता से कटे होंगे।
- अनुभव व्यापक रूप से भिन्न हैं: कुछ टीमों ने छोटे PRs लागू करके विश्वसनीयता बेहतर की; अन्य ने पाया कि कड़ी सीमाओं ने डिलीवरी धीमी की और समीक्षाएँ खराब कीं।