क्या व्यक्तिगत कोड स्वामित्व महत्वपूर्ण है? [बन्द है]

48

मैं कुछ सहकर्मियों के साथ एक तर्क के बीच में हूं कि क्या पूरे कोडबेस का टीम स्वामित्व इसके घटकों के व्यक्तिगत स्वामित्व से बेहतर है।

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

यह एक (या दो) टीम के सदस्यों के साथ विशिष्ट कार्यक्षमता के ज्ञान को केंद्रित करता है जो बग फिक्स को बहुत आसान बनाता है।

सबसे अधिक, यह एक व्यक्ति के साथ प्रमुख निर्णयों पर अंतिम कहता है, जिनके पास समिति के बजाय बहुत सारे इनपुट हैं।

अगर कोई और आपका कोड बदलना चाहता है तो मैं अनुमति की वकालत नहीं कर रहा हूँ; शायद कोड की समीक्षा हमेशा मालिक के पास हो, सुनिश्चित करें। न ही मैं ज्ञान सिलोस के निर्माण का सुझाव दे रहा हूं: इस स्वामित्व के बारे में कुछ खास नहीं होना चाहिए।

लेकिन अपने सहकर्मियों को यह सुझाव देते समय, मुझे एक टन पुशबैक मिला, निश्चित रूप से मुझे उम्मीद से कहीं अधिक।

इसलिए मैं समुदाय से पूछता हूं: एक बड़े कोडबेस पर एक टीम के साथ काम करने पर आपकी क्या राय है? क्या सामूहिक रूप से स्वामित्व बनाए रखने के बारे में मुझे कुछ याद आ रहा है?

team organization code-ownership

— जिम पल्स
स्रोत

"टूटी हुई खिड़की सिंड्रोम" क्या है? मैं शब्द से परिचित नहीं हूँ।

— उमान

1

टूटी हुई खिड़की का सिंड्रोम: en.wikipedia.org/wiki/Broken_windows_theory

— Pemdas

1

"यह एक (या दो) टीम के सदस्यों के साथ विशिष्ट कार्यक्षमता के ज्ञान को केंद्रित करता है ..." और न ही मैं ज्ञान सिलोस के निर्माण का सुझाव दे रहा हूं "। क्या यह विरोधाभास नहीं है? मेरे लिए, एक / दो सदस्यों के साथ ज्ञान को केंद्रित करना ज्ञान साइलो की परिभाषा है।

— साल्स्के

यह एक अन्य प्रश्न के समान लगता है जो कुछ वर्षों बाद आया था।

— एरिक किंग

46

मेरा मानना है कि लॉन्ग टर्म में टीम ओनरशिप ज्यादा फायदेमंद है।

आपको यह समझने के लिए निम्नलिखित 2 परिदृश्यों को देखने की आवश्यकता है कि लोगों की न्यूनतम संख्या में ज्ञान को ध्यान केंद्रित करना आदर्श से कम क्यों है:

दुर्भाग्यपूर्ण दुर्घटना से टीम के सदस्य मिले
टीम के सदस्य को रोजगार के बेहतर अवसर मिलते हैं

स्वाभाविक रूप से, व्यक्ति / लोग जो विशेष खंड लिखते हैं, उन्हें इसका अधिक ज्ञान होगा, लेकिन उन्हें ज्ञान का एकमात्र साइलो बनाने के लिए प्रलोभन न दें । सिलोस आपको लंबी अवधि के दर्द से अल्पकालिक जीत दिलाएगा।

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

— दान मैकग्राथ
स्रोत

7

एक OO के नजरिए से, दोनों परिदृश्य बनते हैं: "टीम का कोई सदस्य मो के आसपास नहीं है।" "बेहतर रोजगार सेशन" "दुर्भाग्यपूर्ण दुर्घटना" का सिर्फ एक उपवर्ग नहीं है?

— दान रोसेनस्टार्क

4

@ यार: हाँ, हालांकि मुझे लगता है कि आप अभी भी किसी ऐसे व्यक्ति से पूछ सकते हैं जिसने "बेहतर रोजगार" पाया है और अधिक पैसे वापस करने के लिए ... कोई भी राशि उसे बस के नीचे से वापस लाने के लिए नहीं जा रही है :-)

— डीन हार्डिंग

4

मैं अपने समूह के देवों को मूल लेखक के साथ पूछने / जोड़ी बनाने के लिए प्रोत्साहित करता हूं जिस तरह से आपको ज्ञान के कुछ वितरण के साथ तेज बग फिक्स मिलता है।

— आहारबोध

17

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

— जेसन बेकर

4

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

— डैन मैकग्राथ

27

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

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

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

— रॉबर्ट हार्वे
स्रोत

5

+1 स्वामित्व की भावना के कारण बेहतर कोड गुणवत्ता के बारे में बात के लिए। वह निश्चित रूप से मौजूद है।

— परिक्रमा

+1 (+10 यदि मैं कर सकता था): स्वामित्व कोड गुणवत्ता को प्रभावित करता है, न केवल इसलिए कि यह गर्व की भावना देता है और, इसके साथ, एक मजबूत प्रेरणा, लेकिन यह भी क्योंकि यह कोड जटिलता को प्रबंधित करने में मदद करता है, जैसा कि निबंध में बहुत अच्छी तरह से समझाया गया है। "एक के सिर में एक कार्यक्रम धारण करना", paulgraham.com/head.html देखें ।

— जियोर्जियो

19

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

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

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

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

— हारून McIver
स्रोत

5

प्रो टीमों के पास बैकअप क्वार्टरबैक हैं

— स्टीवन ए। लोव

1

@ पहले ही मैंने कहा था कि; लेकिन दोहराए जाने के लिए धन्यवाद ... "क्या आपके पास बैकअप है? निश्चित रूप से आप ... लेकिन टीम के सदस्यों की टीम के भीतर एक पहचान होनी चाहिए। सभी को एक ही मानना एक अलग तरह का दर्द पूछ रहा है।"

— एरोन मैकिवर

एनएफएल टीमों में तीन क्वार्टरबैक हैं, क्रॉस-प्रशिक्षित खिलाड़ी नहीं। स्पोर्ट्स एनालॉग शायद ही कभी आईटी में काम करते हैं ;-)

— स्टीवन ए। लोव

3

@ मुझे पता है कि एनएफएल कैसे काम करता है, इसके बारे में मैं फिर से कहता हूं कि बैकअप मौजूद नहीं है, बल्कि पूरी टीम में उस ज्ञान को फैलाने की कोशिश की जा रही है। डेवलपर्स == खिलाड़ी। अगर हम क्वार्टरबैक == आर्किटेक्ट जैसे टाइटल पेश करना चाहते हैं, लेकिन यह एक एकल टीम को एक लक्ष्य हासिल करने के लिए उकसाता है। हर हफ्ते 45 खिलाड़ी सूट करते हैं और उन 45 खिलाड़ियों में 6.6% को इस बात की जानकारी है कि क्वार्टरबैक पोजिशन को कैसे संचालित किया जाए। मेरे लिए आदर्श लगता है; 75% चाहने वाले इन पदों में से अधिकांश में टीम को क्वार्टरबैक पोजिशन को संचालित करने के बारे में ज्ञान होना चाहिए।

— एरॉन मैकिवर

10

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

इसका कारण यह है कि यदि यह सभी की ज़िम्मेदारी है, तो यह किसी की ज़िम्मेदारी नहीं है।

— जेसन बेकर
स्रोत

+1 के लिए "इसका कारण यह है कि यदि यह सभी की ज़िम्मेदारी है, तो यह किसी की ज़िम्मेदारी नहीं है।"

— कार्तिक श्रीनिवासन

@KarthikSreenivasan: बिल्कुल, और फिर कुछ बेकार टीम के सदस्य (1) कोड में यादृच्छिक परिवर्तन करना शुरू कर देंगे "क्योंकि पूरी टीम कोड का मालिक है" और (2) उन त्रुटियों को ठीक नहीं करना जो वे शुरू करते हैं क्योंकि यह पूरी टीम की जिम्मेदारी है उन्हें ठीक करें"। मुझे लगता है कि व्यक्तिगत स्वामित्व और टीम के स्वामित्व के बीच आदर्श समाधान कहीं और है।

— जियोर्जियो

8

मैं निम्नलिखित कारणों से व्यक्तिगत रूप से टीम का स्वामित्व प्राप्त करूंगा:

पूरे प्रोजेक्ट पर कोड की संगति
कोड की चर्चा को बढ़ावा देता है, जो हमेशा बेहतर, अधिक संश्लिष्ट समाधानों की ओर ले जाता है
यदि एक टीम का सदस्य बीमार (या बदतर) है, तो कोड का एक पूरा खंड देरी के अधीन नहीं है
टीम के सदस्य परियोजना के सभी हिस्सों पर काम कर सकते हैं, जो विकास प्रक्रिया में निर्मित कोड समीक्षा करने का काम करता है

— morganpdx
स्रोत

6

विशेषज्ञता ठीक है - एक बड़े कोडबेस के लिए यह लंबे समय तक संचार का काफी समय बचा सकता है - लेकिन स्वामित्व नहीं है।

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

5

मुझे आपसे असहमत होना है: एक कोडबेस की टीम स्वामित्व व्यक्तिगत स्वामित्व की तुलना में बहुत बेहतर विकल्प है।

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

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

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

— सौरभ शरण
स्रोत

5

मुझे लगता है कि आपको दोनों की आवश्यकता है, क्योंकि दोनों दृष्टिकोणों के बीच एक तनाव है।

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

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

— डेविड कौरन्यू
स्रोत

4

मुझे लगता है कि सामूहिक कोड स्वामित्व व्यक्तिगत कोड स्वामित्व की तुलना में अतुलनीय रूप से बेहतर है।

मैं ट्रक तर्क से परेशान नहीं हूं - एक व्यक्तिगत स्वामित्व मॉडल में, किसी अन्य को लेने के लिए आवश्यक समय के संदर्भ में एक मालिक का नुकसान महंगा है, लेकिन यह घटना काफी दुर्लभ है कि परिशोधन लागत कम है।

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

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

मैं ध्यान देता हूं कि आप व्यक्तिगत कोड स्वामित्व के द्वारा सामूहिक कोड स्वामित्व के कुछ लाभ प्राप्त कर सकते हैं जहां विभिन्न प्रोग्रामर के बीच नियमित रूप से कोड की एक विशेष बिट का स्वामित्व चलता है (जैसे, हर तीन महीने, या हर रिलीज - शायद यहां तक कि हर पुनरावृत्ति?) । क्रॉप रोटेशन के बराबर प्रोग्रामिंग। यह मजेदार हो सकता है। मैं इसे स्वयं कोशिश करने वाला नहीं हूँ, हालाँकि।

— टॉम एंडरसन
स्रोत

1

मुझे नहीं लगता कि टीम कोड स्वामित्व उतना महत्वपूर्ण है जितना कि कई योगदानकर्ता प्रचलित उपप्रणालियों की बुनियादी वास्तुकला को समझते हैं।

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

— Pemdas
स्रोत

0

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

अधिक जिम्मेदारी और कम स्वामित्व पर विचार करें। आखिरकार, जो भी चेक लिख रहा है वह वैसे भी असली मालिक है।

— JeffO
स्रोत

0

जिम, मैं उस 100% पर आपके साथ हूं। मैं अपने काम के स्थान पर बिल्कुल उसी लड़ाई के बीच में हूं - यही कारण है कि मैं आपके सवाल पर ठोकर खाई।

जिस तरह से मैं इसे देखता हूं: "जब हर कोई इसका मालिक होता है, तो कोई भी इसका मालिक नहीं होता है"।

मेरे लिए, स्वामित्व और जिम्मेदारी की तुलना में गुणवत्ता को कोड करने के लिए कोई और महत्वपूर्ण कारक नहीं है।

वास्तविक जीवन से उदाहरण यह अच्छी तरह से वर्णन करता है। जो आप बेहतर देखभाल करेंगे: आपका निजी लॉन या समुदाय का पार्क? काफी सामान्य।

वैसे, "टीम लचीलेपन" के लिए जरूरी नहीं कि इसे बंद कर दिया जाए। इसका मतलब केवल यह है कि जब कोई व्यक्ति किसी चीज़ का मालिक होता है, तो वह उसे करता है - और यदि केवल दिन के लिए।

— acohen
स्रोत

0

मेरे लिए यह आपकी टीम की गतिशीलता पर निर्भर करता है।

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

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

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

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

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

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