जोड़ी प्रोग्रामिंग करते समय आप प्रवाह को कैसे प्राप्त कर सकते हैं और बनाए रख सकते हैं?


17

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

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

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

जोड़ी प्रोग्रामिंग करते समय आप प्रवाह को कैसे प्राप्त कर सकते हैं और बनाए रख सकते हैं?


4
मैं इस बात से सहमत नहीं हूं कि अन्य जोड़ियां किसी भी समय इंटरप्ट कर सकती हैं।
जेफो

3
फ्लो का एक विकल्प बाल्मर चोटी पर स्थिति की पहचान करना और बनाए रखना है । इसे प्राप्त करने के लिए अच्छी मात्रा में प्रयोग, समय और स्कॉच की आवश्यकता हो सकती है।
ईल

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

जवाबों:


15

संपादित करें: अस्वीकरण - यह है कि मैं "जोन" को कैसे परिभाषित करता हूं: A state of extreme focus, in which one is able to understand how many intricate details connect together, regardless of whether these do so elegantly (or simply) or not.

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

द क्लीन कोडर पर एक प्यारा अध्याय है जहां अंकल बॉब ने स्पष्ट रूप से बताया कि "जोन में जाना" एक भ्रमपूर्ण रूप से बुरा विचार है।

यहां "जोन में होने" की तुलना में संभवतः बेहतर विकल्प है: सीधे सोचें और शांति से और पेशेवर रूप से विचार करें कि आप क्या कर रहे हैं। संचार करें। अपने साथी के साथ विचार साझा करें। वास्तविक समस्याओं की पहचान करें। संभावित समाधान पर चर्चा करें। हो सकता है कि आप सुपरनैचुरल रूप से ध्यान केंद्रित न करें, लेकिन आपको अच्छे निर्णय लेने और डिजाइन करने की संभावना है।

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

दूसरी तरफ ... यदि आपको अपने सिर को सीधा करने के लिए कुछ समय की आवश्यकता होती है (हम सभी कभी-कभी करते हैं), बस इसे लें। अपने विचारों को समेटो। पहले अपने सिर में समस्या का समाधान करें।

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


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

7
@HLGEM - मुझे नहीं लगता कि काम करने के लिए बहुत अधिक जगह पर काम करना बहुत जरूरी है।
जेएफओ

2
@ एचएलजीईएम: निश्चित रूप से एक पेशेवर के पास औसत कामकाजी परिस्थितियों में औसत उत्पादकता होनी चाहिए। लेकिन दूसरी ओर यह नियोक्ता के हित में होगा कि वे एक ही पेशेवर काम को बहुत ही फोकस्ड तरीके से करने दें, क्योंकि इससे उत्पादकता और गुणवत्ता बढ़ सकती है।
जियोर्जियो

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

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

5

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

उदाहरण

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


युग्म प्रोग्रामिंग में कार्यान्वयन क्यों नहीं किया जाना चाहिए?
कोशिश-पकड़-अंत में

5

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

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

हां, यह भयावह संभावना को कम कर देता है कि कार्यदिवस के दौरान एक देव स्टैकएक्सचेंज ब्रेक ले सकता है।

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


1
जोड़ी प्रोग्रामिंग का बिंदु एक दूसरे को बंद करने से रोक नहीं रहा है; यह भी प्रभावी नहीं होगा। बिंदु की वास्तविक समय में कोड समीक्षा हो रही है।
लेव

3
@Lev: कमिट करने से पहले कोड की समीक्षा करना अधिक कुशल है: समीक्षा पूरे कार्यदिवस के बजाय कुछ मिनट से लेकर आधे घंटे तक होती है।
जियोर्जियो

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

1
@ लीव: "यदि आपने जोड़ीदार प्रोग्राम किया था, तो आपके साथी ने बग पर ध्यान दिया होगा और डिबगिंग समय को बचाया होगा।": इस बात की कोई गारंटी नहीं है कि बग को जोड़ी प्रोग्रामिंग के साथ या कोड समीक्षाओं के साथ देखा गया है। उदाहरण के लिए, जोड़ी प्रोग्रामिंग के छह घंटे के बाद कोई इतना थक सकता है कि कोई आसानी से बग को नजरअंदाज कर दे।
जियोर्जियो

जाहिर है इसकी कोई गारंटी नहीं है, लेकिन यह मदद कर सकता है।
लेव

3

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

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


0

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

  • कोड डिजाइन

  • टाइपिंग

  • डोमेन और कोड के बारे में नई बातें सीखना

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

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

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