* कोड स्वामी * प्रणाली: क्या यह एक कुशल तरीका है? [बन्द है]

50

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

प्लस साइड पर, प्रस्तावित दृष्टिकोण के साथ माना जाता है कि हम सामान्य विकास के समय को बचाते हैं, क्योंकि प्रत्येक डेवलपर कोड के अपने हिस्से को अच्छी तरह से जानता है और तेजी से सुधार करता है। नकारात्मक पक्ष यह है कि डेवलपर्स सिस्टम को पूरी तरह से नहीं जानते हैं।

क्या आपको लगता है कि दृष्टिकोण मध्यम आकार की प्रणाली (सामाजिक नेटवर्क साइट के विकास) के लिए अच्छी तरह से काम करेगा?

project-management code-ownership

— sergzach
स्रोत

23

मैंने इस तरीके से काम किया है और मैं हमेशा कोड बदलने के लिए समाप्त हो गया जो मेरे पास नहीं था। चूंकि कोड "मेरा" नहीं था, इसलिए यह हमेशा किसी को नाराज करता था और बदलाव के लिए कोड को कभी भी प्रलेखित या परीक्षण नहीं किया गया था। मेरे द्वारा स्वामित्व वाली परियोजनाओं में, मैंने हमेशा समूह स्वामित्व को तेजी से एकीकरण (लंबे विलय को रोकने के लिए) के साथ प्रोत्साहित किया।

— डैनी वारोड

26

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

— maple_shaft

6

मैंने पूरी तरह से यह सवाल बहुत समय पहले पूछा था: प्रोग्रामर.स्टैकएक्सचेंज.

— com

7

लगता है जैसे वह खुद को अपूरणीय होने में कोड करने की कोशिश कर रहा है।

— इयान होल्डर

6

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

— स्कॉट व्हिटलॉक

37

इन सवालों में से कई की तरह, मुझे लगता है कि जवाब है:

निर्भर करता है

यह मानने का कारण है कि स्थिति लेने के लिए कि प्रत्येक प्रोग्रामर को पता होना चाहिए कि कोड की हर पंक्ति गुमराह है।

अगर हम एक पल के लिए मान लें कि किसी को कोड के टुकड़े की गहरी समझ है, तो किसी ऐसे व्यक्ति की तुलना में 5 गुना तेजी से बदलाव होगा जो इसे बिल्कुल नहीं जानता है (मेरे अनुभव में विश्वास की एक विशाल छलांग नहीं) और इसमें लगभग एक महीने का समय लगता है कोडिंग अनुभव को एक काफी आकार के मॉड्यूल की अच्छी समझ प्राप्त करना (यह भी अनुचित नहीं है) तो हम कुछ (पूरी तरह से फर्जी और काल्पनिक) नंबर चला सकते हैं:

प्रोग्रामर A: की गहरी समझ है
प्रोग्रामर B: कोई नहीं

कहते हैं कि प्रोग्रामर A को प्रति दिन 1 यूनिट काम मिलता है। 5 कार्यदिवस के 4 सप्ताह में वह 20 इकाइयों को काम दे सकता है।

तो प्रोग्रामर बी, प्रति दिन 0.2 इकाइयों का काम शुरू कर रहा है, और अपने 20 वें दिन (21 वें दिन वे प्रोग्रामर ए के रूप में अच्छे हैं) पर काम के 0.96 इकाइयों के साथ समाप्त हो रहे हैं, उसी में 11.6 यूनिट काम पूरा करेंगे 20 दिन की अवधि। उस महीने के दौरान प्रोग्रामर बी ने प्रोग्रामर ए के साथ तुलना में 58% दक्षता हासिल की। हालांकि, अब आपके पास एक और प्रोग्रामर है जो उस मॉड्यूल के साथ-साथ पहले वाले को भी जानता है।

बेशक, एक सभ्य आकार की परियोजना पर, आपके पास हो सकता है ... 50 मॉड्यूल? तो उन सभी से परिचित होने में आपको लगभग 4 साल लगते हैं, और इसका मतलब है कि सीखने वाला प्रोग्रामर औसतन, प्रोग्रामर ए ... हम्म की तुलना में 58% दक्षता पर काम कर रहा है।

इसलिए इस परिदृश्य पर विचार करें: एक ही प्रोग्रामर, एक ही प्रोजेक्ट (A यह सब जानता है, और B इसे कोई भी नहीं जानता है।) कहते हैं कि वर्ष में 250 कार्य दिवस हैं। मान लें कि वर्कलोड को 50 मॉड्यूलों पर बेतरतीब ढंग से वितरित किया गया है। यदि हम दोनों प्रोग्रामर को समान रूप से विभाजित करते हैं, तो ए और बी दोनों को प्रत्येक मॉड्यूल पर 5 कार्य दिवस मिलते हैं। A प्रत्येक मॉड्यूल पर 5 यूनिट काम कर सकता है, लेकिन B केवल मेरे छोटे एक्सेल सिमुलेशन के अनुसार, प्रत्येक मॉड्यूल पर किए गए 1.4 यूनिट काम करता है। कुल (ए + बी) प्रति मॉड्यूल 6.4 यूनिट काम है। ऐसा इसलिए है क्योंकि B अपना अधिकांश समय बिना किसी कौशल के मॉड्यूल पर काम कर रहे हैं।

इस स्थिति में, मॉड्यूल के एक छोटे उपसमुच्चय पर B ध्यान केंद्रित करना अधिक इष्टतम है। यदि B केवल 25 मॉड्यूल पर ध्यान केंद्रित करता है, तो उन्हें प्रत्येक पर 10 दिन मिलते हैं, प्रत्येक पर 3.8 यूनिट काम करते हैं। प्रोग्रामर A तब प्रत्येक 25 मॉड्यूल पर 7 दिन बिता सकता है, जिस पर B काम नहीं कर रहा है, और 3 दिन प्रत्येक एक ही पर काम कर रहा है। B. कुल उत्पादकता 6.8 से 7 इकाइयों तक प्रति मॉड्यूल औसत 6.9 है, और यह काफी अधिक है। 6.4 यूनिट प्रति मॉड्यूल की तुलना में हमने ए और बी समान रूप से काम फैलाया।

जैसा कि हम उन मॉड्यूलों के दायरे को सीमित करते हैं जो B काम करता है, हम और भी अधिक दक्षता प्राप्त करते हैं (एक बिंदु तक)।

प्रशिक्षण

मैं यह भी तर्क दूंगा कि जो कोई मॉड्यूल के बारे में ज्यादा नहीं जानता है, वह उस व्यक्ति को बाधित करेगा जो अधिक अनुभव वाले किसी व्यक्ति की तुलना में बहुत अधिक करता है । तो ऊपर दिए गए इन नंबरों पर ध्यान नहीं दिया जाता है कि B जितना अधिक समय कोड पर खर्च करता है, उन्हें समझ में नहीं आता है, A का अधिक समय वे प्रश्न पूछकर उठाते हैं, और कभी-कभी बी ने जो किया उसे ठीक करने या उसका निवारण करने में मदद करते हैं। किसी को प्रशिक्षित करना एक समय लेने वाली गतिविधि है।

सर्वोतम उपाय

इसलिए मुझे लगता है कि इष्टतम समाधान जैसे प्रश्नों पर आधारित होना चाहिए:

आपकी टीम कितनी बड़ी है? क्या यह समझ में आता है कि हर किसी को हर हिस्से पर प्रशिक्षित किया जाता है, या अगर हमारे पास 10 व्यक्ति टीम है, तो क्या हम यह सुनिश्चित कर सकते हैं कि प्रत्येक मॉड्यूल कम से कम 3 लोगों द्वारा जाना जाए? (10 प्रोग्रामर और 50 मॉड्यूल के साथ, प्रत्येक प्रोग्रामर को 3x कवरेज प्राप्त करने के लिए 15 मॉड्यूल जानना होगा।)
आपका कर्मचारी कैसा है? यदि आप हर 3 साल में औसतन कर्मचारियों को बदल रहे हैं, और सिस्टम के हर कोने को जानने में इससे अधिक समय लगता है, तो वे खुद को वापस भुगतान करने के लिए प्रशिक्षण के लिए लंबे समय तक नहीं रहेंगे।
क्या आपको वास्तव में एक समस्या का निदान करने के लिए एक विशेषज्ञ की आवश्यकता है? बहुत सारे लोग इस बहाने का उपयोग करते हैं, "क्या होगा अगर वह व्यक्ति छुट्टी पर जाता है", लेकिन मुझे कई बार एक प्रणाली में एक समस्या का निदान करने के लिए बुलाया गया है जिसका मुझे कोई अनुभव नहीं है। यह सच हो सकता है कि अनुभवी व्यक्ति इसे बहुत तेज़ी से पा सकता है, लेकिन इसका मतलब यह नहीं है कि आप उनके बिना एक या दो सप्ताह तक नहीं रह सकते। कुछ सॉफ्टवेयर सिस्टम इतने महत्वपूर्ण हैं कि समस्या का निदान 5 घंटे के बजाय 1 घंटे में किया जाना चाहिए या दुनिया समाप्त हो जाएगी। आपको इन जोखिमों का वजन करना होगा।

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

— स्कॉट व्हिटलॉक
स्रोत

3

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

— पूली

1

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

— स्कॉट व्हिटलॉक

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

— सर्जक

76

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

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

— टॉम स्क्वायर्स
स्रोत

5

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

— रॉबर्ट हार्वे

1

कोड स्वामित्व की सबसे बड़ी समस्याओं में से एक है क्रमांकन। क्या होता है जब 90% काम एक व्यक्ति के क्षेत्र में निहित होता है? क्या बाकी टीम को अपने अंगूठे पर बैठकर इंतजार करना चाहिए?

— नील टिबरेला

5

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

— एलेक्स

3

@ रोबर्ट हार्वे: टीम सभी कोड का मालिक है ।

— स्टीवन ए लोव

2

"भयानक विचार" बहुत मजबूत है। लिनक्स कर्नेल उस मॉडल का उपयोग करता है और ऐसा लगता है कि यह अच्छी तरह से काम किया है।

— जोह

28

यह इस बात पर निर्भर करता है कि समस्या का डोमेन क्या है।

यदि यह सामान्य सामान है (यानी साधारण सीआरयूडी कार्रवाई आदि), तो मैं टॉम स्क्वायर्स से सहमत हूं (किसी को भी इस पर काम करने और इसे संपादित करने में सक्षम होना चाहिए)।

हालांकि ...

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

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

— डेमियन ब्रेख्त
स्रोत

2

किनारे के मामलों के बारे में अच्छी बात है। +1

— टॉम स्क्वॉयर

1

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

— डेमियन ब्रेख्त

क्षमा करें, थक गया था और उस हिस्से को याद किया।

— डैनी वारोड

+1 मुझे लगता है कि यह एकमात्र उत्तर है जो इंगित करता है कि स्वामित्व के विभिन्न स्तरों में परियोजना के आधार पर गुण हो सकते हैं।

— थॉमस लेविने

1

मैं वास्तव में इसे स्वामित्व के रूप में नहीं देखता हूं। कोड समीक्षाएं प्राकृतिक हैं (हाँ, प्राकृतिक), और यह स्वाभाविक है कि किसी विशेष सबसिस्टम पर सबसे विशेषज्ञ डेवलपर इस सबसिस्टम में परिवर्तनों की समीक्षा करेगा।

— मैथ्यू एम।

10

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

यह एक बात पर उबलता है: अनुशासन । कितने अकेले प्रोग्रामर जानते हैं जो वास्तव में अपनी कोडिंग शैली में अनुशासित हैं? जब आप अनुशासन के साथ कोड नहीं करते हैं, तो आप शॉर्टकट लेते हैं (क्योंकि आप "इसे बाद में ठीक कर लेंगे") और कोड की स्थिरता बनी रहती है। हम सभी जानते हैं "बाद में" कभी नहीं आता है। तथ्य : जब आप किसी टीम में अपने साथियों के लिए तुरंत जवाबदेह होते हैं, तो शॉर्टकट लेना कठिन होता है। क्यों? क्योंकि आपके निर्णयों पर सवाल उठाए जाएंगे और शॉर्टकट्स को सही ठहराने के लिए यह हमेशा कठिन होगा। अंतिम परिणाम? आप बेहतर, अधिक रख-रखाव कोड का उत्पादन करते हैं जो अधिक मजबूत भी है।

— कार्ल
स्रोत

9

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

एक समझौता कोड के प्रत्येक क्षेत्र के लिए कम से कम 2 मालिकों का होना होगा। फिर कोई छुट्टी पर जा सकता है, नई नौकरी ले सकता है, या रिटायर हो सकता है, और अभी भी कोई है जो कोड जानता है (और नए व्यक्ति को प्रशिक्षित कर सकता है)। हर किसी को सब कुछ सीखने की ज़रूरत नहीं है, जो थोड़ा अधिक कुशल है।

एक ही 2 (या 3) नहीं है लोग हर समय एक साथ काम करते हैं। अलग-अलग क्षेत्रों के लिए जोड़े स्विच करें, इसलिए संबंधित कार्यक्रम क्षेत्र के किसी अलग व्यक्ति के साथ काम करते समय ज्ञान अनजाने में भी साझा किया जाता है।

— thursdaysgeek
स्रोत

1

या, दूसरे शब्दों में, आप XP :-)

— डैनी वारोड

6

हां, अल्पावधि में यह थोड़ा अधिक कुशल है। और वहाँ लाभ समाप्त होता है। यह भी लागत outweighing के करीब नहीं आता है।

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

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

यह कहने के लिए नहीं है कि, 50 डेवलपर्स की टीम पर, सभी को सभी कोड पता होना चाहिए, लेकिन 5-7 लोगों की एक टीम के पास इतना बड़ा मॉड्यूल होना चाहिए कि वह उन लोगों को काम करने में सक्षम बना सके। किसी भी व्यक्ति के पास कुछ भी नहीं होना चाहिए।

— PDR
स्रोत

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

— वेटिन

1

@Vatine: सही है। इसलिए आप अपने कोड को मॉड्यूल में तोड़ते हैं और प्रत्येक मॉड्यूल पर काम करने वाली एक टीम होती है। आपके पास अभी भी एक व्यक्ति के स्वामित्व वाले कोड का एक टुकड़ा नहीं है।

— पीडीआर

हां, इसे एकल व्यक्तियों (शायद) के लिए तोड़ने का कोई मतलब नहीं है, लेकिन निश्चित रूप से "कोडबेस के विभिन्न हिस्सों के लिए अलग-अलग स्वामित्व" के लिए कुछ तर्क हैं।

— वेटिन

6

कम से कम तीन मुद्दे हैं जो अन्य उत्तर बताते हैं; लेकिन मैं कोशिश करना चाहूंगा और दोनों का एक साथ इलाज करूंगा। दो मुद्दे हैं:

विशेषज्ञता : किसी टीम पर किसी विशेष क्षेत्र के बारे में विस्तृत ज्ञान है; यह ज्ञान परियोजना में उस डोमेन के विशिष्ट कार्यान्वयन से स्वतंत्र है
नेतृत्व : हालांकि परियोजना के निर्माण का काम कई डेवलपर्स में साझा किया जा सकता है; रोडमैप, साथ ही महत्वपूर्ण कार्यान्वयन विवरण के बारे में तत्काल निर्णय किसी विशेष टीम के सदस्य या टीम के केवल कुछ सदस्यों के हाथों में होते हैं।
अहंकार रहित कोड : परियोजना को लागू करने का विशेष तरीका टीम पर किसी विशेष डेवलपर की कोडिंग शैलियों, प्रथाओं या ज्ञान पर निर्भर नहीं है; और एक अच्छी तरह से ज्ञात कोडिंग शैली या एक अच्छी तरह से सुसज्जित विनिर्देश के सख्त पालन से, किसी भी नए टीम के सदस्य के पास अनुभवी देवों के रूप में परियोजना के हाव-भाव को समझने का एक समान मौका है।

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

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

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

— SingleNegationElimination
स्रोत

6

कोड के स्वामित्व को रोकने के लिए जाता है, विकास की अड़चनें पैदा करते हैं और कोड की समस्याओं से निपटने के लिए अहंकार की समस्या पैदा करते हैं।

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

— डैनी वारोड
स्रोत

5

यह बहुत सारे कारणों से खराब है, मैंने एक दुकान में काम किया, जहां उन्होंने इसे कुछ अधिक उचित तरीके से बदलने की कोशिश की और यह बदसूरत था।

इसके खराब होने के कारण:

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

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

बेहतर तरीका यह है कि हर कोई कोड बेस (या एक आधा दर्जन भागों या तो यह वास्तव में बड़ा और विविध है) के प्रत्येक भाग से परिचित हो सकता है कि वे कर सकते हैं

उस क्षेत्र के किसी भी दोष को ठीक करें
मामूली या मध्यम नई सुविधाएँ या संवर्द्धन जोड़ें

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

एकमात्र कोड स्वामित्व के लिए समर्थक यह है कि "कोड स्वामी" संभवतः दूसरों की तुलना में तेज़ी से काम कर सकता है, लेकिन यह केवल सच है अगर हर कोई गैर-अतिव्यापी परियोजनाओं पर "कोड स्वामी" है। दूसरे शब्दों में, यदि लोग "एकमात्र कोड स्वामी" के लाभ के चारों ओर घूमते हैं, तो चले जाते हैं।

— शीघ्र
स्रोत

2

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

— रॉबर्ट हार्वे

5

देखें ट्रक नंबर उर्फ बस फैक्टर

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

"बस से टकरा जाना" कई अलग-अलग रूप ले सकता था। यह एक नया काम करने वाला व्यक्ति हो सकता है, एक बच्चा हो सकता है, अपनी जीवन शैली या जीवन की स्थिति को बदल सकता है, या सचमुच बस से टकरा सकता है: प्रभाव समान होगा ...

— यहोशू ड्रेक
स्रोत

स्रोत के ऐतिहासिक महत्व को देखते हुए मुझे लगा कि यह आधिकारिक है। en.wikipedia.org/wiki/WikiWikiWeb यह लगभग 4 वर्षों से बस फैक्टर के सामान्य उपयोग की भविष्यवाणी करता है।

— जोशुआ ड्रेक

1

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

— Vatine
स्रोत

1

नुकसान गंभीर है; आपकी टीम का "ट्रक नंबर" बहुत अधिक हो जाता है।

समीक्षा करने के लिए, "ट्रक नंबर" को केवल इस रूप में परिभाषित किया गया है "टीम के कितने सदस्य, सबसे खराब स्थिति, किसी महत्वपूर्ण कार्य को करने के लिए आवश्यक ज्ञान को टीम से हारने से पहले एक ट्रक द्वारा मारा जा सकता है।"

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

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

— Keiths
स्रोत

1

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

कार्यभार और शेड्यूलिंग समस्याएँ इसे अधिलेखित कर देंगी। यह एक प्रमुख बग को ठीक करने के लिए मूर्खतापूर्ण होगा क्योंकि अपराधी दो सप्ताह की छुट्टी पर है।

लक्ष्य आपकी टीम को "दोष खेल" खेलना नहीं है या बग को बहुत दूर ले जाता है (वे वैसे भी सभी समान नहीं हैं)। यह आधार पर कि किसने आखिरी में कोड की जाँच की या एक पर्यवेक्षक ने निर्णय लिया और इसे कोड की हर पंक्ति के हर हिस्से से गुजरने के बजाय किसी को सौंप दिया।

बेहतर प्रोग्रामर शायद अन्य लोगों के कोड का एक बहुत कुछ तय करते हैं, चाहे आप इसे कैसे भी निर्दिष्ट करें।

— JeffO
स्रोत