निर्भरता लेने के डर से कैसे निपटें

54

टीम मैं ऐसे घटक बनाता हूं जिनका उपयोग कंपनी के भागीदारों द्वारा हमारे प्लेटफॉर्म के साथ एकीकृत करने के लिए किया जा सकता है।

जैसे, मैं मानता हूं कि हमें (तृतीय-पक्ष) निर्भरता का परिचय देते समय अत्यधिक सावधानी बरतनी चाहिए। वर्तमान में हमारे पास कोई तृतीय-पक्ष निर्भरता नहीं है और हमें रूपरेखा के निम्नतम एपीआई स्तर पर बने रहना है।

कुछ उदाहरण:

हम फ्रेमवर्क (.NET स्टैंडर्ड) के निम्नतम एपीआई स्तर पर रहने के लिए मजबूर हैं। इसके पीछे तर्क यह है कि एक नया प्लेटफॉर्म एक दिन आ सकता है जो केवल बहुत कम एपीआई स्तर का समर्थन करता है।
हमने JSON को क्रमबद्ध करने के लिए अपने स्वयं के घटकों को लागू किया है और JWT के लिए भी ऐसा करने की प्रक्रिया में हैं। यह फ्रेमवर्क एपीआई के उच्च स्तर पर उपलब्ध है।
हमने मानक लाइब्रेरी के HTTP फ्रेमवर्क के आसपास एक आवरण लागू किया है, क्योंकि हम मानक पुस्तकालय के HTTP कार्यान्वयन पर निर्भरता नहीं लेना चाहते हैं।
XML से / के लिए मैपिंग के लिए सभी कोड "हाथ से" लिखा जाता है, फिर से उसी कारण से।

मुझे लगता है कि हम इसे बहुत दूर ले जा रहे हैं। मैं सोच रहा हूं कि इससे कैसे निपटा जाए क्योंकि मुझे लगता है कि यह हमारे वेग को बहुत प्रभावित करता है।

— Bertus
स्रोत

20

क्या इसके लिए कोई औचित्य है (जैसे, बाहरी आवश्यकता) या क्या यह अज्ञानता से बाहर किया जा रहा है?

— ब्लरफ्ल

6

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

— फिलीप मिलोवानोविक

73

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

— UKMonkey

8

कहा कि वैकल्पिक ड्रॉ बैक है, जैसे प्रोजेक्ट्स को कभी खत्म नहीं करना। लेकिन यह सॉफ्टवेयर नौकरियों और रोजगार को बढ़ावा देता है :)

— मार्शल शिल्प

5

आप सही हैं कि आप कमोडिटी सॉफ़्टवेयर का पुन: आविष्कार करके प्रयास बर्बाद कर रहे हैं। आप इसमें गलत हैं कि यह "सभी निर्भरताओं से बचने" के करीब भी नहीं है। Microsoft पर Excel टीम ने एक बार Microsoft पर C टीम पर निर्भरता लेने से बचने के लिए अपना C संकलक लिखा था । आप ऑपरेटिंग सिस्टम, उच्च-स्तरीय रूपरेखा, और इतने पर निर्भरता ले रहे हैं।

— एरिक लिपर्ट

94

... हम फ्रेमवर्क (.NET मानक) के निम्नतम एपीआई स्तर पर बने रहने के लिए मजबूर हैं ...

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

.NET मानक नहीं है, और कभी भी " फ्रेमवर्क का निम्नतम एपीआई स्तर " नहीं होगा । .NET के लिए API का सबसे प्रतिबंधक सेट पोर्टेबल क्लास लाइब्रेरी बनाकर प्राप्त किया जाता है जो विंडोज फोन और सिल्वरलाइट को लक्षित करता है।

.NET मानक के जिस संस्करण को आप लक्षित कर रहे हैं, उसके आधार पर, आप एपीआई के बहुत समृद्ध सेट के साथ समाप्त हो सकते हैं जो .NET फ्रेमवर्क, .NET कोर , मोनो , और ज़मारिन के साथ संगत हैं । और कई तृतीय-पक्ष पुस्तकालय हैं जो .NET मानक संगत हैं जो इन सभी प्लेटफार्मों पर काम करेंगे।

फिर .NET मानक 2.1 है, 2019 की शरद ऋतु में जारी होने की संभावना है। यह .NET कोर, मोनो और ज़मारिन द्वारा समर्थित होगा। यह .NET फ्रेमवर्क के किसी भी संस्करण द्वारा समर्थित नहीं होगा , कम से कम भविष्य के भविष्य के लिए, और हमेशा की संभावना है। इसलिए निकट भविष्य में, " फ्रेमवर्क का सबसे निचला एपीआई स्तर " होने से दूर , .NET मानक ढांचे को उलट देगा और ऐसे एपीआई हैं जिनके पास बाद वाले द्वारा समर्थित नहीं हैं।

तो " इस के पीछे तर्क यह है कि एक नया मंच एक दिन आ सकता है कि केवल बहुत ही एपीआई स्तर का समर्थन करता है " के साथ सावधान रहना होगा क्योंकि यह काफी संभावना है कि नए मंच वास्तव में पुराने ढांचे की तुलना में एक उच्च स्तर एपीआई का समर्थन करेंगे।

फिर तीसरे पक्ष के पुस्तकालयों का मुद्दा है। उदाहरण के लिए JSON.NET .NET मानक के साथ संगत है। .NET मानक के साथ संगत किसी भी पुस्तकालय की गारंटी है - एपीआई-वार - सभी .NET कार्यान्वयन के साथ काम करने के लिए जो .NET मानक के उस संस्करण के साथ संगत हैं। इसलिए आप इसका उपयोग न करके और अपनी JSON लाइब्रेरी बनाकर कोई अतिरिक्त संगतता प्राप्त नहीं कर सकते हैं। आप बस खुद के लिए और अधिक काम पैदा करते हैं और अपनी कंपनी के लिए अनावश्यक लागतों का खर्च उठाते हैं।

तो हां, आप निश्चित रूप से इसे मेरे विचार से बहुत दूर ले जा रहे हैं।

— डेविड अरनो
स्रोत

16

"आप बस अपने लिए और अधिक काम पैदा करते हैं और अपनी कंपनी के लिए अनावश्यक लागतों का खर्च उठाते हैं।" - और सुरक्षा दायित्व। यदि आप इसे पुनरावर्ती वस्तु देते हैं तो क्या आपका JSON एनकोडर स्टैक ओवरफ्लो के साथ दुर्घटनाग्रस्त होता है? क्या आपका पार्सर पात्रों को सही ढंग से बचता है? क्या यह बिना चरित्र वाले चरित्रों को अस्वीकार करता है जो इसे करना चाहिए? कैसे बिना सरोगेट पात्रों के बारे में? जब JSON 2 ^ 64 से बड़ी संख्या को एन्कोड करता है तो क्या यह ओवरफ्लो होता है? या यह केवल evalकुछ पवित्रता जांच के साथ एक छोटा आवरण है जिसे आसानी से बाईपास किया जाता है?

— जॉन ड्वोरक

4

".NET के लिए API का सबसे अधिक प्रतिबंधात्मक सेट पोर्टेबल क्लास लाइब्रेरी बनाकर प्राप्त किया जाता है जो विंडोज फोन और सिल्वरलाइट को लक्षित करता है।" मैं एक अंग पर बाहर जाऊंगा और दावा करूंगा कि उस उपसमुदाय में कम से कम कुछ एपीआई हैं जो कभी भी मौजूद सभी संभावित कार्यान्वयनों द्वारा समर्थित नहीं हैं (और कोई भी WinPhone या सिल्वरनाइट के बारे में कोई परवाह नहीं करता है, यहां तक कि Microsoft भी नहीं)। आधुनिक ढांचे के लिए एक लक्ष्य के रूप में .NetStandard 2.0 का उपयोग करना बहुत ही विवेकपूर्ण है और विशेष रूप से सीमित नहीं है। 2.1 को अपडेट करना एक अलग कहानी है लेकिन ऐसा कोई संकेत नहीं है कि वे ऐसा करेंगे।

— 15:14

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

— जैस्पर

51

हमें फ्रेमवर्क (.net मानक) के न्यूनतम एपीआई स्तर पर रहने के लिए मजबूर किया जाता है। इसके पीछे तर्क यह है कि एक नया प्लेटफॉर्म एक दिन आ सकता है जो केवल बहुत कम एपीआई स्तर का समर्थन करता है।

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

हमने JSON को क्रमबद्ध करने के लिए अपने स्वयं के घटकों को लागू किया है, और JWT के लिए भी ऐसा करने की प्रक्रिया में हैं। यह फ्रेमवर्क एपीआई के उच्च स्तर में उपलब्ध है। हमने मानक पुस्तकालय के HTTP फ्रेमवर्क के आसपास एक आवरण लागू किया है क्योंकि हम मानक पुस्तकालय के HTTP आवेग पर निर्भरता नहीं लेना चाहते हैं। XML से / के लिए मैपिंग के लिए सभी कोड "हाथ से" लिखा जाता है, फिर से उसी कारण से।

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

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

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

— berry120
स्रोत

3

और यहां तक कि अगर आप नहीं कर सकते हैं, तो दूसरे पुस्तकालय में स्विच करना अभी भी आसान है और अपने खुद के रोल करने से बेहतर है।

— मोनिका

5

उत्कृष्ट बिंदु यह है कि निचले स्तर का सामान तेजी से मर जाता है। यह सार की स्थापना का पूरा बिंदु है।

— मोनिका

"पुराने, निम्न एपीआई स्तर अप्रचलित और नए लोगों की तुलना में असमर्थित होने की संभावना है"। है ना? नेटस्टैंडर्ड एक दूसरे के ऊपर बने हैं जहाँ तक मुझे पता है (मतलब 2.0 1.3 + X है)। इसके अलावा मानक बस हैं कि .. मानकों, कार्यान्वयन नहीं। यह किसी मानक के बारे में बात करने का कोई मतलब नहीं है कि उस मानक के अधिकांश विशिष्ट कार्यान्वयन भविष्य में हो सकते हैं (लेकिन पहले के बिंदु को देखें कि यह भी चिंता का विषय क्यों नहीं है)। अगर आपकी लाइब्रेरी को NetStandard 1.3 के बाहर किसी चीज की आवश्यकता नहीं है, तो इसे 2.0 में बदलने का कोई कारण नहीं है

— Voo

11

पूरे मामले में ये चीजें आपके ग्राहकों के लिए अच्छी हैं। यहां तक कि एक लोकप्रिय ओपन सोर्स लाइब्रेरी उनके लिए किसी कारण से उपयोग करना असंभव हो सकता है।

उदाहरण के लिए, उन्होंने खुले स्रोत उत्पादों का उपयोग न करने का वादा करते हुए अपने ग्राहकों के साथ एक अनुबंध पर हस्ताक्षर किए हो सकते हैं।

हालाँकि, जैसा कि आप बताते हैं, ये सुविधाएँ बिना लागत के नहीं हैं।

बाजार के लिए समय
पैकेज का आकार
प्रदर्शन

मैं इन डाउनसाइड्स को बढ़ाऊंगा और ग्राहकों के साथ बात करके पता लगाऊंगा कि क्या आपको वास्तव में अनुकूलता के uber स्तरों की आवश्यकता है।

यदि सभी ग्राहक पहले से ही उदाहरण के लिए Json.NET का उपयोग करते हैं, तो अपने उत्पाद में अपने स्वयं के deserialisation कोड के बजाय इसका उपयोग करके, इसके आकार को कम करता है और इसमें सुधार करता है।

यदि आप अपने उत्पाद का दूसरा संस्करण पेश करते हैं, तो एक जो तीसरे पक्ष के पुस्तकालयों के साथ-साथ एक संगत का उपयोग करता है जिसे आप दोनों से ऊपर उठा सकते हैं। क्या ग्राहक थर्ड पार्टी का उपयोग नवीनतम सुविधाओं को थोड़ा पहले पाने के लिए करेंगे, या 'संगत' संस्करण के साथ रहेंगे?

— ईवान
स्रोत

11

हां मैं स्पष्ट रूप से सहमत हूं, और मैं आपकी सूची में "सुरक्षा" जोड़ूंगा। वहाँ कुछ क्षमता है कि आप अपने कोड में भेद्यता का परिचय दे सकते हैं, विशेष रूप से JSON / JWT जैसी चीजों के साथ, अच्छी तरह से परीक्षण किए गए ढांचे और निश्चित रूप से मानक पुस्तकालय की तुलना में।

— बर्टस

हां, इसकी सूची बनाना कठिन है क्योंकि जाहिर है कि सुरक्षा और प्रदर्शन जैसी चीजें दोनों तरीकों से जा सकती हैं। लेकिन परिष्करण सुविधाओं के बीच एक स्पष्ट संघर्ष है और आंतरिक घटकों का बीमा पूरी तरह से चित्रित / समझा जाता है

— इवान

12

"उन्होंने खुले स्रोत उत्पादों का उपयोग न करने का वादा करने वाले अपने ग्राहकों के साथ एक अनुबंध पर हस्ताक्षर किए हो सकते हैं" - वे .NET मानक का उपयोग कर रहे हैं, जो खुला स्रोत है। जब आप अपने संपूर्ण उत्पाद को किसी ओपन सोर्स फ्रेमवर्क पर आधारित कर रहे हों तो उस अनुबंध पर हस्ताक्षर करना एक बुरा विचार है।

— स्टीफन

और अभी भी लोग इसे करते हैं

— इवान

7

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

— डबल विजन स्टाउट फैट हैवी
स्रोत

2

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

— कोई यू

0

मूल रूप से यह सब बनाम जोखिम के प्रयास के लिए आता है।

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

ताकत: कम प्रयास, क्योंकि आपको इसे स्वयं कोड करने की आवश्यकता नहीं है।
कमजोरियाँ: यह एक दस्तकारी समाधान के रूप में आपकी विशेष आवश्यकताओं के लिए डिज़ाइन किया गया रिवाज नहीं है।
अवसर: बाजार का समय छोटा है। आपको बाहरी विकास से लाभ हो सकता है।
धमकी: आप अतिरिक्त निर्भरता वाले ग्राहकों को परेशान कर सकते हैं।

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

— डोमिनिक होफर
स्रोत

-2

अपने घटक पुस्तकालयों को एक "कोर" सेट में विभाजित करें, जिसमें कोई निर्भरता नहीं है (अनिवार्य रूप से आप अभी क्या कर रहे हैं) और एक "सामान्य" सेट, जिसकी आपके "कोर" और 3 पार्टी पुस्तकालयों पर निर्भरता है।

इस तरह अगर कोई केवल "कोर" कार्यक्षमता चाहता है, तो उनके पास यह हो सकता है।

यदि कोई "सामान्य" कार्यक्षमता चाहता है, तो उनके पास यह हो सकता है।

और आप प्रबंधित कर सकते हैं कि "कोर" बनाम "कॉमन" क्या है। आप "सामान्य" में अधिक तेज़ी से कार्यक्षमता जोड़ सकते हैं, और इसे अपने "कोर" कार्यान्वयन में स्थानांतरित कर सकते हैं यदि / जब यह आपके स्वयं के कार्यान्वयन को प्रदान करने के लिए समझ में आता है।

— Turtle1363
स्रोत