एक टीम के लिए घर में सब कुछ लिखना कितना आम है? [बन्द है]


53

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

यह फर्म सरकार या रक्षा ठेकेदारों या किसी भी सुरक्षा-महत्वपूर्ण परियोजनाओं या इस तरह की किसी भी चीज़ के लिए काम नहीं करती है। वे आपके औसत, मध्यम आकार के सॉफ्टवेयर विकास फर्म थे।

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

संपादित करें - अधिकांश हर प्रतिक्रिया ने कहा है कि यह कुछ चिंतित है। क्या दूसरा साक्षात्कार उन्हें घर में सब कुछ लिखने पर अपनी स्थिति स्पष्ट करने / दोहराने के लिए कहने के लिए एक उपयुक्त समय होगा?


58
विशाल लाल झंडा। शांति से चलें और कोई अचानक चाल न चलें।
tdammers

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

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

13
सब कुछ? क्या इसमें उनके अपने ब्राउज़र, ऑपरेटिंग सिस्टम और कंपाइलर शामिल हैं? अन्यथा वे सिर्फ खुद को बहका रहे हैं।
मुहम्मद अलकरौरी

4
बेशक यह उतना ही हास्यास्पद है जितना लोग कहते हैं। तथ्य यह है कि ए) नौकरी के लिए गलत पुस्तकालय चुनना संभव है और बी) ऐसी स्थितियां हैं, जहां उपलब्ध कोई भी तृतीय पक्ष पुस्तकालय आपकी आवश्यकताओं को एक घर से बेहतर नहीं पूरा करेगा: इसका मतलब यह नहीं है कि कभी भी तीसरे पक्ष का उपयोग करने की कंबल नीति नहीं है लाइब्रेरी सही है।
user16764

जवाबों:


76

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

एक अधिक तर्कसंगत और गहन उत्तर यह हो सकता है कि वे केवल तीसरे पक्ष के पुस्तकालयों का उपयोग करेंगे:

  • कोड की जरूरतों को पूरा करें अन्यथा वे खुद को लिखेंगे
  • कंपनी के बिजनेस मॉडल के साथ संगत लाइसेंस के तहत उपलब्ध थे
  • शामिल परीक्षण
  • एक कोड समीक्षा पास की

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

यदि कोड खुला स्रोत है, तो सबसे खराब स्थिति में, तृतीय-पक्ष पुस्तकालय अप्रभावित हो जाता है। लेकिन कौन परवाह करता है? परीक्षण साबित करते हैं कि पुस्तकालय आपकी आवश्यकताओं के लिए अनुकूल है!

इसके अलावा, तीसरे पक्ष के पुस्तकालयों की स्थापना के लिए एक फैलाव प्रोग्रामर उत्पादकता को गंभीरता से रोकता है। मान लीजिए कि कंपनी वेब एप्लिकेशन लिख रही थी और उसने jQuery का उपयोग करने से इंकार कर दिया था, इसलिए इसके बजाय DOM हेरफेर को सरल बनाने के लिए अपने स्वयं के वैकल्पिक क्रॉस-ब्राउज़र लाइब्रेरी को लिखा। निकट-निश्चितता के साथ हम मान सकते हैं कि उनका कार्यान्वयन:

  • पहले से ही jQuery से परिचित डेवलपर्स के लिए एक एपीआई विदेशी होगा
  • JQuery के रूप में अच्छी तरह से प्रलेखित नहीं किया जाएगा
  • लायब्रेरी का उपयोग कर समस्याओं का सामना करते समय प्रासंगिक Google परिणाम नहीं होंगे
  • JQuery के रूप में क्षेत्र-परीक्षण नहीं किया जाएगा

उन सभी बिंदुओं को प्रोग्रामर उत्पादकता के लिए प्रमुख बाधाएं हैं। उस तरह से उत्पादकता छोड़ने के लिए एक व्यवसाय कैसे हो सकता है?


आपने यह पूछने के लिए अपना प्रश्न अपडेट किया है कि क्या यह दूसरे साक्षात्कार में लाने के लिए उपयुक्त है। यह बिल्कुल है

हो सकता है कि आपने पहले साक्षात्कार में अपने साक्षात्कारकर्ता के उत्तर की गलत व्याख्या की हो, या हो सकता है कि साक्षात्कारकर्ता ने कंपनी की स्थिति को केवल गलत तरीके से समझाया हो और एक नया साक्षात्कारकर्ता इसे स्पष्ट कर सकता है।

यदि आप समझाते हैं कि आप बाहरी पुस्तकालयों पर उनके रुख के बारे में चिंतित हैं, तो कम से कम दो संभावित परिणाम हैं:

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

1
+1 लेकिन मुझे लगता है कि आपका मतलब निजी क्षेत्र से है, सार्वजनिक क्षेत्र से नहीं ।
MarkJ

6
"यदि कोड खुला स्रोत है, तो सबसे खराब स्थिति में, तृतीय-पक्ष पुस्तकालय अस्वाभाविक हो जाता है। लेकिन कौन परवाह करता है? परीक्षण साबित करते हैं कि पुस्तकालय आपकी आवश्यकताओं के लिए अनुकूल है!" आपके पास स्रोत कोड भी है, जो आपको उस स्थिति में रखता है जो आप अभी उपयोग कर रहे हैं और किसी भी भविष्य की जरूरतों को पूरा करने के लिए इसे अपडेट करने में सक्षम हैं। (हां, एक "एलियन" कोड बेस के लिए इस्तेमाल होने में समय लगता है, लेकिन ऐसा आपका खुद का रोल करता है।)
एक CVn

34

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


2
चूंकि डेवलपर्स के पास अब अन्य नौकरियों के लिए प्रासंगिक कौशल नहीं थे, इसलिए कंपनी का पैसा विस्तारित देव समय पर खो दिया गया था, जो कि दिवंगत टीम के सदस्यों को बदलने के लिए नहीं बचा था! #stratgey
माइकल पॉलुकोनिस

@ मिचेल: वे केवल वही लोग रख सकते थे जो घर के ढांचे को बनाने के मूल निर्णय के लिए मौजूद थे। लगभग एक साल के बाद छोड़ने के लिए नए काम पर रखा।
केविन क्लाइन


+1 यदि अनुपलब्ध सुविधा वास्तव में, वास्तव में, महत्वपूर्ण है: ओपन-सोर्स लाइब्रेरी को संशोधित करें और मुख्य स्रोत में सुविधा का योगदान करें। महान व्यावसायिक मूल्य में वृद्धि, सभी को अच्छा लगता है और यह सभी के सीवी के लिए उत्कृष्ट है क्योंकि उन्होंने अब एक ओपन-सोर्स योगदान दिया है।
MarkJ

@ मर्कज: लेकिन अगर बदलाव को खारिज कर दिया जाता है, तो किसी को एक गंभीर अहंकार होगा।
केविन क्लाइन

20

दुकान में नॉट इंवेंटेड नामक बीमारी है । यह मौके पर साक्षात्कार को समाप्त करने और तुरंत छोड़ने का एक अच्छा कारण है। यह केवल एक शीर्ष-डाउन हाउस की सफाई से ठीक हो सकता है जो कि होने की बहुत संभावना नहीं है।

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


15

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


11

मेरे कुछ मित्र हैं, जिन्होंने यहां सिंड्रोम का आविष्कार नहीं करने के साथ सॉफ्टवेयर हाउस में काम किया है । इसलिए मानसिकता वहीं है।

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


+1 मुख्य कारणों में से एक जो मैंने अपने पिछले नियोक्ता से लिया था!
एंटनी स्कॉट

5

यह आम नहीं है कि मैं कहाँ रहता हूँ, और मुझे बहुत सी कंपनियों के सहकर्मियों के बारे में पता है। मैं यह कहना चाहता हूँ कि यह मेरे से तात्कालिक "नो थैंक्स" है।

मैं पहले से ही बनाए गए अच्छे अंकों को फिर से हासिल नहीं करूंगा, लेकिन मैं एक बात जोड़ूंगा।

उन्होंने बस काम को और अधिक कठिन बना दिया है।

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

अब बेशक ऐसे लोग होंगे जो चुनौती पसंद करते हैं, लेकिन मुझे लगता है कि वे अल्पमत में होंगे।

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


4

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

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

आपने इस परिदृश्य को जो लिखा है, उससे ऐसा प्रतीत नहीं होता कि यह मामले के दिल में है।


4

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

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

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

कुछ कंपनियां अपने स्वयं के ओपन सोर्स प्रोजेक्ट बनाने की स्वतंत्रता देती हैं, जो अधिक उपयुक्त लगता है।

मैं व्यक्तिगत रूप से ऐसी संस्कृति वाले स्थान पर नहीं जाऊंगा।


1

आपको जो मिला है वह दूसरे साक्षात्कार में जाने और उनसे कुछ कठिन प्रश्न पूछने का वास्तव में अच्छा अवसर है। मुझे नहीं पता कि कंपनी क्या करती है इसलिए यह कहना मुश्किल है कि यह एक अजीब विकल्प क्यों लगता है। Google की थर्ड पार्टी लाइब्रेरी के उपयोग के संबंध में आप @Daniel Pryden की टिप्पणी का उपयोग कर सकते हैं।

आपके द्वारा उपयोग किया गया कोई भी सॉफ़्टवेयर, चाहे वह इन-हाउस हो या किसी तृतीय पक्ष के फायदे और नुकसान हों। एक उपकरण का उपयोग न करना क्योंकि यह घर में नहीं है, भले ही यह नौकरी के लिए सबसे अच्छा उपकरण है, एक निश्चित बंद मानसिकता को दर्शाता है और यह कभी भी नवाचार और रचनात्मकता को प्रोत्साहित करने वाला नहीं है।

शायद, हालांकि, शायद, आप उस बदलाव को पेश करने वाले व्यक्ति हैं। सबकुछ के लिए सुभकामनाये।


-3

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

अपने अगले साक्षात्कार की कल्पना करें जब वे पूछते हैं कि आपने किन तकनीकों के साथ काम किया है और आप केवल नंगे हड्डियों C ++ का उल्लेख कर सकते हैं। यह स्नातक स्तर की तरह लगता है


"मैंने यहां इसका उल्लेख नहीं देखा है" - क्या आपने अन्य उत्तरों को देखा था, उदाहरण के लिए इस एक पर ?
gnat

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

@GrandmasterB आप सही हैं, मुझे स्पष्ट करने की अनुमति दें - बहुत सारे स्थान पूछते हैं कि आपने किन उपकरणों के साथ काम किया। यदि आपके अन्य उम्मीदवारों को खरोंच से सीखना होगा, तो अनदेखी की संभावना बहुत अधिक होती है, जब अन्य उम्मीदवार मैदान में दौड़ सकते हैं।
मार्टिन कोनसेनी

-9

बड़ी कंपनियाँ खुद ही सब कुछ लिख लेती हैं।

इसे स्वयं लिखने के कई फायदे हैं:

  1. आप खुद सॉफ्टवेयर की गारंटी दे रहे हैं
  2. आप काम की मात्रा की सही गणना कर सकते हैं जो इसे बनाने में गई थी
  3. अगली बार जब लिबास उपलब्ध नहीं होते हैं तो भी अपने कदमों को दोहराना संभव हो जाता है
  4. यह आपकी आवश्यकता ब्लोट को कम करता है
  5. आप वही नहीं दोहरा रहे हैं जो दूसरे पहले कर चुके हैं
  6. आपको इसे बनाए रखने के लिए पर्याप्त लोगों की गारंटी है
  7. आप सॉफ्टवेयर के हर हिस्से को संशोधित कर सकते हैं
  8. सॉफ्टवेयर का आकार आपके पास मौजूद संसाधनों की मात्रा से सीमित है

यदि आप किसी अन्य पुस्तकालय का उपयोग करते हैं तो यहां से प्रत्येक बिंदु कैसे टूटता है:

  1. किसी और का मालिक है
  2. आप नहीं जानते कि लिबास बनाने में कितना प्रयास हुआ
  3. उत्पाद का आपका अगला संस्करण नए प्लेटफ़ॉर्म पर बनाना असंभव है क्योंकि समान लीव अब उपलब्ध नहीं हैं
  4. आवश्यकता को लागू करने की क्षमता इस बात पर निर्भर है कि क्या यह वर्षों पहले लागू किया गया था
  5. किसी और ने भी समान सीमाओं और सुविधाओं को प्राप्त करने के लिए एक ही काम का उपयोग किया है
  6. चूंकि आपने लिबास नहीं बनाया है, इसलिए आपके पास अपने उत्पाद के सभी सॉफ़्टवेयर को बनाए रखने के लिए पर्याप्त लोग नहीं हैं
  7. Libs बायनेरी हैं, गैर-परिवर्तनीय हैं। यदि स्रोत उपलब्ध है, तो भी आपके पास कोड की बड़ी मात्रा को संशोधित करने के लिए पर्याप्त लोग नहीं हैं।
  8. आपके द्वारा बनाए गए कोड को बनाए रखना + आपके द्वारा मूल रूप से अनुमानित की तुलना में सबसे बड़ा प्रयास है

7
क्या इन तर्कों का तार्किक विस्तार आपके अपने संकलक (शायद आपकी अपनी भाषा के लिए) को लिखने के लिए नहीं होगा, इस सॉफ़्टवेयर को अपने OS पर चलाएं, और शायद अपना स्वयं का HW भी बनाएँ?
17

4
1: हां और मैं इसका उपयोग करने के लिए शुल्क का भुगतान कर सकते हैं (बिना पैसे खर्च किए इसे बनाने के लिए लागत में अंतर है)। 2: अगर मैं इसका निर्माण नहीं कर रहा हूं तो मुझे कोई परवाह नहीं है। 3: व्यापार प्लेटफार्मों में बदलने के लिए धीमी कर रहे हैं। अत्याधुनिक रहना शायद ही कभी आवश्यकता होती है। लेकिन अच्छा सॉफ्टवेयर आसानी से चला गया। 4: सच नहीं है। आप बस ब्लोट को बाहरी से आंतरिक में स्थानांतरित करते हैं। 5: कोई मतलब नहीं है। 6: सच नहीं है। 7: सही है, लेकिन इसका मतलब है कि आपको अपने कीमती प्रोग्रामर्स (एक प्रोजेक्ट का सबसे महंगा हिस्सा) को वास्तविक काम से बग फिक्सिंग में बदलने की जरूरत है, जिसे कहीं और बनाए रखा जा सकता है। 8: यह एक बुरी बात है।
मार्टिन यॉर्क

5
कई बड़ी कंपनियाँ विभिन्न स्रोतों में ओपन सोर्स कोड का व्यापक उपयोग करती हैं (जिसमें लिबास भी शामिल है), अक्सर संबंधित परियोजनाओं में सुधार / योगदान करते हैं। अंक ज्यादातर अप्रासंगिक या गलत हैं।
मैट

7
@ tp1: मैं Google के लिए काम करता हूं और मैं आपको आश्वस्त कर सकता हूं कि जब वे हमारी जरूरतों को पूरा करते हैं तो Google तीसरे पक्ष के पुस्तकालयों का बहुत उपयोग करता है। कई बार Google के पास ऐसी ज़रूरतें होती हैं जो कई अन्य सॉफ़्टवेयर कंपनियों से अलग या अलग पैमाने पर होती हैं, इसलिए एक कारण या किसी अन्य Google से अक्सर घर में चीजों का विकास होगा। लेकिन Google बड़ी संख्या में ओपन-सोर्स लाइब्रेरीज़, और / या ओपन-सोर्स बहुत सारी लाइब्रेरियों का उपयोग करता है, इसलिए सब कुछ इन-हाउस नहीं है। आपके अधिकांश बिंदु अब ओपन-सोर्स सॉफ़्टवेयर के लिए लागू नहीं होते हैं, क्योंकि स्रोत होने से आप यह सुनिश्चित करते हैं कि आप इसे हमेशा डिबग कर सकते हैं और यदि आवश्यक हो तो इसे ठीक कर सकते हैं।
डैनियल प्रेडेन

5
"नहीं, मान आवश्यकताओं को सही ढंग से लागू करने से आता है। यदि यह आवश्यकताओं को ज्ञात करने से पहले बनाया गया था, तो यह उन सटीक आवश्यकताओं को सही ढंग से लागू नहीं कर सकता है।" सुराग: यदि आपको लगता है कि इस तर्क में कोई योग्यता है, तो आप चिंताओं को अलग करने में विफल रहे हैं।
user16764
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.