जोड़ी प्रोग्रामिंग के लिए कारण


13

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

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

जैसा कि कोई व्यक्ति विकास की मंजिल के करीब है, जो स्पष्ट रूप से एक किताब से नहीं समझ सकता है, जैसे कि मेरा रास्ता या विषय पर विकी पृष्ठ ... उच्च स्तर के प्रबंधन की स्थिति से, स्क्रेम या एजाइल से निपटने पर पेयर प्रोग्रामिंग के क्या लाभ हैं। वातावरण?


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

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

@JimmyHoffa तो प्रमुख विचार प्रक्रिया यह है कि अगर हम बग को खोजने से पहले ही इसे स्वीकार कर लेते हैं, तो हम कोड समीक्षा / लाइन के परीक्षण में खोए समय को बहुत कम कर सकते हैं?
जेफ लैंगमेयर

3
@JeffLangemeier यह वास्तव में उससे अधिक है; यदि आप सबसिस्टम A के खंड A1 के डिजाइन में खामियां देखते हैं, तो A1 के पहले भी प्राकृतिक प्रवचन के कारण लिखा गया है जो सबसिस्टम ए को लागू करने के बीच में दो डेवलपर्स के बीच होता है, आप न केवल उस समय को बचा रहे हैं जो फिक्सिंग सेक्शन में खर्च होगा ए 1, और ए 5 और ए 7 जो ए 1 पर निर्भर हैं (या ए 1 फिक्सिंग से कैस्केड के कारण उन निर्भर वर्गों में बग ढूंढते हैं), आप उस बुरे सेक्शन को पूरी तरह से नहीं लिखकर समय की बचत कर रहे हैं। यह परीक्षण के समय को कम कर देता है हाँ, लेकिन यह इस तरह से देव समय को और कम कर देता है।
जिमी होफा

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

जवाबों:


25

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

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

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

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

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


महान जवाब के लिए +1। मैं अभी भी विचार को दृढ़ता से नापसंद करता हूं, लेकिन आप इसके लाभों को अच्छी तरह से प्रस्तुत करते हैं।

मुझे आपके जिब सर का कट पसंद है, यह स्पष्टीकरण वास्तव में यह व्यवहार्य लगता है।
जेफ लैंगमेयर

9
मैं एक हाइब्रिड मॉडल पसंद करता हूं, जहां मौजूदा जरूरतों के आधार पर पेयरिंग अधिक तदर्थ हैं। इसके अलावा, ऐसे समय होते हैं जब अकेले काम करना अधिक कुशल होता है और ऐसा समय जब साथी के साथ काम करना बेहतर होता है। स्थायी जोड़े में मजबूर होना मेरे लिए मनमाना और अनम्य है।
1

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

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

3
  1. अंतिम कोड (दक्षता) में कम त्रुटियां
    पूरी तरह से कोड समीक्षा की जगह नहीं लेती हैं, लेकिन चीजों को जल्दी शुरू करने के लिए अत्यधिक प्रभावी हैं। वहाँ अनुसंधान है कि उस दिशा में बताते हैं।

  2. तेजी से पूर्णता (प्रभावशीलता)
    इस ओर इशारा करते हुए कई शोध हैं। जब जटिल विशेषताओं की बात आती है तो 2 सिर बस अधिक प्रभावी होते हैं। पेयरिंग में अनुभव इसके लिए जरूरी है।

(ध्यान दें: यह प्रबंधक के लिए आपकी सलाह है: वित्तीय रूप से एक महत्वपूर्ण निर्णय क्योंकि आपको अधिक कुशल गर्त कम कीड़े मिलते हैं और तेजी से पूरा होने से अधिक प्रभावी होते हैं)

  1. शिक्षण जूनियर्स
    आप एक जूनियर को अधिक अनुभवी प्रोग्रामर से सीधे जोड़ सकते हैं। यदि आपके पास पूर्ण शुरुआती लोगों का एक समूह है, तो आस-पास रहना आसान है और उन्हें जोड़े के रूप में, मूल बातें समझ लें। चारों ओर छड़ी और सलाह दे। अवधारणा स्पष्ट रूप से बहुत पुरानी है और शिल्प कौशल से उपजी है।

3

त्वरित उत्तर: अधिकांश लाभ और लागत हालांकि विकिपीडिया में पोस्ट किए गए हैं , आइए इसे एक बिटिफायरेंट कोण से देखें।

मैं जोड़ी प्रोग्रामिंग लाभों के विशिष्ट मामलों का उल्लेख करना चाहूंगा जो ब्लॉग पोस्ट से लिए गए चुस्त / विकसित विकास परिवेश पर लागू होते हैं :

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

संक्षेप में:

  • टीम संचार को बढ़ावा देता है
  • कुशल अनुप्रयोग ज्ञान हस्तांतरण को बढ़ावा देता है
  • डिजाइन दृष्टिकोण पर जवाबदेही को बढ़ावा देता है
  • कोड बनाए रखने के लिए बेहतर, आसान परिणाम
  • अपने शुरुआती चरण में छोटी गाड़ी कोड को खत्म करने में मदद करता है
  • टीम की उत्पादकता बढ़ाता है क्योंकि टीम के सदस्य कोडिंग के दौरान अविभाजित होंगे
  • टीम के सदस्यों के संचार और सहयोग कौशल में सुधार करता है
  • कार्यस्थल पर ऊदबिलाव बनाता है
  • अधिक मजेदार काम करता है

When two developers work together design pattern quality improves-> उस वाक्यांश का कोई मतलब नहीं है। कम से कम When two bakers work together wheat quality improvesया उससे अधिक समझदारी नहीं When two race drivers work together asphalt quality improves
फोल्डेलिन

यह ब्लॉग का एक उद्धरण है जिसे आप देख सकते हैं। हालाँकि, मेरा इरादा कुछ प्रकार की जवाबदेही के साथ तकनीकी डिजाइन और कोड की गुणवत्ता पर बेहतर ध्यान केंद्रित करना था, क्योंकि प्रत्येक डेवलपर उस कोड पर गर्व करने का प्रयास करता है जो बनाया जाता है।
युसुबोव

2

जोड़ी प्रोग्रामिंग के लिए कुछ लाभ हैं:

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

विकी की विकी प्रविष्टि में लागत और लाभों का अच्छा सारांश है ।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.