How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Three Open-Source Ecosystems

कल्पना कीजिए कि एक ऐसी दुनिया है जहाँ सॉफ़्टवेयर बनाना एक विशाल, जटिल महल बनाने जैसा है। इस दुनिया में, डेवलपर्स केवल दीवार पर ईंटें नहीं फेंकते और उम्मीद नहीं करते कि वे चिपक जाएँगी; वे कोड रिव्यू (Code Review) नामक एक कठोर प्रणाली का उपयोग करते हैं। इससे पहले कि कोई भी नई ईंट (या कोड की पंक्ति) स्थायी रूप से महल में जोड़ी जाए, निरीक्षकों की एक टीम उसकी दरारों की जाँच करती है, यह सुनिश्चित करती है कि वह डिज़ाइन में फिट बैठती है या नहीं, और यह भी देखती है कि वह किसी अन्य चीज़ को तोड़ तो नहीं रही है। महल को ऊँचा और सुरक्षित रखने के लिए यह प्रक्रिया अत्यंत महत्वपूर्ण है।

हालाँकि, कभी-कभी एक प्रोजेक्ट केवल एक ईंट जितना बड़ा नहीं होता। यह एक पूरा टावर हो सकता है जिसे बनाया जाना है। अतीत में, डेवलपर्स शायद एक साथ पूरा टावर बनाने की कोशिश करते थे, लेकिन इसकी जाँच करना कठिन है। इसलिए, उन्होंने इसे छोटे, जुड़े हुए चरणों की एक श्रृंखला में तोड़ने की शुरुआत की। सॉफ़्टवेयर की दुनिया में, विशेष रूप से गेरिट (Gerrit) नामक टूल के भीतर, इन जुड़े हुए चरणों को रिलेशन चेन्स (Relation Chains) कहा जाता है। एक रिलेशन चेन को डोमिनोज़ (dominoes) के एक सेट की तरह समझें जो एक लाइन में खड़े हैं: जबकि आप दूसरे के गिरने तक तीसरे को नहीं गिरा सकते, और दूसरे के गिरने तक पहले को नहीं, निरीक्षक उन सभी की एक साथ जाँच कर सकते हैं, लेकिन महल को केवल क्रम में ही पूरा किया जा सकता है। पूरी श्रृंखला आपस में जुड़ी हुई है; यदि पहला डोमिनो ("बेस") डगमगा रहा है, तो पूरी लाइन मुसीबत में है। इन चेन्स को समझना इसलिए महत्वपूर्ण है क्योंकि यदि सिस्टम बहुत धीमा या भ्रमित करने वाला है, तो डेवलपर्स घंटों इंतज़ार करने में फंस सकते हैं, या महल में छिपी हुई दरारें रह सकती हैं।

---

डोमिनो प्रभाव: डेवलपर्स वास्तव में कोड चेन्स का उपयोग कैसे करते हैं

यह शोध पत्र एक गहन अध्ययन है कि तीन विशाल ओपन-सोर्स समुदायों (OpenStack, Wikimedia, और ONAP) के डेवलपर्स सॉफ़्टवेयर बनाने के लिए इन "रिलेशन चेन्स" का उपयोग कैसे करते हैं। शोधकर्ताओं ने लगभग 30,000 चेन्स और 4,00,000 से अधिक व्यक्तिगत कोड परिवर्तनों का विश्लेषण किया ताकि यह देखा जा सके कि ये जुड़े हुए डोमिनोज़ वास्तविक दुनिया में कैसे व्यवहार करते हैं। वे जानना चाहते थे: क्या ये चेन्स सामान्य हैं? क्या वे समीक्षा प्रक्रिया को तेज़ करते हैं या धीमा? और क्या होता है जब आप लाइन के बीच में एक डोमिनो को ठीक करने की कोशिश करते हैं?

चेन्स हर जगह हैं (और बड़ी होती जा रही हैं)

सबसे पहले, अध्ययन में पाया गया कि ये चेन्स कोई दुर्लभ या विशिष्ट तकनीक नहीं हैं; वे काम करने का एक मानक तरीका हैं। प्रोजेक्ट के आधार पर, सभी कोड परिवर्तनों में से 5% से 49% तक एक चेन का हिस्सा होते हैं। वास्तव में, जिन 15 प्रोजेक्ट्स का उन्होंने अध्ययन किया, उनमें से 14 में इन चेन्स का उपयोग समय के साथ बढ़ रहा है। डेवलपर्स समझ रहे हैं कि बड़े कार्यों को जुड़े हुए, छोटे टुकड़ों में तोड़ना ही सही तरीका है।

इनमें से अधिकांश चेन्स छोटी होती हैं, आमतौर पर केवल एक जोड़ी डोमिनोज़ (एक बेस चेंज और एक आश्रित चेंज)। हालाँकि, कुछ प्रोजेक्ट्स में ऐसी चेन्स हैं जो अविश्वसनीय रूप से गहरी होती हैं। शोधकर्ताओं ने 98 सदस्यों वाली चेन पाई। एक प्रोजेक्ट में तो ऑटो-जेनरेटेड (स्वचालित रूप से निर्मित) लगभग 60,000 सदस्यों वाली एक एकल चेन भी थी, हालाँकि वह मानव द्वारा नहीं बल्कि स्वचालित कॉन्फ़िगरेशन का एक विशेष मामला था।

"बीच वाला" हिस्सा ही बाधा (Bottleneck) है

यहाँ मामला दिलचस्प हो जाता है। शोधकर्ताओं ने पाया कि चेन के बीच में होना सबसे कठिन काम है। यदि आप पहला डोमिनो ("बेस") हैं, तो आपको बस अपनी समीक्षा का इंतज़ार करना है। यदि आप अंतिम डोमिनो ("टॉप") हैं, तो आपको बस अपने से पहले वालों का इंतज़ार करना है। लेकिन यदि आप बीच में हैं, तो आप एक दबाव में फंसे हुए हैं। आप अपने से पहले वाले डोमिनो (उसके अप्रूव होने का इंतज़ार) द्वारा रोके जाते हैं और साथ ही अपने बाद वाले डोमिनोओं को भी रोकते हैं।

इस "दबाव" के कारण, चेन के बीच के बदलावों को अप्रूव होने में काफी अधिक समय लगता है। अध्ययन में पाया गया कि, औसतन, चेन के सदस्यों को समान आकार के एकल, अलग-थलग परिवर्तनों की तुलना में मर्ज होने में 2.6 गुना अधिक समय लगता है। यह देरी इसलिए नहीं है क्योंकि कोड खराब है; यह "सिंक्रोनाइज़ेशन ओवरहेड" के कारण है। भले ही निरीक्षक (रिव्यूअर्स) समानांतर (parallel) में ईंटों की जाँच कर सकते हैं, लेकिन महल में वास्तविक विलय (merge) एक-एक करके, नीचे से ऊपर की ओर ही होना चाहिए। हर बार जब चेन के किसी हिस्से में बदलाव किया जाता है, तो अक्सर पूरी लाइन को फिर से जाँचने, फिर से टेस्ट करने और पुनर्व्यवस्थित करने की आवश्यकता होती है, जिससे एक बाधा उत्पन्न होती है जहाँ बीच के बदलाव नीचे वालों के लिए इंतज़ार करते हैं और ऊपर वालों को भी रोक देते हैं।

"सीआई एम्प्लीफिकेशन" (CI Amplification) का राक्षस

यह शोध पत्र एक ऐसी घटना पर भी प्रकाश डालता है जिसे वे सीआई एम्प्लीफिकेशन इफेक्ट (CI amplification effect) कहते हैं। "सीआई" का अर्थ है कंटीन्यूअस इंटीग्रेशन (Continuous Integration), जो एक रोबोट सेना की तरह है जो हर नई ईंट का स्वचालित रूप से परीक्षण करती है ताकि यह सुनिश्चित हो सके कि वह महल को तोड़ न दे। सख्त नियमों वाले प्रोजेक्ट्स (जैसे OpenStack) में, जब भी कोई डेवलपर चेन में किसी बदलाव को अपडेट करता है, तो रोबोट सेना को उस बदलाव और उस पर निर्भर सभी बदलावों का फिर से परीक्षण करना पड़ता है।

अध्ययन में पाया गया कि चेन के सदस्य 10 से 23 स्वचालित टेस्ट जॉब्स को ट्रिगर करते हैं, जबकि एक एकल, अलग-थलग बदलाव शायद दो से भी कम को ट्रिगर करता है। यह ऐसा ही है जैसे यदि आपको अपना एक बल्ब बदलने के लिए अपने पूरे घर का फिर से परीक्षण करना पड़े। यह कंप्यूटरों के लिए काम का भारी बोझ और मनुष्यों के लिए देरी पैदा करता है।

"फाउंडेशन इफेक्ट" (Foundation Effect)

लेखकों की एक और दिलचस्प खोज है जिसे वे फाउंडेशन इफेक्ट कहते हैं। उन्होंने पाया कि पहले डोमिनो (बेस) पर किया गया प्रयास यह निर्धारित करता है कि उसके बाद के सभी डोमिनो पर कितना प्रयास किया जाएगा।

यदि बेस चेंज पर बहुत अधिक ध्यान दिया जाता है, बहुत सारी टिप्पणियाँ मिलती हैं, और संशोधन के कई दौर होते हैं, तो पूरी चेन भी वैसा ही व्यवहार करती है। शोधकर्ताओं ने बेस पर होने वाली गतिविधि और उसके वंशजों (descendants) की गतिविधि के बीच एक मजबूत संबंध (सहसंबंध 0.43 से 0.61) पाया। यह ऐसा है जैसे पहले डोमिनो का "वाइब" पूरी लाइन का स्वर तय करता है। यदि नींव कमजोर है और उसे बहुत अधिक सुधार की आवश्यकता है, तो पूरा टावर बनाने में अधिक समय लगता है। इसके विपरीत, यदि बेस ठोस है और जल्दी अप्रूव हो जाता है, तो बाकी चेन सुचारू रूप से चलती है।

चेन्स स्थिर नहीं हैं

अंत में, यह शोध पत्र बताता है कि ये चेन्स कठोर संरचनाएँ नहीं हैं। चेन के लगभग 33.5% बदलावों में उनके अंतिम रूप से मर्ज होने से पहले "स्ट्रक्चरल इवोल्यूशन" (संरचनात्मक विकास) होता है। इसका मतलब है कि समीक्षा के दौरान डोमिनोज़ के बीच का संबंध बदल जाता है। एक डेवलपर किसी बदलाव को उसके पैरेंट (parent) से अलग करने और उसे किसी दूसरे से जोड़ने का निर्णय ले सकता है, या पूरी चेन को पुनर्गठित किया जा सकता है।

यह जटिलता की एक और परत जोड़ता है: चेन का नक्शा लगातार बदलता रहता है। कभी-कभी, एक चेन लंबे समय तक निष्क्रिय रह सकती है। अध्ययन में पाया गया कि एक चेन के किसी हिस्से के सबमिट होने और उसके अंततः मर्ज होने के बीच का अंतर कुछ मामलों में 2.85 साल तक खिंच सकता है!

भविष्य के लिए इसका क्या अर्थ है

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

उनका सुझाव है कि यदि हम अपना ध्यान चेन के बेस (आधार) पर केंद्रित करते हैं, तो हम बाकी चेन के लिए बहुत सारा समय बचा सकते हैं। यदि नींव ठोस है, तो पूरी संरचना तेज़ी से आगे बढ़ती है। वे यह भी प्रस्तावित करते हैं कि टूल्स को "बीच" के बदलावों के बारे में अधिक स्मार्ट होना चाहिए, शायद उन्हें प्राथमिकता देकर ताकि बाकी लाइन का रास्ता साफ हो सके।

संक्षेप में, रिलेशन चेन्स के साथ सॉफ़्टवेयर बनाना एक जटिल ऑर्केस्ट्रा संचालित करने जैसा है। यदि कंडक्टर (बेस) ताल से बाहर है, तो पूरा ऑर्केस्ट्रा संघर्ष करता है। लेकिन यदि कंडक्टर स्पष्ट है और संगीतकार (टूल्स) समझते हैं कि वाद्य यंत्र एक-दूसरे से कैसे जुड़े हैं, तो संगीत तेज़ी से बहता है। अध्ययन बताता है कि इन कनेक्शनों को समझकर, हम लाइन में इंतज़ार करना बंद कर सकते हैं और बहुत अधिक कुशलता से महल बना सकते हैं।