सही निर्भरताओं का चयन: एक व्यापक व्यावहारिक मार्गदर्शिका

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

अपने आप से तुरंत पहला प्रश्न पूछें: क्या आपको वास्तव में एक नई निर्भरता की आवश्यकता है? क्या मौजूदा वातावरण, जैसे भाषा या स्थापित पुस्तकालयों का उपयोग करके समस्या को हल किया जा सकता है? उदाहरण के लिए, UUID उत्पन्न करने के लिए अतिरिक्त लाइब्रेरी स्थापित करने की कोई आवश्यकता नहीं है। Node.js और ब्राउज़र इसे आउट ऑफ बॉक्स सपोर्ट करते हैं : crypto.randomUUID()

दूसरा प्रश्न: क्या आपको संपूर्ण पुस्तकालय की आवश्यकता है? उदाहरण के लिए, यदि आपको केवल ड्रॉपडाउन की आवश्यकता है, तो क्या यह बूटस्ट्रैप जैसी कोई चीज़ स्थापित करने के लायक है? शायद रेडिक्स यूआई से एक अनस्टाइल ड्रॉपडाउन घटक के साथ खुद को एक एकल, केंद्रित लाइब्रेरी तक सीमित करना बेहतर है?

ठीक है। हमारे दिमाग में कुछ उम्मीदवार हैं। तो, हम सही कैसे चुनें?

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

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

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

1. सुरक्षा

इसका इस्तेमाल कितना सुरक्षित है? यह काल्पनिक लग सकता है, लेकिन हां, निर्भरता खतरनाक हो सकती है। उदाहरण के लिए, 500k डाउनलोड के साथ एक लाइब्रेरी में एक दिलचस्प विशेषता जोड़ी गई : यह कंप्यूटर पर सभी फाइलों को ❤️ से बदलने की कोशिश करता है यदि आपका आईपी पता एक विशिष्ट सीमा के भीतर आता है।

एक दिलचस्प तथ्य यह है कि इस निर्भरता का उपयोग vue-cli में किया गया था। हम ऐसे मुद्दों का पता कैसे लगा सकते हैं? समस्या पृष्ठ की जाँच करें, या पुस्तकालय के नाम से गूगल करने का प्रयास करें। आमतौर पर ऐसी सूचनाएं जल्दी सामने आ जाती हैं।

2. रखरखाव

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

यहां गो की दुनिया से एक उदाहरण दिया गया है: 18.2K सितारों वाले पुस्तकालय के लेखकों ने अपनी निर्भरता को बनाए रखने और इसे संग्रहीत करने का फैसला किया। इसका मतलब है कि कुछ सालों में सपोर्ट और अपडेट की कमी एक समस्या बन जाएगी। अब पहले GitHub की जाँच किए बिना समान निर्भरता स्थापित करने की कल्पना करें। यह उत्पादों की समाप्ति तिथि की जाँच करने जैसा है।

यहाँ लगातार अच्छी रिलीज़ का एक उदाहरण दिया गया है:

3. ओपन/क्लोज्ड इश्यू

1. खुले इश्यू और बंद इश्यू का अनुपात क्या है? लेखक परिवर्तनों को स्वीकार करने के लिए कितने इच्छुक हैं? यह संभव है कि आपको किसी दिन कुछ योगदान करने की आवश्यकता हो। उदाहरण के लिए, यह पुस्तकालय काफी लोकप्रिय है और इसमें 98% प्रतिशत बंद मुद्दे हैं। केवल 18 खुले हैं।

   

   
   

2. महत्वपूर्ण मुद्दों को कितनी जल्दी हल किया जाता है? एक बार, मैंने 31k सितारों वाला एक ORM चुना, लेकिन किसी बिंदु पर, हमें एक समस्या का सामना करना पड़ा जिसने हमें ब्लॉक कर दिया। हमें वर्कअराउंड की तलाश करनी थी और अंततः दूसरे समाधान पर स्विच करना पड़ा। दुर्भाग्य से, लगभग चार साल बीत चुके हैं, और समस्या अभी भी हल नहीं हुई है।

   

   इस तरह के मुद्दों को सबसे ज्यादा कमेंट करके सॉर्ट करके पहचाना जा सकता है।

   
   

3. क्या योगदान प्रक्रिया को क्रिएटर्स ने व्यवस्थित किया है? क्या कोई स्पष्ट, परिभाषित कार्यप्रवाह मौजूद है? उदाहरण के लिए, Next.js के रचनाकारों ने अपनी योगदान प्रक्रिया के बारे में 40 मिनट का वीडियो भी रिकॉर्ड किया।

   
   

4. कोड गुणवत्ता

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

5. टेस्ट कवरेज

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

6. पुस्तकालय का आकार

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

वेब परियोजनाओं के लिए, पैकेज आकार निर्धारित करने के लिए एक बढ़िया टूल है: https://bundlephobia.com । बेशक, सर्वर-साइड रेंडरिंग और ट्री शेकिंग आकार को कम कर सकते हैं, लेकिन इसे हमेशा सत्यापित करने की आवश्यकता होती है।

एक लोकप्रिय उदाहरण दिनांक हेरफेर लाइब्रेरी है। Dayjs (2.9KB) द्वारा प्रदान की गई कार्यक्षमता पर्याप्त हो सकती है, जिससे मोमेंट.js (72.1KB) या दिनांक-fns (26.8KB) स्थापित करने की आवश्यकता समाप्त हो जाती है।

7. निर्भरता की संख्या

परियोजना के संपूर्ण निर्भरता वृक्ष में निर्भरता की संख्या से ऊपर सूचीबद्ध सभी बिंदुओं को कुछ हद तक गुणा किया जाता है। संपूर्ण डिपेंडेंसी ट्री की जांच करने के लिए एक बढ़िया टूल: https://npm.anvaka.com

8. लाइसेंस

क्या आपने कभी इस बारे में सोचा है? मेरे पास भी नहीं था। उदाहरण के लिए, MIT और Apache 2.0 लाइसेंस वाणिज्यिक परियोजनाओं में पुस्तकालयों के मुफ्त उपयोग की अनुमति देते हैं, जबकि कुछ GPL v2 लाइसेंसों की विशिष्ट आवश्यकताएं और प्रतिबंध हैं। हमारी परियोजनाओं में से एक में, हमारे पास एक वकील द्वारा तैयार की गई तालिका थी जो हमारे सभी निर्भरता पेड़ के लाइसेंसों की जांच करती थी। इसलिए यदि आप लाइसेंस में कुछ असामान्य देखते हैं, तो ऑडिट के दौरान समस्याओं से बचने के लिए वकील से परामर्श करना बेहतर होता है। हम कानूनी रूप से उपयोगिता का उपयोग करके मौजूदा एनपीएम निर्भरताओं से सभी लाइसेंस निकाल सकते हैं। पीएस मैं वकील नहीं हूं, और यह कानूनी सलाह नहीं थी। यह एक दुर्लभ और विशेष मामला है कि लाइसेंस के कारण कुछ उपयुक्त नहीं हो सकता है, लेकिन यह अभी भी संभव है।

समाप्त!

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

कृपया आपके पास कोई भी टिप्पणी या सुझाव छोड़ने के लिए स्वतंत्र महसूस करें। अपने अनुभव को टिप्पणियों में भी साझा करने में संकोच न करें। आपकी पसंद और टिप्पणियाँ मुझे नए लेख लिखने के लिए प्रेरित करती हैं। हैप्पी कुकिंग :)