स्टैक्ड पीआर: कोड समीक्षा पर पुनर्विचार

स्टैक्ड पीआर के साथ कोड समीक्षा पर पुनर्विचार

यह पोस्ट शिफ्ट-लेफ्ट सिद्धांतों की पड़ताल करती है और सुझाव देती है कि स्टैक्ड पीआर तेजी से उपयोगी हो जाएंगे।

पीयर कोड समीक्षा प्रक्रिया सॉफ्टवेयर विकास का एक अनिवार्य हिस्सा है। यह सॉफ्टवेयर की गुणवत्ता बनाए रखने में मदद करता है और मानकों, परियोजना आवश्यकताओं, शैली दिशानिर्देशों के पालन को बढ़ावा देता है और सीखने और ज्ञान हस्तांतरण की सुविधा प्रदान करता है।

कोड समीक्षा प्रभावशीलता

जबकि पर्याप्त रूप से छोटे कोड परिवर्तनों की समीक्षा के लिए प्रभावशीलता अधिक है, परिवर्तन के आकार में वृद्धि के साथ यह तेजी से गिरती है। प्रभावी होने के लिए मानसिक फोकस के आवश्यक स्तर को बनाए रखने के लिए, बड़ी कोड समीक्षाएँ थका देने वाली होती हैं।

आमतौर पर, समीक्षा की अवधि जितनी लंबी होती जाती है, समग्र समीक्षा उतनी ही कम प्रभावी होती जाती है:

तो हम पुल अनुरोधों (पीआर) के आकार को सीमित क्यों नहीं कर सकते? जबकि कई परिवर्तन छोटे से शुरू हो सकते हैं, अचानक दो-पंक्ति का एक छोटा सा परिवर्तन 500-पंक्ति रिफैक्टर में विकसित हो सकता है जिसमें समीक्षकों के साथ कई आगे-पीछे की बातचीत शामिल है।

कुछ इंजीनियरिंग टीमें लंबे समय तक चलने वाली फीचर शाखाएं भी बनाए रखती हैं क्योंकि वे काम करना जारी रखती हैं, जिससे समीक्षा करना कठिन हो जाता है।

तो, हम सही संतुलन कैसे बनायें? सरल। स्टैक्ड पीआर का प्रयोग करें.

स्टैक्ड पीआर क्या हैं?

स्टैक्ड पुल अनुरोध छोटे, पुनरावृत्तीय परिवर्तन करते हैं और एक ही पुल अनुरोध में बड़े मोनोलिथ परिवर्तनों को बंडल करने के बजाय एक दूसरे के ऊपर स्टैक्ड होते हैं। स्टैक में प्रत्येक पीआर केवल एक तार्किक परिवर्तन पर ध्यान केंद्रित करता है, जिससे समीक्षा प्रक्रिया अधिक प्रबंधनीय और कम समय लेने वाली हो जाती है।

हमने पिछले साल एक पोस्ट भी लिखी थी जिसमें बताया गया था कि कैसे यह मदद फाइलों या सुविधाओं के आधार पर चीजों को तोड़ने के बजाय एक कथा के रूप में कोड परिवर्तनों का प्रतिनिधित्व करती है।

स्टैक्ड पीआर क्यों?

अधिक प्रभावी कोड समीक्षाओं की संस्कृति के निर्माण के अलावा, स्टैक्ड पीआर के कुछ अन्य लाभ भी हैं:

प्रारंभिक कोड समीक्षा प्रतिक्रिया

कल्पना कीजिए कि आप एक बड़ी सुविधा लागू कर रहे हैं। संपूर्ण सुविधा बनाने और फिर कोड समीक्षा का अनुरोध करने के बजाय, प्रारंभिक रूपरेखा तैयार करने और उसे प्रतिक्रिया के लिए तुरंत प्रस्तुत करने पर विचार करें।

यह संभवतः आपके डिज़ाइन पर शीघ्र प्रतिक्रिया प्राप्त करके आपके अनगिनत घंटे बचा सकता है।

तेज़ सीआई फीडबैक चक्र

स्टैक्ड पीआर शिफ्ट-लेफ्ट अभ्यास का समर्थन करते हैं क्योंकि परिवर्तनों को लगातार एकीकृत और परीक्षण किया जाता है, जो समस्याओं का शीघ्र पता लगाने और सुधार की अनुमति देता है।

परिवर्तनों को टुकड़ों और टुकड़ों में मिला दिया जाता है, किसी भी मुद्दे को जल्दी पकड़ लिया जाता है बनाम एक विशाल परिवर्तन को इस उम्मीद में विलय कर दिया जाता है कि इससे उत्पाद में कमी नहीं आएगी!

ज्ञान बांटना

कोड समीक्षाएँ भावी पीढ़ी के लिए भी अद्भुत हैं। आपके कोड परिवर्तन किसी सुविधा को लागू करने के पीछे आपकी विचार प्रक्रिया को बता रहे हैं, इसलिए, परिवर्तनों का टूटना अधिक प्रभावी ज्ञान हस्तांतरण बनाता है।

टीम के सदस्यों के लिए परिवर्तनों को समझना आसान है, जो भविष्य के लिए बेहतर ज्ञान साझा करने को बढ़ावा देता है।

अनब्लॉक रहना

कोड की समीक्षा और अनुमोदन की प्रतीक्षा करना एक निराशाजनक प्रक्रिया हो सकती है। स्टैक्ड पीआर के साथ, डेवलपर्स पिछले पीआर को मंजूरी देने के लिए समीक्षकों की प्रतीक्षा किए बिना एक फीचर के कई हिस्सों पर काम कर सकते हैं

क्या चालबाजी है?

तो, अधिक डेवलपर कोड समीक्षा के लिए स्टैक्ड पीआर का उपयोग क्यों नहीं करते?

हालाँकि यह स्टैक्ड पीआर वर्कफ़्लो कोड समीक्षाओं को प्रबंधनीय और डेवलपर्स को उत्पादक बनाए रखने की दोनों वांछित प्रथाओं को संबोधित करता है, दुर्भाग्य से, यह Git या GitHub द्वारा मूल रूप से बहुत अच्छी तरह से समर्थित नहीं है।

परिणामस्वरूप, इंजीनियरों को इस स्टैकिंग तकनीक को मौजूदा Git और GitHub प्लेटफार्मों में शामिल करने में सक्षम बनाने के लिए ओपन-सोर्स समुदाय में कई उपकरण विकसित किए गए हैं। लेकिन पीआर को ढेर करना कहानी का केवल एक हिस्सा है।

अद्यतन करने

जैसे ही हमें कोड समीक्षा फीडबैक मिलता है और हम स्टैक के हिस्से में बदलाव करते हैं, हमें अब सभी बाद की शाखाओं में विवादों को फिर से आधार बनाना और हल करना होगा।

चलिए एक उदाहरण लेते हैं. कल्पना करें कि आप एक ऐसे बदलाव पर काम कर रहे हैं जिसके लिए स्कीमा परिवर्तन, बैकएंड परिवर्तन और फ्रंटएंड परिवर्तन की आवश्यकता है।

इसके साथ, अब आप पहले समीक्षा के लिए एक सरल स्कीमा परिवर्तन भेज सकते हैं, और जब इसकी समीक्षा की जा रही हो, तो आप बैकएंड और फ्रंटएंड पर काम करना शुरू कर सकते हैं। स्टैक्ड पीआर का उपयोग करके, इन सभी 3 परिवर्तनों की 3 अलग-अलग समीक्षाओं द्वारा समीक्षा की जा सकती है।

इस मामले में, आपके पास एक स्टैक हो सकता है जो इस तरह दिखता है जहां demo/schema , demo/backend और demo/frontend एक दूसरे के ऊपर खड़ी 3 शाखाओं का प्रतिनिधित्व करते हैं।

अब तक, यह समझ में आता है, लेकिन क्या होगा यदि आपको स्कीमा परिवर्तन पर कुछ कोड समीक्षा टिप्पणियाँ मिलती हैं जिसके लिए एक नई प्रतिबद्धता बनाने की आवश्यकता होती है? अचानक आपका प्रतिबद्ध इतिहास इस तरह दिखता है:

अब, आपको बाद की सभी शाखाओं को मैन्युअल रूप से रीबेस करना होगा और हर चरण में विवादों को हल करना होगा। कल्पना करें कि यदि आपके पास 10 खड़ी शाखाएँ हैं जहाँ आपको 10 बार संघर्षों को हल करना पड़ सकता है।

विलय

लेकिन इतना ही नहीं, पीआर को स्टैक में मर्ज करना एक वास्तविक दुःस्वप्न हो सकता है। पीआर को मर्ज करने के लिए आपके पास 3 विकल्प squash , merge और rebase हैं। आइए यह समझने का प्रयास करें कि प्रत्येक में पर्दे के पीछे क्या होता है।

• squash कमिट के मामले में, Git पीआर के सभी मौजूदा कमिटों से परिवर्तन लेता है और उन्हें एक ही कमिट में फिर से लिखता है। इस मामले में, वे परिवर्तन कहां से आए इसका कोई इतिहास नहीं रखा गया है।

• merge कमिट एक विशेष प्रकार की Git कमिट है जिसे दो या दो से अधिक कमिट के संयोजन द्वारा दर्शाया जाता है। तो, यह squash कमिट के समान ही काम करता है लेकिन यह अपने माता-पिता के बारे में जानकारी भी प्राप्त करता है। एक सामान्य परिदृश्य में, एक मर्ज कमिट के दो माता-पिता होते हैं: बेस ब्रांच पर अंतिम कमिट (जहां पीआर मर्ज किया गया है), और फीचर ब्रांच पर शीर्ष कमिट जिसे मर्ज किया गया था।

  
  

  यद्यपि यह दृष्टिकोण प्रतिबद्ध इतिहास को अधिक संदर्भ देता है, यह अनजाने में एक गैर-रेखीय गिट-इतिहास बनाता है जो अवांछनीय हो सकता है।

• अंत में, rebase और मर्ज के मामले में, Git बेस ब्रांच पर कमिट्स को फिर से लिखेगा। तो, squash कमिट विकल्प के समान, यह मूल कमिट से जुड़े किसी भी इतिहास को खो देगा।

आमतौर पर, यदि आप पीआर को स्टैक करते समय merge कमिट रणनीति का उपयोग कर रहे हैं, तो आपका जीवन थोड़ा आसान होगा, लेकिन अधिकांश टीमें गिट-इतिहास को साफ रखने के लिए उस रणनीति का उपयोग करने से हतोत्साहित करती हैं। इसका मतलब है कि आप संभवतः squash या rebase मर्ज का उपयोग कर रहे हैं।

और यह बाद की सभी असंबद्ध स्टैक्ड शाखाओं के लिए एक मर्ज संघर्ष पैदा करता है।

उपरोक्त उदाहरण में, मान लें कि हम पहली शाखा demo/schema मेनलाइन में मर्ज कर देते हैं। यह एक नया कमिट D1 बनाएगा जिसमें A1 और A2 के परिवर्तन शामिल होंगे।

चूँकि Git को नहीं पता कि D1 कहाँ से आया है, और demo/backend अभी भी A2 पर आधारित है, इसलिए मेनलाइन के शीर्ष पर demo/backend रीबेस करने का प्रयास मर्ज टकराव पैदा करेगा।

इसी तरह, demo/frontend दोबारा बेस करने के बाद demo/backend दोबारा बेस करने से भी वही समस्याएं पैदा होंगी। इसलिए यदि आपके पास दस खड़ी शाखाएँ हैं और आप स्क्वैश ने उनमें से एक को मिला दिया है, तो आपको इन संघर्षों को नौ बार हल करना होगा।

हम अभी भी केवल सतह को खरोंच रहे हैं; कई अन्य उपयोग के मामले हैं जैसे कि कमिट को पुन: व्यवस्थित करना, विभाजित करना, मोड़ना और शाखाओं का नाम बदलना, जो स्टैक्ड पीआर से निपटने के दौरान प्रबंधन के लिए भारी ओवरहेड बना सकते हैं।

इसीलिए हमने एविएटर के हिस्से के रूप में स्टैक्ड पीआरएस प्रबंधन का निर्माण किया।

एविएटर सीएलआई अलग क्यों है?

एविएटर को एक संवर्द्धन परत के रूप में सोचें जो आपके मौजूदा टूलींग के शीर्ष पर स्थित है। उन्नत डेवलपर अनुभव प्रदान करने के लिए एविएटर GitHub, Slack, Chrome और Git CLI से जुड़ता है।

एविएटर सीएलआई बाकी सभी चीजों के साथ सहजता से काम करता है! सीएलआई सिर्फ गिट के शीर्ष पर एक परत नहीं है बल्कि गिटहब में स्टैक के संदर्भ को भी समझता है। आइए एक उदाहरण पर विचार करें.

एक ढेर बनाना

स्टैक बनाना काफी सरल है। इस मामले को छोड़कर, हम यह सुनिश्चित करने के लिए कि स्टैक को ट्रैक किया गया है, शाखाएं बनाने के लिए av सीएलआई का उपयोग करते हैं। उदाहरण के लिए, अपनी स्कीमा शाखा और संबंधित पीआर बनाने के लिए, नीचे दिए गए चरणों का पालन करें।

 av stack branch demo/schema # make schema changes git commit -a -m "[demo] schema changes" av pr create

चूँकि एविएटर आपके GitHub से भी जुड़ा है, इससे आपके लिए स्टैक की कल्पना करना आसान हो जाता है।

या यदि आप इसे टर्मिनल से विज़ुअलाइज़ करना चाहते हैं, तो आप अभी भी सीएलआई कमांड के साथ ऐसा कर सकते हैं:

स्टैक को अद्यतन करना

स्टैक का उपयोग करना अब आसान हो गया है। आप किसी भी शाखा में नए कमिट जोड़ सकते हैं, और सभी शाखाओं को सिंक्रनाइज़ करने के लिए स्टैक में कहीं से भी av stack sync चला सकते हैं। एविएटर स्वचालित रूप से आपके लिए सभी शाखाओं को पुनः आधार बनाता है, और यदि कोई वास्तविक मर्ज संघर्ष है, तो आपको बस इसे एक बार हल करना होगा।

स्टैक का विलय

यह वह जगह है जहां एविएटर उपकरण आसानी से किसी भी मौजूदा टूलींग से अलग दिखते हैं। एविएटर में, हमने बड़े पैमाने पर हजारों परिवर्तनों को ऑटो-मर्ज करने का प्रबंधन करने के लिए सबसे उन्नत मर्जक्यू में से एक का निर्माण किया है।

एविएटर सीएलआई और स्टैक्ड पीआर के साथ सहज एकीकरण का समर्थन करता है। इसलिए पीआर के आंशिक या पूर्ण स्टैक को मर्ज करने के लिए, आप उन्हें सीएलआई av pr queue का उपयोग करके या गिटहब: /aviator stack merge पर एक टिप्पणी पोस्ट करके एविएटर मर्जक्यू को सौंप सकते हैं।

एविएटर स्वचालित रूप से क्रम में सभी कतारबद्ध स्टैक को मान्य करने, अपडेट करने और ऑटो-मर्ज करने का काम संभालता है।

अब जब पीआर मर्ज हो जाते हैं, तो आप इस बार सभी पीआर को अपडेट करने और सभी मर्ज किए गए पीआर को साफ करने के लिए av stack sync --trunk चला सकते हैं।

शिफ्ट-लेफ्ट ही भविष्य है

परिवर्तनों को छोटे भागों में विभाजित करने की आवश्यकता के कारण स्टैक्ड पीआर शुरू में अधिक काम की तरह लग सकते हैं। हालाँकि, कोड समीक्षा दक्षता में वृद्धि, तेज़ फीडबैक लूप और बेहतर सीखने के अवसर निश्चित रूप से इस ओवरहेड से अधिक होंगे।

जैसे-जैसे हम शिफ्ट-लेफ्ट सिद्धांतों को अपनाना जारी रखेंगे, स्टैक्ड पीआर तेजी से उपयोगी होते जाएंगे।

एविएटर सीएलआई बहुत कम परेशानी के साथ स्टैक्ड पीआर को प्रबंधित करने का एक शानदार तरीका प्रदान करता है। सीएलआई ओपन-सोर्स है और पूरी तरह से मुफ़्त है। हम चाहेंगे कि आप इसे आज़माएँ और अपनी प्रतिक्रिया हमारे चर्चा बोर्ड पर साझा करें।

एविएटर में, हम डेवलपर्स को तेज़ और बेहतर निर्माण करने के लिए सशक्त बनाने के लिए पहले सिद्धांतों से डेवलपर उत्पादकता उपकरण बना रहे हैं।