1. घर
  2. सवाल और जवाब
  3. मैं ट्रंक को बेकार नए शौक से कैसे बचा सकता हूं?

मैं ट्रंक को बेकार नए शौक से कैसे बचा सकता हूं?

2009-05-07 11 views
25

एक सहकर्मी निम्न समस्या रिले, चलो कहना यह दोषी की रक्षा के लिए काल्पनिक है:मैं ट्रंक को बेकार नए शौक से कैसे बचा सकता हूं?

5-10 के एक दल ने एक परियोजना है जो इस मुद्दे पर ही आधारित है पर काम करता है। यही है, ठेठ प्रवाह इस प्रकार है:

  1. काम (बग, वृद्धि, आदि) का एक हिस्सा इस मुद्दे को एक डेवलपर के लिए असाइन किया गया है समस्या ट्रैकर
  2. में एक मुद्दे के रूप में बनाई गई है
  3. डेवलपर समस्या का समाधान और उनके कोड ट्रंक
  4. में परिवर्तन रिलीज के समय, जमे हुए पर करता है, और भारी ट्रंक परीक्षण या जारी शाखा या जो कुछ भी रिलीज़ मोड में बनाया गया है और
समस्या वह मैं कर रहा है

जारी किया कि कुछ नए शौकियों ने कई बुरी आदतों को जन्म दिया जो घटनाओं की दुर्भाग्यपूर्ण श्रृंखला के कारण पकड़े नहीं गए थे। इसके बाद हॉट फिक्स के रोलबैक या फ्लोरी के साथ खराब रिलीज हुआ।

एक विचार हम साथ कर रही हैं:

निरस्त नवागंतुकों के लिए ट्रंक के लिए उपयोग करने के लिए और उन्हें एक प्रति डेवलपर शाखा पर विकसित कर (हम SVN का उपयोग कर रहे):

  • अच्छा है: newbies के अलग हैं और दूसरों को चोट नहीं कर सकते हैं
  • अच्छा: कमिटर ट्रंक के साथ नौसिखिया शाखाओं विलय अक्सर
  • अच्छा है: इस कठोर कोड की समीक्षा
  • बुरा लागू करता है: यह भारी है Committers पर (लेकिन कोड की समीक्षा के बाद शायद इसके आसपास कोई रास्ता नहीं है!)
  • खराब: यह ट्रंक परिवर्तनों की ट्रेसिबिलिटी को थोड़ा मुश्किल बना सकता है क्योंकि समीक्षाकर्ता प्रतिबद्ध होगा - इस पर भी यकीन नहीं है ।

अद्यतन: यदि आप अपने मूल्यवान इनपुट के लिए धन्यवाद,,।

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

एक बार वह छेद - परीक्षण - प्लग हो गया है, हर किसी के द्वारा गलतियों - नौसिखिया या वरिष्ठ - ठीक से पकड़ा जाएगा और तदनुसार निपटाया जाएगा।

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

जगह में उन दो फिक्सेस के साथ, मुझे लगता है कि मैंने ऊपर प्रस्तावित किए गए कठोर या कठोर के रूप में कुछ आवश्यक नहीं है। धन्यवाद!

स्रोत

2009-05-07 Michael Haren

+0

मुझे लगता है कि ट्रेसिबिलिटी को कवर किया जा सकता है कि इतिहास शाखा में नौसिखिया के लिए जिम्मेदार परिवर्तन दिखाएगा, और उसके बाद कमिश्नर द्वारा विलय किया जाएगा। – GuyBehindtheGuy

+0

आपकी प्रणाली कैसे तय करती है कि किसी को किसी नौसिखिया होने से रोकना चाहिए और एक कम्यूटर बनना चाहिए? – TwentyMiles

+0

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

उत्तर

28

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

आखिरकार, आप "विश्वसनीय" डेवलपर्स का एक सेट बनाने और "अविश्वसनीय" डेवलपर्स का एक सेट बनाने की कोशिश कर रहे हैं।

मैं एक अंग पर बाहर जा रहा हूं और कहता हूं कि निश्चित रूप से 'नई' (आपकी कंपनी के लिए नई) कोडर हैं जो आपके कुछ 'अनुभवी' डेवलपर्स की तुलना में गलतियां करने की संभावना कम होगी।

आपकी मूल प्रणाली में विफल होने से टेस्टिंग में विफलता एक समस्या नहीं है जिसे डेवलपर्स को अलग करके हल किया जा सकता है।

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

स्रोत

2009-05-07 17:19:08 DevinB

+1

@devinb: मैं पूरी तरह से आपसे सहमत हूं - परीक्षण प्रक्रिया में विफलता "घटनाओं की दुर्भाग्यपूर्ण श्रृंखला" का एक बड़ा हिस्सा था। शायद मेरे स्वर नए लोगों पर थोड़ा कठोर था - शायद नहीं - वे वास्तव में नए लोगों के नाम से बहुत लंबे समय तक रहे हैं। फिर भी, मैं सहमत हूं - मैं सिस्टम को ठीक करना चाहता हूं, लक्षणों का इलाज नहीं करता हूं और लोगों को अलग करता हूं। –

+2

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

+2

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

3

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

स्रोत

2009-05-07 17:16:44 kemiller2002

+0

मुझे बेवकूफ लगता है .... हाँ मेरा मतलब लक्षण था। – kemiller2002

13

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

प्रति डेवलपर शाखा भी काम करती है, लेकिन मैं सुझाव देता हूं कि डेवलपर परिवर्तनों को मर्ज करें (फिर शायद किसी अन्य डेवलपर के साथ)।

स्रोत

2009-05-07 17:20:26 nevets1219

+1

मुझे यह विचार पसंद है। यह बहुत कम प्रतिकूल लगता है - बहुत अधिक टीम उन्मुख, जो अच्छा है। –

+4

+1: कोड समीक्षा n00bz को संवर्धित करने का एक शानदार तरीका है। उन्हें दिखाएं कि आप क्या उम्मीद करते हैं, समीक्षा करें कि वे क्या उत्पादन करते हैं और जब तक आप अपेक्षा करते हैं तब तक उस पर टिप्पणी न करें। –

+2

मैं तर्क दूंगा कि परीक्षण कोड समीक्षाओं से अधिक उपयोगी है। कोड समीक्षा अभी भी, मूल रूप से, एक मानव ऑपरेशन (और इसलिए गिरने योग्य) हैं; दूसरी तरफ बेसलाइन रिग्रेशन परीक्षण विश्वसनीय रूप से मान्य कर सकता है कि "कम से कम यह टूटा नहीं गया है" (निश्चित रूप से परीक्षण करने के लिए जाने वाली चीजों के सेट के लिए)। –

2

वहाँ कई अन्य बातों के तुम कर सकते हो रहा है:

  • परियोजना प्रबंधन: टीम के साथ समस्या के बारे में बताएँ, जिम्मेदारी है कि ट्रंक

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

  • यूनिट टेस्ट:: सभी को अपने कोड के लिए यूनिट परीक्षण भी लिखने की आवश्यकता है।

  • नियमित बिल्ड और टेस्ट: निर्माण सर्वर स्थापित करें और शुरुआती समस्याओं को खोजने के लिए रात के निर्माण (इकाई परीक्षण सहित) करें।

  • कोड समीक्षा नए एसवीएन सर्वर पर एक पोस्ट-प्रतिबद्ध हुक सेट करें ताकि नए कामों पर ईमेल अधिसूचना भेजी जा सके, और किसी ने जल्दी जल्दी समीक्षा की है।

स्रोत

2009-05-07 17:21:59

12

उम ... यह स्पष्ट हो सकता है लेकिन कैसे घटनाओं है कि बुरा करने के लिए नेतृत्व की दुर्भाग्यपूर्ण श्रृंखला फिक्सिंग के बारे में पकड़े जाने नहीं करता है?

आपकी प्रक्रिया उचित लगता है; लेकिन यदि आप निरंतर एकीकरण करने जा रहे हैं, तो आपको यह सत्यापित करने की आवश्यकता है कि एकीकृत ट्रंक टूटा नहीं गया है। ऐसा लगता है कि उस प्रक्रिया को किसी तरह से पराजित किया गया है; ऐसा लगता है कि आपको उस प्रक्रिया को हराने वाले मुद्दे को ढूंढने और ठीक करने की आवश्यकता है।

स्रोत

2009-05-07 17:22:26

+2

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

+3

मैं पहले परीक्षण प्रक्रिया को ठीक करने के विचार से बहुत दृढ़ता से सहमत हूं। ऐसा लगता है कि किसी को बीफ और मरने का बुरा हिस्सा मिल रहा है; आप अचानक गोमांस से बाहर नहीं जाते हैं, आप यह पता लगाने की कोशिश करते हैं कि सुरक्षा मानकों में असफल रहा, और उनको ठीक करें। –

+2

@McWafflestix: मरना बहुत बुरा है, इसलिए कभी-कभी आपको बीफ को बाहर निकालना पड़ता है जब तक आप पाते हैं कि समस्या कहां स्थित है। फिर आप समस्या को ठीक करते समय चक भुनाते हैं। – Les

1

  • डेवलपर्स को काम करने से पहले यूनिट परीक्षण चलाएं, ताकि वे आसानी से खराब काम से बच सकें।

  • सीआई को सुनिश्चित करने के बाद, यूनिट परीक्षणों को फिर से चलाने के बाद चलाना चाहिए।

  • डेवलपर्स शाखाओं में काम करना चाहिए, जिसे समीक्षा के बाद विलय किया जाना चाहिए। एक वरिष्ठ प्रोग्रामर के लिए जो भरोसा करता है, वह "समीक्षा" हो सकती है "क्या परीक्षण पास हो जाते हैं? क्या कोड उचित दिखता है?" "Newbies" के लिए, यह और अधिक व्यापक हो सकता है।

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

स्रोत

2009-05-07 17:22:36

1

कोड ट्रंक पर परिवर्तनों की समीक्षा करें और उन्हें फ़िक्स (यदि कोई हो) लागू करें। आखिरकार वे बेहतर हो जाएंगे और हर कोई खुश होगा।

स्रोत

2009-05-07 17:22:45 cherouvim

8

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

इसके अलावा - पहली बार प्रक्रिया के माध्यम से नए शौक को हाथ से पकड़ें ताकि वे कुछ भी करने के लिए बहुत डरते न हों।

स्रोत

2009-05-07 17:24:26 tvanfosson

+0

सभी अच्छे विचार, धन्यवाद! –

0

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

"दुर्भाग्यपूर्ण घटनाओं की श्रृंखला";)। ईमानदार होने के लिए जो आपके क्यू & ए जैसा लगता है वह आपके प्रस्ताव की तरह कठोर नहीं है। एक बेहतर परीक्षण कवरेज और शायद एक सीआई सर्वर मदद करेगा। मैं व्यक्तिगत रूप से svn प्रतिबद्ध संदेश पसंद है। यह मुझे आसानी से अद्यतित रखता है। मुझे एक diff के साथ एक ईमेल मिलता है कि किसी ने किया है। करने में आसान और अपठित प्रतिबद्ध मेल भी एक todo सूची हैं।

तो, नएbies और परिवर्तनों को गले लगाने के लिए बेहतर है। नियंत्रण संरचनाओं में समय और प्रयास मत डालो। नए लोगों को पढ़ाने और प्रक्रिया में सुधार करने के लिए इसे बेहतर तरीके से खर्च करें।

स्रोत

2009-05-07 18:20:40

2

आप ReviewBoard की तरह एक मंचन समीक्षा प्रणाली डाल सकता है। Mondrian पर Google टॉक भी देखें। हम यहां समीक्षा बोर्ड का उपयोग शुरू कर रहे हैं, लेकिन "पोस्ट-प्रतिबद्ध" तरीके से, जिसे इसे सीधे डिज़ाइन नहीं किया गया है।

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

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

आप एक निरंतर एकीकरण बिल्डर्सवर तक भी जा सकते हैं (जैसा कि कई अन्य लोगों ने उल्लेख किया है)।

एक छोर पर, प्रतिबद्ध प्रक्रिया हो सकता है:

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

(हमारे यहाँ पल में प्रक्रिया "निर्देशित समकक्ष समीक्षा", "प्रतिबद्ध" "वास्तव में सरल बूट/कार्यक्षमता परीक्षण के साथ autobuild", संभावित "औपचारिक समकक्ष समीक्षा", और अंततः "स्थैतिक कोड विश्लेषण के परिणाम को संबोधित कर रहा है "।

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

और उन सभी लोगों के लिए ++ जिन्होंने "नौसिखिया को गले लगाया" दृष्टिकोण का उल्लेख किया। नवागंतुकों को लगता है कि उनके पास सीखने के संसाधनों और औजारों का एक टन है जो उनके निपटारे में बेहतर बनने के लिए बहुत अधिक महत्वपूर्ण है, क्योंकि उन्हें "दंडित" या प्रतिबंधित महसूस करना है।

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

स्रोत

2009-05-07 18:59:37 leander

3

अहम, Mercurial का उपयोग करें? फिर अपने newbies के लिए अपने स्वयं के संग्रह वे कृपया के रूप में के रूप में ज्यादा नुकसान पहुंचा सकता है ...

स्रोत

2009-05-07 19:00:55

+0

इस मामले में मुझे नहीं लगता कि एक डीवीसीएस ने हमारी मदद की होगी, हालांकि, मैं व्यक्तिगत रूप से प्रशंसक हूं। –

0

मैं सिर्फ बातें अन्य लोगों ने कहा है लेकिन गूंज किया जा सकता है ...

साक्षात्कार प्रक्रिया काफी तीव्र होना चाहिए उन से मुक्ति पाने के कि स्थिति से क्या आवश्यक है संभाल नहीं कर सकते हैं। तो, यह मेरा preemptive समाधान है।

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

स्रोत

2009-05-07 19:13:12 Pwninstein

1

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

स्रोत

2009-05-08 03:21:14 GuyBehindtheGuy

+0

मैं पूरी तरह से ओपन सोर्स प्रोजेक्ट्स के लिए सहमत हूं, बेकार कमिटर्स –

+0

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

1

कार्ल फोगेल इस स्थिति और उनकी प्रसिद्ध पुस्तक, Producing Open Source Software - How to Run a Successful Free Software Project में कई समान चर्चा करता है, और उसी निष्कर्ष पर आता है: सख्त परीक्षण और कोड समीक्षा सख्त प्रमाणीकरण से अधिक सहायक होती है।

स्रोत

2009-06-08 00:05:16 thSoft

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

  • कोई संबंधित समस्या नहीं^_^