👨🏾‍🚀 👩🏼‍🤝‍👨🏽 👩🏿‍🤝‍👩🏻 चरम प्रोग्रामिंग: जोड़ी प्रोग्रामिंग 🈚️ 🥩 🛌🏾

जोड़ी प्रोग्रामिंग एक्सपी प्रथाओं में से एक है। यह प्रथा कोड रिव्यू के चरम (अतिरंजित) विचार का प्रतीक है। यदि एक समीक्षा आपको कोड की गुणवत्ता में सुधार करने की अनुमति देती है, तो चलो इसे लगातार करते हैं, रिफैक्टिंग और नए कोड लिखने के दौरान।

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

यह कैसे करना है?

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

अनुसंधान

सबसे बड़ी संशयवाद सवाल उठाती है: क्या विकास तब धीमा हो जाएगा जब दो प्रोग्रामर एक ही काम में लगे हों?

अध्ययन बताते हैं कि जोड़े में काम करना या तो व्यक्तिगत रूप से एक ही गति से होता है, या थोड़ा (15%) अधिक धीरे-धीरे । लेकिन कोड बहुत बेहतर है, इसमें कम त्रुटियां (60%) और तकनीकी ऋण शामिल हैं ।

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

जोड़ी प्रोग्रामिंग से बोनस

अनुभव का आदान-प्रदान: अक्सर ऐसा होता है कि एक जोड़ी में बैठकर आप काम की गति बढ़ाने के लिए कुछ नए हॉट की, दिलचस्प उपयोगिताओं के बारे में जानेंगे। किसी भी मामले में, दूसरों के कार्यक्रम को देखकर, आप खुद लगातार सीखते हैं।
सिस्टम का ज्ञान: जोड़े के निरंतर परिवर्तन से टीम के भीतर सिस्टम के विभिन्न हिस्सों के बारे में ज्ञान फैलाने में मदद मिलती है। इससे यह समझना संभव हो जाता है कि सिस्टम कैसे विकसित हो रहा है, सिस्टम के डिजाइन में सुधार करें और तर्क की नकल न करें।
सामूहिक कोड स्वामित्व: जब हर कोई सिस्टम के सभी हिस्सों को लिखने में शामिल होता है, तो किसी वर्ग या विधानसभा के व्यक्तिगत स्वामित्व की कोई बात नहीं हो सकती है।
Mentoring: हम सभी ने एक बार प्रोग्रामिंग शुरू की। जैसा कि अभ्यास ने दिखाया है, प्रोजेक्ट में सबसे सरल इंजेक्शन जोड़ी प्रोग्रामिंग की प्रक्रिया में होता है।
अधिक संचार: टीम के भीतर संचार विश्वास का निर्माण करने में मदद करता है। स्टैंड-अप और रेट्रोस्पेक्टिव्स रोजमर्रा के काम में संचार को जोड़ते हैं, लेकिन यह जोड़ी प्रोग्रामिंग की संभावनाओं के साथ तुलना नहीं की जा सकती है।
एन्कोडिंग मानक: एक जोड़ी में बैठना, लगातार कीबोर्ड को पार करना और जोड़े को बदलना, प्रोग्रामर इस बारे में ज्ञान फैलाते हैं कि प्रोजेक्ट पर एन्कोडिंग मानकों को क्या अपनाया जाता है। कोड की गुणवत्ता की जांच करने के लिए आपको अब स्वचालित टूल को फास्ट करने की आवश्यकता नहीं है।
अनुशासन में सुधार: एक जोड़ी में बैठकर, मैं एक साथी को अपनी रुचि और प्रशिक्षण का स्तर दिखाना चाहता हूं। और यह अस्थायी रूप से सामाजिक स्विच करने के लिए बहुत कठिन है। नेटवर्क नवीनतम मजेदार चित्रों के माध्यम से ब्राउज़ करने के लिए।
स्ट्रीम युग्मन: एक प्रोग्रामर दूसरे से पूछता है कि "अब हम क्या हल कर रहे हैं?" और वे दोनों कार्य में डूबने लगे। इस तरह के दृष्टिकोण से प्रवाह राज्य का एक संयुग्मन हो सकता है , जिससे उत्पादकता कई गुना बढ़ जाती है।
कम रुकावट: एक जोड़े में, आपको तीसरे पक्ष के कारकों पर कम हस्तक्षेप करना होगा, जैसे दो लोगों का समय एक से अधिक मूल्यवान है, उनका काम 2 गुना अधिक महंगा हो जाता है।

विरोधी पैटर्न

यदि सही ढंग से किया जाए तो पेयर प्रोग्रामिंग अकेले प्रोग्रामिंग की तुलना में अधिक रोचक और रोमांचक हो सकती है। इसके विपरीत, गलत होने पर अकेले काम करने की तुलना में यह भयानक और उबाऊ हो सकता है।

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

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

इसे कैसे ठीक करें?

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

प्रयोज्यता की सीमा

वास्तविक व्यवहार में, जोड़ी प्रोग्रामिंग का उपयोग समय का लगभग 20% होता है , और लगातार नहीं, क्योंकि यह XP की भावना के कारण लग सकता है। बेशक, यह प्रतिशत अनुमानित है और परियोजना पर निर्भर करता है, लेकिन सामान्य तौर पर यह 100% तक नहीं पहुंचता है। फिर भी, कभी-कभी आप बस वापस बैठना चाहते हैं और कोड पर ध्यान देना चाहते हैं, सुंदर के बारे में सोचते हैं और इस कोड को और बेहतर बनाने के विचार को जन्म देते हैं।

बात यह है कि ऐसे कार्य हैं जो जोड़े में करने का कोई मतलब नहीं है:

अनुसंधान कार्य: जब आपको एक अध्ययन करने की आवश्यकता होती है, तो एक अच्छी गूगल करें और वर्तमान समस्या के बारे में विशेषज्ञों के साथ बातचीत करें।
दिनचर्या: जब निम्न चरण बिल्कुल स्पष्ट होते हैं, तो जोड़े में काम करना बहुत उबाऊ हो सकता है।
समानांतर करना आवश्यक है: यदि दो पूरी तरह से अलग-अलग कार्य हैं और समय सीमाएं कस रही हैं, तो जोड़े में बैठना नहीं, बल्कि प्रत्येक को अपना कार्य करना तर्कसंगत है।

आपको यह समझने की आवश्यकता है कि जोड़ी प्रोग्रामिंग मैराथन में जीत दिलाती है और अगर हम छोटी परियोजनाएं करते हैं तो यह लगभग घातक है।

सही ढंग से जोड़ी प्रोग्रामिंग को एक उपकरण के रूप में देखता है, और सभी समस्याओं के लिए रामबाण नहीं है। यह समझने की कोशिश करें कि यह किन स्थितियों में उपयोगी है और इसमें आप इसके बिना क्या कर सकते हैं।

संदर्भ

ExtremeProgramming.org: जोड़ी प्रोग्रामिंग

जोड़ी प्रोग्रामिंग बनाम। कोड समीक्षा

जोड़ी प्रोग्रामिंग लाभ

समीक्षा कोड आपकी आत्मा को बचाएगा

सभी मुझे वास्तव में किंडरगार्टन में सीखे गए पेयर प्रोग्रामिंग के बारे में जानना चाहिए

जोड़ी प्रोग्रामिंग लाभ: दो प्रमुख एक से बेहतर हैं

जोड़ी प्रोग्रामिंग: 100% बाँधना का नुकसान

चरम प्रोग्रामिंग: जोड़ी प्रोग्रामिंग