आपके PR बड़े होने का असली कारण
मैं एक ऐसी कंपनी में काम करता था जहाँ आदतवश बहुत बड़े pull requests भेजे जाते थे। एक PR हफ्तों तक खुला रह सकता था। उसकी समीक्षा करने के लिए पूरे subsystem को अपने दिमाग में रखना पड़ता था। Bugs जमा होते गए। Deadlines निकलती गईं। अंततः हमें सिस्टम के एक बड़े हिस्से को फिर से बनाना पड़ा क्योंकि अब कोई भी उसे सुरक्षित रूप से बदल नहीं पा रहा था।
Engineers बुरे नहीं थे। वे समझदार थे और कड़ी मेहनत करते थे। PR एक उबाऊ कारण से बड़े होते गए।
किसी ने उन्हें काम को छोटे हिस्सों में बाँटना नहीं सिखाया था।
हम अक्सर बड़े PR को अनुशासन (discipline) की समस्या मानते हैं। हम कहते हैं, "बस छोटे PR बनाओ।" हम ऐसे व्यवहार करते हैं जैसे 1,500 बदलावों और 150 बदलावों के बीच केवल इच्छाशक्ति (willpower) का ही अंतर हो।
यह इच्छाशक्ति के बारे में नहीं है। बड़े काम को छोटे, स्वतंत्र हिस्सों में बाँटना एक कौशल (skill) है। अधिकांश लोगों को यह कभी नहीं सिखाया जाता। जब कोई टिकट कहता है "add billing," तो यह एक एकल कार्य जैसा लगता है। यह देखना कि एक PR कहाँ समाप्त होता है और अगला कहाँ से शुरू होता है, सबसे कठिन हिस्सा है।
मैं भी बड़े PR भेजता था। मुझे लगता था कि "done" का मतलब है पूरी समस्या को एक साथ हल करना और उसे review के लिए भेजना। यह सीखने में सालों लग गए कि छोटा होना बेहतर है।
छोटे PR ने मेरे लिए सब कुछ बदल दिया:
- Reviewers अधिक bugs पकड़ पाते हैं। एक इंसान लगभग 200 बदलावों को समझ सकता है। वे 2,000 बदलावों को नहीं समझ सकते। वे बस सरसरी तौर पर देखते हैं और approve कर देते हैं।
- Merges तेज़ी से होते हैं। PR कतार (queue) में पड़े रहना बंद हो जाते हैं।
- मैंने घबराहट महसूस करना बंद कर दिया। मैंने एक बार में एक हिस्से पर ध्यान केंद्रित किया।
- मैं एक बेहतर planner बन गया। काम को विभाजित करने के लिए आपको अपने काम के स्वरूप को समझना होगा।
मैंने सिस्टम को Lego bricks की तरह देखना शुरू कर दिया। वे छोटे टुकड़े हैं जो आपस में जुड़ जाते हैं। एक बार जब आप उन ईंटों को देख लेते हैं, तो काम को छोटा करना स्वाभाविक लगता है।
मेरी वर्तमान टीम छोटे PR भेजती है। परिणाम स्पष्ट हैं:
- हमारा औसत merge time 1.5 दिन है।
- हम bugs को जल्दी ढूंढते और ठीक करते हैं क्योंकि बदलाव स्पष्ट (legible) होते हैं।
- हमारी delivery timing सुसंगत (consistent) है।
काम को विभाजित करना एक ऐसा कौशल है जिसे आपको सिखाना (coach) चाहिए। आप किसी नियम से बड़े PR को ठीक नहीं कर सकते। आप उन्हें लोगों को 'ईंटों' को देखना सिखाकर ठीक करते हैं।
AI इस कौशल को और भी महत्वपूर्ण बना देता है।
अतीत में, 2,000 lines का code लिखने में बहुत मेहनत लगती थी। उस friction ने PR को छोटा रखा। AI ने उस friction को खत्म कर दिया। आप एक prompt के साथ भारी बदलाव उत्पन्न कर सकते हैं।
मेहनत गायब नहीं हुई। यह बस reviewer पर स्थानांतरित हो गई। author को कुछ नहीं चुकाना पड़ता, लेकिन reviewer को इसकी पूरी कीमत चुकानी पड़ती है।
यदि आकार अब यह संकेत नहीं देता कि लेखक ने कितना काम किया है, तो आकार आपको जोखिम के बारे में बहुत कम बताता है। आपको यह तय करना होगा कि किन हिस्सों पर आपका सबसे अधिक ध्यान देने की आवश्यकता है।
अपनी टीम को बारीकियों को देखना सिखाएं। इंजीनियरिंग में यह सबसे अधिक प्रभाव डालने वाली आदत है।
आपकी टीम यह कैसे तय करती है कि किन PRs की गहन समीक्षा की आवश्यकता है और किन्हें जल्दी पास किया जा सकता है?
स्रोत: https://dev.to/pixel-wraith/the-real-reason-your-prs-get-big-5cm3
वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi