एक निर्भरता कैसे चुनें: खरीद के खिलाफ निर्माण, जोखिम प्रबंधन, और अधिक

मजेदार तथ्य, मैंने सोचा कि मैं पहले से ही इस पोस्ट को लिखा था, लेकिन जब मैं इसे संदर्भित करना चाहता था, तो मुझे पता चला कि मैं नहीं था. इस पोस्ट में, मैं एक निर्भरता चुनते समय अपने दृष्टिकोण का वर्णन करना चाहता हूं. मैं सबसे पहले इस पोस्ट के संदर्भ में निर्भरता के साथ मैं क्या मतलब है परिभाषित करूंगा. फिर, मैं संभावित निर्भरताओं का विश्लेषण करने के लिए कई मानदंडों की एक ग्रिड सूची दूंगा. एक निर्भरता क्या है? एक निर्भरता सचमुच कुछ है जो आपके सॉफ्टवेयर पर निर्भर करता है: एक फ़ाइल सिस्टम या एक डेटाबेस, नेटवर्क, आदि जैसे बुनियादी ढांचे इस पोस्ट के संदर्भ में, हालांकि, मैं एक सॉफ्टवेयर निर्भरता के लिए सीमा को सीमित करना चाहता हूं जिसे आपको कॉपी करने / चलाने की आवश्यकता है, विभिन्न सॉफ्टवेयर स्टैक इस लाइब्रेरी के लिए अलग-अलग नाम हैं: आई.ई। रूबी इसे एक गहने कहते हैं Rust इसे एक क्रेडिट कहते हैं Python और Node.js इसे एक पैकेज कहते हैं इसे मॉड्यूल कहते हैं Maven/Gradle इसे एक निर्भरता कहता है, इसलिए नाम मैं शीर्षक में उपयोग करता हूं आदि ध्यान दें कि उद्योग शुद्ध आय कारणों से सेवा-आधारित आर्किटेक्चर पर चले गए हैं. एक REST API या कुछ और के माध्यम से सेवाओं तक पहुंच सकता है. किसी भी मामले में, समान मूल्यांकन मानदंड लागू होते हैं. खरीदें vs. खरीदें जब आपको नए सॉफ्टवेयर की आवश्यकता होती है, तो सामान्य तर्क यह है कि इसे बनाने के बजाय इसे खरीदने के लिए - Component Off The Shelf. एक ही तर्क एक नई निर्भरता के साथ लागू किया जा सकता है, एक प्रमुख अतिरिक्त विकल्प के साथ: ओपन सोर्स। यहाँ मेरा मामूली योगदान है, व्यक्तिगत अनुभव से. मेरे परियोजनाओं में, मैं दृश्यता के बारे में बहुत रूढ़िवादी हूं. मैं बाहरी पहुंच को कम से कम रखने की कोशिश करता हूं. जावा में, मैं उपयोग करता हूं जितना संभव हो, निर्माताओं में भी. हालांकि, आप परीक्षणों में निजी निर्माताओं का उपयोग नहीं कर सकते. इसलिए, मैंने पैकेज-प्रूफ के लिए दृश्यता का विस्तार किया, लेकिन मैं इसे दस्तावेज़ करने का एक तरीका चाहता था. private अतीत में, मैंने नियमित रूप से टिप्पणियों का उपयोग किया जब तक कि एक सहयोगी ने गुआवा के मैं तुरंत एक बड़ा प्रशंसक बन गया. और फिर भी, मैं इस पर निर्भरता नहीं लाऊंगा केवल. अगर यह केवल गवावा के लिए मेरा एकमात्र टिप्पणी है, तो मैं अपना खुद का बनाना पसंद करूंगा। दृष्टिकोण @VisibleForTesting हालांकि, अगर मुझे गुआवा से अन्य कक्षाओं की आवश्यकता होती है, तो मैं अपने निर्णय को फिर से मूल्यांकन करूंगा। , एक कुंजी के तहत संग्रहीत संभवतः कई मूल्यों के साथ एक नक्शा, विकसित करने के लिए बहुत अधिक समय की आवश्यकता होती है। , शायद मैं निर्भरता को जोड़ूंगा। मल्टीमीप Multimap जैसा कि आप देख सकते हैं, निर्णय काफी संदर्भ निर्भर करता है। इस पोस्ट के बाकी हिस्सों में, हम मान लेंगे कि निर्माण करने का विकल्प सबसे अच्छा समाधान नहीं था, और हमें मौजूद चीजों से एक निर्भरता चुनने की आवश्यकता है। जोखिम प्रबंधन एक निर्भरता चुनना एक जोखिम है, और हर जोखिम के रूप में, आपको उचित आवेदन करने की आवश्यकता है : जोखिम प्रबंधन तकनीक जोखिमों की पहचान करें: अगले अनुभाग में, मैं कई वस्तुओं को सूचीबद्ध करूंगा जिन्हें आप विचार कर सकते हैं। प्रत्येक जोखिम का विश्लेषण करें. संभावना और इसके प्रभाव पर विचार करें. संगठन अलग-अलग हैं. एक अपने संदर्भ में एक विशिष्ट जोखिम के प्रभाव को कम मानता है, लेकिन दूसरा इसे उच्च मानता है. मैं आपको वहां मदद नहीं कर सकता। Plan responses. For each risk, document mitigating actions and their associated costs निगरानी! जोखिम प्रबंधन एक बार किया गया एक स्थिर गतिविधि नहीं है। यहां तक कि निर्भरताओं के संदर्भ में, नए जोखिम दिखाई दे सकते हैं, उदाहरण के लिए, एक नया महत्वपूर्ण सीवीई. इसके अलावा, एक जोखिम इसकी संभावना को बढ़ा सकता है, उदाहरण के लिए, एक कोर कमांडर परियोजना छोड़ देता है, और बस कारक को एक महत्वपूर्ण स्तर तक कम कर सकता है। चुनें मानदंड के मैं लिख रहा हूं वह आधार है जिस पर मैं निर्माण करूंगा. मैं इसके ऊपर विकसित करूंगा. ब्लैक लाइसेंस और कानूनी पहलू मुझे लगता है कि यह सबसे महत्वपूर्ण पहलू है. आपको लाइसेंस को देखने की आवश्यकता है. GitHub इसे सत्यापित करना आसान बनाता है: सबसे पहले, यह परियोजनाओं को एक लाइसेंस बनाने के लिए प्रोत्साहित करता है फ़ाइल; फिर, यह शीर्ष पर स्पष्ट रूप से दिखाता है यदि यह मान्यता प्राप्त ओपन सोर्स लाइसेंस में से एक है। LICENSE आपको यह सुनिश्चित करने की आवश्यकता है कि आप लाइसेंस को समझते हैं। , यह काफी आसान है: दूसरों ने पहले से ही आपके लिए काम किया है. अन्य प्रकारों के लिए, यह अधिक कठिन हो सकता है. कुछ निर्भरताओं को एक डबल लाइसेंस के तहत जारी किया जाता है: एक ओपन सोर्स और एक वाणिज्यिक। OSI अनुमोदित लाइसेंस कीमत मूल्य के तीन मॉडल हैं (जिसे मैं जानता हूं): तय कीमत कुछ कारकों के आधार पर परिवर्तनीय मूल्य, उदाहरण के लिए, सीपीयू की संख्या, उपयोगकर्ताओं की संख्या, आदि उपर्युक्त का एक संयोजन लाइसेंस सीमित समय के लिए या हमेशा के लिए हो सकता है। मेरी सबसे अच्छी सलाह आपकी आवश्यकताओं, अपने दायरे और अपने बजट को लिखना है. फिर, आपको शायद अपनी खरीद विभाग को खरीद को सौंप देना चाहिए: वे पेशेवर हैं और बातचीत करने के लिए सबसे अच्छे हैं. आपको किसी भी समय उन्हें शामिल करने की आवश्यकता होगी. शासन वाणिज्यिक परियोजनाओं को एक कंपनी द्वारा नियंत्रित किया जाता है. एक कंपनी द्वारा नियंत्रित परियोजना का मुख्य लाभ वित्तीय समर्थन है. यदि परियोजना उम्मीद की गई आय को वापस नहीं देती है तो यह एक मूर्खतापूर्ण बिंदु बन सकता है. अन्य लाभ संभवतः लेवरेज के लिए पेशेवर कौशल और समर्थन शामिल होंगे (लिंक देखें: # नीचे)। ओपन सोर्स वे प्रबंधन के बारे में कई विकल्प प्रदान करते हैं: एक फाउंडेशन, एक डेवलपर्स समुदाय, या एक ही। फाउंडेशन प्रबंधन का सबसे स्थिर रूप हैं, कंपनियों के समान। के और यह वे बहुत अलग-अलग मॉडल के तहत काम करते हैं। Apache फाउंडेशन Eclipse फाउंडेशन लिनक्स फाउंडेशन एपैच फाउंडेशन परियोजनाओं पर काम करने वाले व्यक्तियों की व्यक्तिगत योग्यता पर आधारित है. वे बुनियादी ढांचे (एससीएम, ईमेल, निर्माण बुनियादी ढांचे, आदि) प्रदान करते हैं, लेकिन आप इसके अलावा अपने आप हैं. इसके विपरीत, , लिनक्स फाउंडेशन का हिस्सा, कंपनियों पर निर्माण करता है. एक कंपनी एक योगदान के द्वारा सीएनसीएफ का हिस्सा बन जाती है। सीएनसीएफ परियोजना को नियंत्रित करने वाला समूह जितना बड़ा है, उसमें प्रभाव डालने में अधिक समय लगेगा. प्रभाव आपके द्वारा वांछित दिशा में रोडमैप को चलाने के रूप में बड़ा हो सकता है, और एक बग को ठीक करने या यहां तक कि अपने स्वयं के सुधार को एकीकृत करने के रूप में छोटा हो सकता है. डेवलपर्स के साथ बातचीत तकनीकी विचारधारा वाले लोगों के लिए आसान होगी. किसी भी मामले में, अपने लक्ष्यों को आगे बढ़ाने के लिए राजनीति खेलने की उम्मीद करें, हालांकि नियंत्रण शरीर के आधार पर अलग-अलग नीतियों के साथ। परिपक्व एक निर्भरता जोड़ना एक समझौता है: आप समय बचाते हैं, लेकिन आप नियंत्रण खो देते हैं. यदि आप एक प्रोजेक्ट पर अपने सॉफ्टवेयर का निर्माण करते हैं जो रखरखाव नहीं किया जाता है, तो आपको अपनी कोड को कटौती करने के लिए या खुद को बनाए रखने के लिए अपने कोड को स्थानांतरित करने की आवश्यकता होगी. इस कारण से, आपको एक निर्भरता के लिए प्रतिबद्ध होने से पहले उचित जोखिम मूल्यांकन करना होगा. यहां परियोजना की परिपक्वता का मूल्यांकन करने के लिए कुछ डेटा बिंदु हैं: जब परियोजना बनाई गई थी? पुराने परियोजनाओं ने अधिक आत्मविश्वास पैदा किया। इसकी रिलीज इतिहास क्या है? रिलीज आवृत्ति जितनी अधिक नियमित होती है, उतनी ही बेहतर होती है। क्या परियोजना अपना मार्गदर्शिका घोषित करती है? यदि हाँ, तो यह कितना विस्तृत है? एक अस्पष्ट मार्गदर्शिका, या बिल्कुल भी नहीं, दृष्टि की कमी को धोखा देती है; एक बहुत विस्तृत, विशेष रूप से दूर भविष्य में, गतिशीलता या यथार्थवाद की कमी का संकेत हो सकता है। व्यावसायिक परियोजनाओं के लिए, क्या लंबे समय तक समर्थन जैसा कुछ है? गतिविधि ओपन सोर्स परियोजनाओं के लिए, आपको उनकी गतिविधि की जाँच करनी चाहिए. एक परियोजना अतीत में बहुत सक्रिय हो सकती है, लेकिन रास्ते में अपनी ड्राइव खो देती है. इस अनुभाग में, हमें निम्नलिखित आइटम की जाँच करनी चाहिए: कितने मुद्दे खुले हैं? एक समस्या को हल करने के लिए औसत समय क्या है? सबसे आम समाधान स्थिति क्या है? सबसे लंबे समय तक खुले मुद्दे क्या हैं? इन का जवाब आपको परियोजना के समग्र स्वास्थ्य के बारे में एक सुझाव देना चाहिए। परियोजना के लिए कितने खातों को प्रतिबद्ध किया जाता है? कितने खातों को नियमित रूप से ऐसा किया जाता है, अर्थात्, वे कितने कोर कमिटर हैं? दूसरे शब्दों में, बुश कारक क्या है? बुश कारक जितना अधिक है, उतना ही अधिक संभावना है कि परियोजना जारी रहेगी यदि एक कमिटर रुक जाता है। ऊपर दिए गए विषयों से संबंधित, मुख्य कमांडरों की प्रतिबद्धता का इतिहास क्या है? क्या कमांडरों को कई गैर-संबंधित परियोजनाओं के बीच फैलाया जाता है, या क्या वे उस पर ध्यान केंद्रित करते हैं जिसे आप निर्भर करते हैं? समर्थन समर्थन व्यापारिक समर्थन और सामुदायिक समर्थन दोनों को शामिल करता है। अधिकांश परिपक्व संगठनों के लिए, वाणिज्यिक समर्थन एक आवश्यकता है. वाणिज्यिक निर्भरताएं प्रकृति से इस तरह का समर्थन प्रदान करती हैं. ओपन-सॉर्ड परियोजनाओं के लिए, समर्थन परियोजनाओं के लिए समर्थन प्रदान करने वाली कंपनियों को अपने कोर व्यवसाय के हिस्से के रूप में प्रदान करता है. अधिकांश समय, इन कंपनियों ने प्रोजेक्ट पर काम करने वाले डेवलपर्स को रोजगार दिया। और के लिए समर्थन की पेशकश Apache फाउंडेशन द्वारा होस्ट किया गया। टमाटर नायकों टॉमकैट Servlet इंजन सामुदायिक समर्थन मुफ्त है, लेकिन यह भी सबसे अच्छा प्रयास है. कोई गारंटी नहीं है कि कोई आपके अनुरोधों का जवाब देगा, और यदि ऐसा है, तो कब। , GitHub, Slack, Google समूह, आदि, और जांचें: जी। जवाब देने वाले विभिन्न लोगों की संख्या एक जवाब और सवाल के बीच की देरी जवाब की गुणवत्ता विकास का अनुभव डेवलपर्स अनुभव, जिसे डीएक्स के रूप में भी जाना जाता है, एक अच्छे परियोजना और एक महान परियोजना के बीच महत्वपूर्ण विभेदों में से एक है। और निम्नलिखित समूहों में सामग्री को समूह करें: ट्यूटोरियल, How-to गाइड, संदर्भ गाइड, और स्पष्टीकरण। Divio सिस्टम अधिकांश परियोजनाएं पूरी तरह से संदर्भ दस्तावेज प्रदान करती हैं. कुछ एक त्वरित शुरुआत की पेशकश करते हैं. एक नए परियोजना पर मेरी पहली DevRel पहल आमतौर पर एक बनाने के लिए (या दूसरों को बनाने के लिए) जब यह खो जाता है. एक त्वरित शुरुआत की अनुपस्थिति एक अवरोधक है जब नए उपयोगकर्ताओं को इनबोर्ड करने के लिए। DX का एक और घटक खुद पर निर्भरता का उपयोग करने से आता है. मैं एक छोटे समय बॉक्स प्रोजेक्ट के भीतर एक प्रोटोटाइप की सिफारिश करता हूं, जो प्रदान की गई निर्भरता का उपयोग करता है. यह आपको डेवलपर्स अनुभव के लिए एक अच्छा एहसास देगा. यदि आप बहुत निवेश करते हैं, तो प्रतिस्पर्धी निर्भरताओं के कुछ प्रोटोटाइप को समानांतर में बनाना समझ में आता है. बाजार को अपनाने और पारिस्थितिकी तंत्र मैंने ऊपर उल्लेख किया है कि एक निर्भरता का चयन जोखिम प्रबंधन है. चूंकि हम सामाजिक जानवर हैं, हम उन लोगों पर भरोसा कर सकते हैं जिन्होंने हमारे सामने निर्भरता का चयन किया है कि उन्होंने सही निर्णय लिया है. खैर, जितनी अधिक संगठन निर्भरता का उपयोग करते हैं, उतनी अधिक संभावना है कि यह सही विकल्प है. हालांकि, गायों की मानसिकता सिंड्रोम के साथ सावधान रहें: मैं देखता हूं कि कई संगठन बस ऐसा करते हैं और कुछ चुनते हैं जो अन्य लोगों ने पूरी तरह से अलग संदर्भ में परीक्षण किया है. खांसी, माइक्रोसेस, खांसी। मैं इसके आसपास के पारिस्थितिकी तंत्र की जांच करने की भी सिफारिश करता हूं, अगर यह लागू होता है. एक सीएसवी पैसिंग निर्भरता स्पष्ट रूप से योग्य नहीं है, लेकिन एक एलडीएपी पढ़ना / लिखना है. कौन से एलडीएपी प्रदाताओं का समर्थन करता है? क्या यह एज़ूर डायरेक्टरी संगत है, आदि? अंत में, जांचें कि क्या एक या अधिक टीम के सदस्य पहले से ही निर्भरता के साथ परिचित हैं। मिसाल मैंने कभी भी निम्नलिखित मानदंडों में से कोई भी का उपयोग नहीं किया है; मैं विकसित नहीं करूंगा. हालांकि, वे आपके संदर्भ में प्रासंगिक हो सकते हैं. संवेदनशीलता प्रबंधन और प्रतिक्रिया समय स्वास्थ्य निर्भरता और अद्यतन आवृत्ति सार्वजनिक सुरक्षा नीति सार्वजनिक बेंचमार्क और प्रदर्शन मीट्रिक्स वास्तविक दुनिया के स्केलेबल उदाहरण कंपनी की स्थिरता और वित्तीय पारदर्शिता संक्षेप इस पोस्ट में, मैंने कई मानदंडों को सूचीबद्ध किया है जिन्हें आप निर्भरताओं का मूल्यांकन करने के लिए उपयोग कर सकते हैं. मुझे उम्मीद है कि यह उपयोगी साबित होगा. मूल रूप से प्रकाशित A Java Geek पर 2 नवंबर, 2025 जावा Geek