Written with AI assistance from the source video. The video is the authority.
5:31Maximilian Schwarzmüller
Log in to leave a comment
No posts yet
AI कोडिंग टूल्स को अपनाने के बाद से जूनियर डेवलपर्स का कोड आउटपुट बहुत बढ़ गया है। लेकिन एक टेक लीड के रूप में, बहुत अधिक संभावना है कि आपकी दिनचर्या किसी नर्क से कम नहीं हो गई है। बड़ी मात्रा में अप्रमाणित कोड एक साथ आने के कारण कोड रिव्यू पूरी तरह रुक गए हैं, और मर्ज कॉन्फ्लिक्ट्स (मर्ज टकराव) और डिप्लॉयमेंट का अचानक रुक जाना आम बात हो गई है। टूल्स के पीछे भागना थोड़ी देर के लिए बंद करना होगा। अब टीम को जिस चीज की जरूरत है, वह है मशीनों द्वारा लिखे गए कोड को नियंत्रित करने के लिए मात्रात्मक (quantitative) मानदंड और एक स्पष्ट परिचालन प्रणाली।
पारंपरिक फीचर-आधारित पुल रिक्वेस्ट (PR) सबमिशन विधि रिव्यूअर पर भारी बोझ डालती है। जब आप एक ही बार में सैकड़ों लाइनों के कोड को सत्यापित करने की कोशिश करते हैं, तो अंततः आप केवल बेसिक क्रियाओं की जांच करते हैं और 'LGTM (Looks Good To Me)' दबा देते हैं। यह वह क्षण है जब दोष (defects) बिना किसी रोक-टोक के प्रोडक्शन में चले जाते हैं।
PR को तार्किक इकाइयों में विभाजित करना चाहिए जो केवल आर्किटेक्चर लेयर या सिंगल रिस्पॉन्सिबिलिटी (एकल जिम्मेदारी) को हल करें। यह अनुशंसा की जाती है कि परिवर्तनों की संख्या 150 लाइनों से कम और संशोधित फाइलों की संख्या 5 से कम तक सीमित करने के लिए मात्रात्मक ऊपरी सीमा लागू की जाए। माइक्रोसॉफ्ट इंजीनियरिंग टीम के एक अध्ययन के अनुसार, जब 400 लाइनों से अधिक के PR पर चेतावनी भेजने का मानदंड लागू किया गया, तो मर्ज के बाद विफलताओं (failure rate) में 35% की कमी आई। इसके अलावा, कोड विश्लेषण प्लेटफॉर्म 'कोड क्लाइमेट (Code Climate)' के आंकड़े बताते हैं कि 150 लाइनों से छोटे PR, 250 लाइनों से बड़े PR की तुलना में 40% तेजी से मर्ज होते हैं और संभावित दोषों (potential defects) को पकड़ने की दर 87% से अधिक हो जाती है।
कोड रिव्यू के समय को कम करने के लिए, टीम के भीतर दिशानिर्देशों को औपचारिक रूप दें और निम्नलिखित अभ्यास करें:
git rebase -i कमांड का उपयोग करके उत्पन्न किए गए घने कमिट्स को संशोधित और व्यवस्थित करें ताकि प्रोजेक्ट इतिहास की पठनीयता सुनिश्चित हो सके।इसे भौतिक रूप से लागू करने के लिए, आपको CI/CD पाइपलाइन में Danger JS को शामिल करना होगा। प्रोजेक्ट रूट में एक dangerfile.js बनाएं और एक ऐसी स्क्रिप्ट तैनात करें जो बिल्ड को तब फेल कर दे जब परिवर्तनों की संख्या 150 लाइनों से अधिक हो या PR का विवरण 15 अक्षरों से कम हो। जब सिस्टम इन्हें ब्लॉक करना शुरू कर देगा, तो टीम के सदस्य खुद ही PR को विभाजित करके सबमिट करने लगेंगे।
AI डेवलपमेंट टूल्स सुविधाजनक तो हैं, लेकिन वे अक्सर डोमेन संदर्भ को नजरअंदाज करते हैं, नकली API बनाते हैं (hallucinations), और सुरक्षा कमजोरियों के साथ आते हैं। मशीन की उत्पादकता का लाभ उठाते हुए गुणवत्ता बनाए रखने के लिए, एक सख्त 'ह्यूमन-इन-द-लूप (Human-in-the-loop)' प्रक्रिया अनिवार्य है। AI-जनरेटेड कोड को एक अलग और स्वतंत्र ब्रांच वातावरण में सत्यापित करने के बाद ही मुख्य ब्रांच (main branch) में मर्ज किया जाना चाहिए।
डिप्लॉयमेंट दुर्घटनाओं को कम करने के लिए AI-जनरेटेड कोड सत्यापन वर्कफ़्लो इस प्रकार है:
main ब्रांच के पॉइंट से ai-refactor/ प्रीफिक्स का उपयोग करके एक समर्पित ब्रांच बनाएं। कोड संशोधित करने से पहले, स्थानीय पथ में लक्ष्यों और बाधाओं को शामिल करने वाली एक विस्तृत मार्कडाउन फाइल (spec.md) बनाएं ताकि AI मॉडल को अनावश्यक कोड जोड़ने से रोका जा सके।Assisted-by: AI-Model-Name कीवर्ड शामिल करें।यदि आप इस वर्कफ़्लो को स्थापित करते हैं, तो आप अनसत्यापित AI कोड को मुख्य स्ट्रीम में प्रवेश करने से रोक सकते हैं।
PR को 150 लाइनों से कम में विभाजित करने से कोड की पठनीयता तो अधिकतम हो जाती है, लेकिन जब कई डेवलपर्स एक ही टारगेट पॉइंट पर लगातार मर्ज करने का प्रयास करते हैं, तो वर्जन कंट्रोल कॉन्फ्लिक्ट्स (मर्ज टकराव) बिगड़ सकते हैं। इस समस्या को हल करने के लिए, 'ट्रंक-बेस्ड डेवलपमेंट (trunk-based development)' प्रतिमान को प्राथमिकता दी जानी चाहिए और इसे Graphite जैसे निरंतर सबमिशन ऑटोमेशन टूल्स और रनटाइम में कोड निष्पादन पथ को नियंत्रित करने वाले 'फीचर फ्लैग' आर्किटेक्चर के साथ जोड़ा जाना चाहिए।
यह सुनिश्चित करने के लिए कि अधूरा नया फीचर कोड मुख्य स्ट्रीम में मर्ज होने के बाद भी प्रोडक्शन वातावरण को प्रभावित न करे, कोडबेस में फीचर फ्लैग समाधान 'अनलीश (Unleash)' स्थापित करें और निम्नलिखित प्रक्रिया लागू करें:
gt create तथा gt submit --stack कमांड का उपयोग करके यह सेट करें कि ऊपरी स्टैक ब्रांच निचली ब्रांच को आधार माने। कोडबेस के भीतर, परिवर्तन क्षेत्र के अनुरूप एक सामान्य इंटरफेस को पहले से परिभाषित करें।useFlag('feat_new_payment')) के आधार पर, कंडीशनल लॉजिक के साथ इंस्टेंस को लेट-मैपिंग इंजेक्शन के माध्यम से लोड करें। फ्लैग के निष्क्रिय होने पर, फैक्ट्री ब्रांचिंग लॉजिक को पुराने वर्शन को रेंडर करने के लिए कॉन्फ़िगर करें।Unleash डैशबोर्ड में, उस फ्लैग के टारगेट एंट्री अनुपात को 0% पर सेट रखते हुए मुख्य ट्रंक में मर्ज करें। चूंकि अधूरा कोड मर्ज होने के बाद भी अंतिम उपयोगकर्ता को दिखाई नहीं देगा, इसलिए मर्ज कॉन्फ्लिक्ट्स को पहले से ही रोका जा सकता है।
एक टिकाऊ डेवलपमेंट संगठन बनाने के लिए, आपको यह नियंत्रित करना होगा कि कोड रिव्यू प्रक्रिया स्वयं स्वस्थ तरीके से चल रही है या नहीं, और इसके लिए मेट्रिक्स का उपयोग करना होगा। कोड क्लाइमेट के बेंचमार्क गाइड के अनुसार, 'रिव्यू साइकिल (Review Cycles)' की निगरानी करना प्रभावी है, जो एक एकल PR के निर्माण से लेकर मर्ज होने तक फीडबैक और संशोधित कमिट्स की आवृत्ति है। उद्योग के शीर्ष 25% चुस्त संगठनों में, औसत रिव्यू साइकिल 1.1 बार के भीतर होती है। दूसरी ओर, यदि किसी टीम का मेट्रिक अक्सर 1.5 से अधिक हो जाता है, तो यह संकेत है कि वहां स्पष्ट मानक दस्तावेजों या अस्पष्ट योजना परिभाषाओं जैसी बाधाएं मौजूद हैं।
रिव्यू प्रक्रिया के दौरान जमा होने वाले कन्वेंशन संघर्षों को कम करने के लिए, CodeRabbit के लर्निंग मैकेनिज्म और Rulens CLI-आधारित फीडबैक लूप को संयोजित करें:
npx rulens generate कमांड को पाइपलाइन में एम्बेड करती है ताकि नया नियम दस्तावेज़ docs/lint-rules.md स्वचालित रूप से संकलित हो सके।एक बार यह परिचालन दिनचर्या स्थापित हो जाने के बाद, AI कोड लिखने के पहले चरण से ही टीम के भीतर के कोडिंग कन्वेंशन के प्रति जागरूक रहेगा। दोहराव वाली लिंट त्रुटियां, मैनुअल सुधार, और रिव्यूअर के साथ थकाऊ बहस कम हो जाएगी, जिससे पूरी टीम का रिव्यू साइकिल कुशलतापूर्वक नियंत्रित हो सकेगा।