चालक और पर्यवेक्षक के पास अलग-अलग कौशल स्तर और अनुभव होने पर जोड़ी प्रोग्रामिंग

Question

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

लेकिन मुझे आश्चर्य है कि मामले में अभी भी रणनीति काम कर रही है। उदाहरण के लिए

• अगर उनके पास एक बहुत अलग प्रोग्रामिंग कौशल स्तर है।
• यदि कोई समस्या क्षेत्र में अनुभव नहीं करता है जबकि दूसरे के पास है।
• क्या यह अभी भी ठीक है अगर उनके पास प्रोग्रामिंग कौशल का स्तर कम है?

क्या आप उपरोक्त मामले में जोड़ी प्रोग्रामिंग रणनीति का सुझाव दे सकते हैं?

Comments

सुनिश्चित करें कि दोनों उच्च कौशल स्तर वाले हैं और दूसरे को कोच करने वाले हैं, इस पर सहमत हैं। यदि ये भूमिकाएं / कौशल स्तर स्पष्ट नहीं हैं, तो जोड़ी प्रोग्रामिंग शायद काम नहीं करेगी और संघर्ष की ओर ले जाएगी।

— जियोर्जियो

लेकिन, जैसा कि आप सुझाव देते हैं, यह सीखने का एक जबरदस्त अवसर हो सकता है।

— मावग

Answer 1

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

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

Comments

माना। मेरे पास टीम में एक जूनियर है और जोड़ी प्रोग्रामिंग में नाटकीय रूप से उनके कोड की गुणवत्ता में वृद्धि हुई है। हालांकि, उनके कोड की जोड़ी-समीक्षा भी बहुत मददगार थी।

— सुल्तान

आपको बस इतना ध्यान रखना है कि वरिष्ठ व्यक्ति 100% चालक नहीं है।

— HLGEM

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

— थॉमस ओवेन्स

मैं @ThomasOwens से सहमत हूं; कम अनुभवी पार्टनर ड्राइव होने से उसका / उसके 'अनुभव' किसी अन्य विधि की तुलना में अधिक तेजी से आएगा, जबकि उन्हें अपने विचारों को साझा करने और अधिक वरिष्ठ साथी के साथ अंतर्दृष्टि प्रदान करने की अनुमति होगी। इससे पहले कि उनकी प्रवीणता का स्तर बहुत करीब न हो जाए।

— एरिक किंग

मुझे आश्चर्य है कि क्या यह वरिष्ठ देव को अभ्यास करने के लिए अधिक बाध्य करता है जो वे उपदेश देते हैं?

— जेफओ

Answer 2

यह वास्तव में उपयोग केस जोड़ी प्रोग्रामिंग के लिए बनाया गया था: पुरानी दाढ़ी और युवा टिड्डे के बीच अनुभव साझा करना।

यह एक दो-तरफा साझाकरण है: फुर्तीले कीड़ों को आमवाती दिमाग को सिखाने के लिए बहुत कुछ है।

Comments

हालाँकि आप शायद मुझे एक मानते हैं, मैं 'आम दिमाग' पर प्यार करता हूँ ...

— Marjan Venema

मुझे नहीं लगता कि "उपयोगकर्ता कहानी" शब्द को यहां लागू किया जा सकता है। उपयोगकर्ता कहानियां एक सॉफ्टवेयर के लिए व्यावसायिक आवश्यकताओं का वर्णन करती हैं।

— कोनराड रुडोल्फ

हाँ, मुझे लगता है कि उसका मतलब है "केस का उपयोग करें"।

— जोर्ग डब्ल्यू मित्तग

डाउनवोट: रणनीति के बारे में कोई शब्द नहीं कि उल्लेखित मामलों से कैसे निपटें।

— कोशिश-कैच-अंत में

Answer 3

जब मुझे मेरी वर्तमान टीम में पदोन्नत किया गया तो मैं J2EE में नौसिखिया था लेकिन मैं डोमेन का विशेषज्ञ था। मेरे वरिष्ठ (नई टीम के नेता) J2EE में कुशल थे, लेकिन मंच में नहीं।

मुझे लगता है कि मैंने इन 4 महीनों में जावा प्रोग्रामिंग के बारे में अधिक जानने के लिए एक पुस्तक पढ़ने की तुलना में जोड़ी प्रोग्रामिंग के साथ और टीम के नेता ने मंच के बारे में भी सीखा।

दोनों के बीच का अनुभव अंतर, प्रोग्रामिंग प्रोग्रामिंग की जोड़ी बनाने की कुंजी है।

Comments

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

— जिमी होफा

Answer 4

मैं अपने अनुभव का वर्णन करूंगा और उसमें से कुछ "रणनीति" प्राप्त करने का प्रयास करूंगा।

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

इस पद्धति का मुख्य लाभ यह था कि मुझे उनके ज्ञान डोमेन से कई चीजों के कार्यान्वयन की व्याख्या करनी थी, इस प्रकार कार्यान्वयन की सटीकता और प्रक्रिया की उनकी समझ को सुनिश्चित करना, जिसका मतलब था कि उन्हें समझ में आया कि इस समय क्यों लिया गया।

एक और लाभ कार्य पर आसान ध्यान केंद्रित है, कोई विचलित नहीं (हा-हा, अपने बॉस की नाक से पहले ट्विटर खोलने की कल्पना करें)।

यह कई बार काफी भयभीत करने वाला था, हालाँकि, जब से एक चाय का विराम भी "काम से विचलित" हो गया था (उनके दृष्टिकोण से नहीं; यह ब्रेक के लिए पूछने के लिए सिर्फ असुविधाजनक था और इसी तरह)।

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

मुझे लगता है कि यह उस मामले में भी बेहतर काम करेगा जब उसके पास कुछ बुनियादी प्रोग्रामर कौशल होंगे, क्योंकि मुझे यह समझाने की ज़रूरत नहीं होगी कि "एक सरणी क्या है"।

आशा करता हूँ की ये काम करेगा :)

Comments

यह अच्छा अनुभवी स्पष्टीकरण है!

— सकारेस

Answer 5

मेरे अनुभव में अगर दोनों प्रोग्रामरों का कौशल स्तर कम है तो यह एक समस्या हो सकती है। उस स्थिति में अक्सर कॉपी-पेस्ट प्रोग्रामिंग की कोशिश करने की प्रवृत्ति होती है। मुझे लगता है कि टीम द्वारा निर्धारित विशिष्ट स्तर तक पहुंचने तक दो नौसिखिए प्रोग्रामर को एक साथ जोड़े नहीं रखना एक अच्छा विचार हो सकता है।

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

Comments

कम कौशल स्तर के देवों को स्वयं प्रोग्रामिंग करते समय कॉपी और पेस्ट करने की संभावना कम होती है? यह आमतौर पर तब होता है जब कोई नहीं देख रहा होता है।

— जेफो

Answer 6

जब तक टीम के सदस्य एक-दूसरे के प्रति सम्मान रखते हैं, प्रोग्रामर के अनुभव के स्तर की परवाह किए बिना जोड़ी प्रोग्रामिंग फायदेमंद हो सकती है। यहां तक ​​कि अगर एक जूनियर प्रोग्रामर कुछ सिंटैक्स त्रुटियों (जो हम सभी बनाते हैं!) को अधिक अनुभवी प्रोग्रामर से पहले स्पॉट करता है, फिर भी कोड संकलित करने में अभी भी समय बचा है।

मुझे यह भी लगता है कि यह उनकी टीम के अन्य सदस्यों की क्षमताओं के प्रति एक प्रोग्रामर के रवैये को खोल सकता है, खासकर अगर उनके पास एक खुला दिमाग है और उम्मीद है कि हर कोई आपको कुछ सिखा सकता है।