2009-04-06 16 views
7

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

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

अद्यतन

मैं कोई डिजाइन मतलब नहीं है, मैं कोई प्रलेखन मतलब। जोड़ी प्रोग्रामिंग का अभ्यास करने वाली एक टीम के साथ मुझे लगता है कि हर कोई डिस्पोजेबल है, क्योंकि हर कोई कोड जानता है। यदि वरिष्ठ डेवलपर छोड़ देता है, तो मुझे लगता है कि कम से कम एक व्यक्ति होता है जो कोड जानता है, क्योंकि अनुभव पहले साझा किया गया था।

+0

क्या आप का मतलब है कि कोई डिज़ाइन नहीं है या कोई दस्तावेज नहीं है? –

+0

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

+1

"हर कोई डिस्पोजेबल है?" वाह, कठिन समय सब खत्म हो गया ... –

उत्तर

12

यदि आपकी टीम 2 व्यक्तियों से बड़ी है तो क्या होगा?

सिर्फ इसलिए कि दो लोगों को सिस्टम का एक हिस्सा पता है इसका मतलब यह नहीं है कि इसे दस्तावेज नहीं किया जाना चाहिए।

और मुझे यह जानकर ख़ुशी होगी कि मुझे सिस्टम के हर छोटे विवरण को याद रखने की ज़रूरत नहीं है क्योंकि यह मेरे सिर की तुलना में कहीं और नहीं है।

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

+0

यदि आपकी टीम दो व्यक्तियों से बड़ी है, तो आप किसी ऐसे व्यक्ति से जुड़ते हैं जो जानता है कि कोड कैसे काम करता है ' फिर से संशोधित/डीबग/फिर से सोचने के लिए माना जाता है। मुझे लगता है कि बहुत सी जोड़ी प्रोग्रामिंग के साथ बहुत से लोग कोड जानते हैं। –

+1

एक बड़ी प्रणाली के बारे में सोचें, नए आदमी को सिखाए जाने के लिए सहकर्मी-प्रोग्रामिंग के कितने घंटे की आवश्यकता होगी कि सिस्टम कैसे काम करता है? मैं सलाह दूंगा कि नया लड़का पहले पढ़ेगा, और डीबगिंग/रीफैक्टरिंग के पहले कुछ दिनों के लिए जोड़ी प्रोग्रामिंग करने की सलाह देगा। –

+1

यदि आपकी टीम में 4 (12 और 34) व्यक्ति शामिल हैं, तो 2 टीमों को डिज़ाइन कैसे पता चलेगा? आपको एक डिज़ाइन की आवश्यकता है अन्यथा आपको एक लैंडर स्टार्टअप समय चाहिए। पहले 1 और 2 एक साथ काम करते हैं, फिर 1 के साथ 3 और 2 के साथ काम करता है 4. – RvdK

1

पहले लिखित कोड के बारे में कौन जानता है? जवाब कोई नहीं जानता है, क्योंकि यह लिखा नहीं गया है। इसका कारण यह नहीं लिखा गया है क्योंकि कोई भी नहीं जानता कि क्या करना है, इसलिए डिज़ाइन दस्तावेज़ की आवश्यकता है।

4

क्या आपने कभी "टेलीफोन" खेला है? मुझे नहीं लगता कि आपको इसे अपने कोडबेस के साथ खेलना चाहिए।

4

क्या होगा अगर वरिष्ठ प्रोग्रामर कंपनी/परियोजना छोड़ देता है?

+0

+1: लॉटरी जीतता है, एक बेंटले खरीदता है और उस ज्ञान से दूर चला जाता है। –

+0

एक स्थान पर मैंने काम किया, मेरे प्रबंधक ने सभी लॉटरी पूलों का हिस्सा होने पर जोर दिया। अगर हम सभी बाहर निकलते हैं, तो वह गड़बड़ी से निपटने के लिए फंसना नहीं चाहता था। –

0

कोड बेस इतना बड़ा हो सकता है कि आप जो भी लागू करना चाहते हैं उसके हर विवरण को मानवीय रूप से याद नहीं कर सकते हैं। इस मामले में एक संदर्भ उपयोगी है।

इसके अलावा, आप एक डिजाइन की जरूरत है अगर आप अन्य घटकों आदि

3

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

+0

मैं आपसे सहमत हूं। –

0

जोड़ी प्रोग्रामिंग केवल आपके कोडिंग और तार्किक पहलू को सक्षम बनाता है।

लेकिन दस्तावेज़ीकरण अच्छी प्रथा है। हमेशा दस्तावेज करें ...

+0

आप कार्य वितरित कर सकते हैं, एक व्यक्ति सोच और दस्तावेज करेगा। अन्य व्यक्ति कोड कर सकते हैं ... यह आपके लिए काम करेगा ???? –

4

डिलिवरेबल्स का सेट स्वतंत्र रूप से तय किया जाना चाहिए कि आप जोड़ी प्रोग्रामिंग का उपयोग करते हैं या नहीं।

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

लेकिन एक साल बाद आपको डिजाइन करने वाले दो लोगों पर भरोसा न करें।

2

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

जोड़ी प्रोग्रामिंग ज्ञान फैलती है, लेकिन यह उस ज्ञान को दस्तावेज़ में कभी दर्द नहीं देती है।

+0

ट्रक कारक मुझे पता नहीं था कि +1;) –

0

आप किसी वर्ड प्रोसेसर एक डिज़ाइन दस्तावेज़ उपयोग उपयोगी :-) के बजाय एक स्प्रेडशीट प्रोग्राम चाहते हैं अच्छी तरह से करता है, तो

एक्सपी, जोड़ी कार्यक्रमों की, चुस्त, आदि ... मतलब यह नहीं है कि आप एक योजना नहीं है यह, क्या हो रहा है इसकी एक बहुत ही कम विस्तृत योजना (सूक्ष्म स्तर पर) है। उपयोगकर्ता द्वारा उपयोग किए जाने वाले उपयोग के मामले अधिकतर डिज़ाइन हैं, और यह डिज़ाइन/प्रोग्रामिंग की अन्य शैलियों की तुलना में एक जीवित दस्तावेज़ है।

जाल में मत आना क्योंकि आप कुछ "शांत" कर रहे हैं कि अब आपको अच्छे प्रथाओं की आवश्यकता नहीं है - वास्तव में प्रोग्रामिंग की इस शैली को सफल होने के बजाय अधिक अनुशासन की आवश्यकता होती है।

1

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

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

1

लोगों का अनुभव कोड के साथ समन्वयित हो सकता है, जैसा कि आप कहते हैं। लेकिन डिज़ाइन निर्णय सभी कोड में नहीं पकड़े गए हैं - केवल वही विकल्प हैं।

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

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

0

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

आप कुछ प्रयोगों की कोशिश कर सकते: -

  • दस्तावेज़ डिजाइन के छोटे भागों की एक जोड़ी और ध्यान दें कि आप कितनी बार यह उल्लेख करने के लिए किया है।
  • दस्तावेज़ सामग्री जो हमेशा दर्द होता है के साथ काम करने के लिए।
0

नहीं न ही जोड़ी प्रोग्रामिंग की कमी का मतलब है कि आपको दस्तावेज़ों की आवश्यकता है। दस्तावेज़ीकरण की आवश्यकता है! ऐसा लगता है कि आपको आश्चर्य हो सकता है!

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

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

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

तो, नीचे पंक्ति, जोड़ी प्रोग्रामिंग बेहतर दस्तावेज उत्पन्न करता है। यह दस्तावेज़ीकरण को खत्म नहीं करता है (हालांकि आप वर्ड दस्तावेज़ नहीं ढूंढ पाएंगे)।

0

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

1

"डिज़ाइन दस्तावेज़" द्वारा आपका क्या मतलब है निर्भर करता है। तो विशेष रूप से व्यवहार चालित विकास (BDD) परीक्षण, या Fitnesse या फिट परीक्षण वे निश्चित रूप से "सक्रिय प्रलेखन" का एक रूप हो ... और वे निश्चित रूप से और साथ ही मूल्य है -

आप कार्यात्मक परीक्षण है, तो रिग्रेशन परीक्षण होने के नाते।

आप उपयोगकर्ता कहानियों को लिखने और जोड़े तो आप प्रलेखन का एक रूप कर रहे हैं करने के लिए कार्यों में उन्हें नीचे तोड़ने के लिए और कार्ड पर उन कार्यों लिखते हैं ...

उन के दो मुख्य प्रकार हैं प्रलेखन मैंने XP टीमों में उपयोग किया है जो सभी उत्पादन कोड पर जोड़े जाते हैं।

एकमात्र अन्य दस्तावेज जो मुझे काफी आसान लगता है वह आधे पृष्ठ या बुलेट बिंदुओं का सेट है जो लोगों को विकास मशीन के लिए निर्माण वातावरण स्थापित करने का तरीका दिखाता है। जब आप इसका उपयोग करते हैं तो आपको सूची बनाए रखना चाहिए।

संबंधित मुद्दे