आंतरिक अनुप्रयोगों के लिए आंतरिक पुस्तकालयों का विकास क्यों करें?


10

मुझे यह समझने में कठिनाई हो रही है कि आपको आंतरिक अनुप्रयोगों के विकास के लिए आंतरिक पुस्तकालयों का उपयोग क्यों करना चाहिए। मैं सराहना करता हूं कि अगर मैं सॉफ्टवेयर का उपयोग करना चाहता हूं जो संगठन के बाहर किसी ने लिखा है तो वे मुझे अपनी हेडर फाइलें और .a या .so फाइलें भेज सकते हैं और मैं इसे केवल अपनी परियोजना से जोड़ सकता हूं (यह मानते हुए कि वे उसी वातावरण में संकलित हैं) ।

लेकिन जब मुझे हेडर और कार्यान्वयन फ़ाइलों तक पहुंच होती है तो एक आंतरिक पुस्तकालय को केवल एक आंतरिक अनुप्रयोग से जुड़ा होने के लिए क्यों विकसित किया जाना चाहिए और उन्हें सिर्फ अपने स्रोत के पेड़ में शामिल कर सकते हैं और उन सभी को एक साथ संकलित कर सकते हैं?

दूसरे शब्दों में: यदि कुछ स्रोत कोड लिखे गए हैं, तो आप यह कैसे तय करते हैं कि इसे बाइनरी लाइब्रेरी में संकलित किया जाना चाहिए और आपके आवेदन से जुड़ा होना चाहिए या केवल प्रोजेक्ट के स्रोत फ़ाइलों में शामिल किया जाना चाहिए और नियमित रूप से संकलित किया जाना चाहिए?

जब मैं कहता हूं कि प्रत्येक परियोजना में फाइलें शामिल हैं, तो मेरा मतलब वर्तमान में विकसित की जा रही परियोजना के स्रोत वृक्ष में प्रत्येक फाइल को कॉपी और पेस्ट करना नहीं है। मेरा मतलब है कि कुछ डायरेक्टरी / लाइब्रेरी (किसी भी प्रोजेक्ट के लिए अलग) में कॉमन सोर्स कोड है, जिसे प्रोजेक्ट के फाइल्स में सामान्य तरीके से शामिल किया जा सकता है, यानी #include।

ps मैं कई डेस्कटॉप अनुप्रयोगों के लिए यहाँ c / c ++ विकास के बारे में बात कर रहा हूँ।


जवाबों:


25

आंतरिक उपयोग के लिए भी पुस्तकालयों और साझा पुस्तकालयों, (.dll या .so फ़ाइलों) को बनाने के कई कारण हैं :

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

कुछ कंपनियों के पास एक लेखांकन अभ्यास भी होता है जहां पुस्तकालय बनाने वाली परियोजनाएं प्रत्येक पुन: उपयोग पर कुछ प्रतिपूर्ति प्राप्त करती हैं।


1
या बिंदु 9 की भिन्नता में, आप लाइब्रेरी को मुख्य एप्लिकेशन कोड की तुलना में एक अलग लाइसेंस के तहत जारी कर सकते हैं।
माइकल बोर्गवर्ड

@MichaelBorgwardt - गुड पॉइंट प्रॉम्प्टिंग पॉइंट 10 से ऊपर।
स्टीव बार्न्स

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

11

कुछ अन्य संभावित कारण जो बड़ी, गैर-औद्योगिक परियोजनाओं पर लागू हो सकते हैं:

  • संकलन समय: विशाल अखंड C ++ हजारों फाइलों, हजारों वर्गों, कार्यों आदि के साथ प्रोजेक्ट करता है, संकलन करने के लिए बहुत लंबा समय ले सकता है (जो उत्पादकता को नुकसान पहुंचाता है यदि आप हर बार जब आप कोड की कुछ पंक्तियों को बदलते हैं तो पुनर्मिलन करना चाहते हैं)। स्टैटिकली-लिंक्ड और डायनेमिकली लिंक्ड लाइब्रेरियों को स्वतंत्र रूप से संकलित किया गया है और यदि उनके स्रोत में बदलाव नहीं हुआ है तो उन्हें पुन: कनेक्ट करने की आवश्यकता नहीं है।

  • अलग-अलग मॉड्यूल या सबसिस्टम की तार्किक पृथक्करण : बड़ी प्रणालियों को आमतौर पर प्रबंधित करना आसान होता है यदि कार्यक्षमता के अलग-अलग क्षेत्रों को अलग-अलग मॉड्यूल में रखा जाता है, और डेवलपर्स को हजारों फ़ाइलों / कक्षाओं वाले विशाल फ़ोल्डर / परियोजनाओं के माध्यम से खोज करने का सामना नहीं करना पड़ता है।

  • डेवलपर्स / टीमों के बीच की सीमाएं : एक ही समय में अलग-अलग नई कार्यक्षमता का निर्माण करने वाले डेवलपर्स विलय की संभावनाओं को कम कर सकते हैं यदि प्रत्येक डेवलपर के लिए अलग-अलग मॉड्यूल में काम करना संभव हो।

  • कोड जिसे एक जीवित वातावरण में जारी नहीं किया जाना चाहिए : उदाहरण के लिए, यूनिट टेस्ट लाइब्रेरी या 'मॉक' लाइब्रेरी जो कि डेवलपर सिस्टम के लिए लाइव सिस्टम घटक (हार्डवेयर, एपीआई, रिमोट सिस्टम, डेटाबेस, आदि) के विकल्प के लिए उपयोग किया जाता है।

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

  • वैकल्पिक विशेषताएं / अनुकूलन : बड़ी प्रणालियों में, कोई एप्लिकेशन कुछ समय में गतिशील रूप से लिंक किए गए मॉड्यूल को मेमोरी में लोड करने से पहले प्रतीक्षा कर सकता है यदि वे अनुप्रयोग की मूल कार्यक्षमता के लिए महत्वपूर्ण नहीं हैं।


सामान्य तौर पर, कई आंतरिक परियोजनाएं अक्सर छोटे माइक्रो-ऐप होती हैं जो अलग-अलग पुस्तकालयों में टूट जाने से लाभ नहीं उठाती हैं। यदि आप एक छोटे से प्रोजेक्ट पर एक अकेला डेवलपर के रूप में काम कर रहे हैं, तो आपको अपने कोड को पुस्तकालयों में विभाजित करने के बारे में चिंता करने की आवश्यकता नहीं है (अभी तक ...)। YAGNI सिद्धांत को न भूलें ।


3
@downvoter - क्या आप डाउनवोट का कारण बता सकते हैं? हर किसी के लिए इस साइट की गुणवत्ता में सुधार करने के लिए उत्तरों पर प्रतिक्रिया उपयोगी है।
बेन कॉटरेल

4

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

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

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


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

@AndrewMurtagh: यह तथ्य कि आप इतनी जल्दी माइकलबॉर्वर्ड के जवाब को स्वीकार कर रहे थे, मुझे आश्चर्य हुआ, क्योंकि उन्होंने जो लिखा था, वह उनके या मेरे बारे में गलतफहमी थी।
डॉक ब्राउन

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

2

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

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

एक उपयोग के मामले के लिए "लाइब्रेरी" लिखना बिना किसी अदायगी के एक बहुत ही महंगे अभ्यास में बदल सकता है --- मुझे कई बार इस बात से काट लिया गया है।

उदाहरण लागत:

  1. "सामान्य" मामलों का उपयोग करने पर विचार करने में लगने वाला समय / ऊर्जा
  2. समय अपने "ग्राहक" (अपने स्वयं के कोड) के लिए "पुस्तकालय" वितरित करने में बिताया
  3. "लाइब्रेरी" का उपयोग करने के लिए भविष्य का दबाव भले ही यह अगले उपयोग के मामले से पूरी तरह से मेल न खाता हो

मेरा सामान्य नियम है: जब तक मुझे कम से कम 2 अलग-अलग स्थानों पर कोड की आवश्यकता न हो, तब तक एक पुस्तकालय में कोड न बनाएं।


2
मैंने कुछ डेवलपर्स द्वारा उपयोग किए जाने वाले लगभग समान कारणों को देखा है कि उनका कोड एक सिंगल> 20k लाइन सोर्स फाइल में क्यों है। जब quirky नामकरण और घटिया टिप्पणियों के साथ संयुक्त रूप से आपके पास जल्द ही कोड है कि इसे बनाए रखने की तुलना में फिर से लिखना तेज है।
स्टीव बार्न्स

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

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

1

जब मैं शीर्ष लेख और कार्यान्वयन फ़ाइलों तक पहुँच प्राप्त कर सकता हूं, तो एक आंतरिक पुस्तकालय को केवल एक आंतरिक अनुप्रयोग से जुड़ा होने के लिए क्यों विकसित किया जाना चाहिए और उन्हें अपने स्रोत के पेड़ में शामिल कर सकता है और उन सभी को एक साथ संकलित कर सकता है?

क्योंकि अगर आप "बस उन्हें मेरे स्रोत के पेड़ में शामिल करते हैं", तो आप कोड की नकल कर रहे हैं ।

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

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

अंत में, तकनीकी कारण हो सकते हैं - एक पुस्तकालय के रूप में कोड का हिस्सा रखना आवश्यक हो सकता है, इसलिए इसे वैकल्पिक रूप से लोड किया जा सकता है या यहां तक ​​कि लोड किया जा सकता है और मांग पर लोड किया जा सकता है, और इस तरह से स्मृति उपयोग को कम किया जा सकता है जब फिजूलियत की आवश्यकता नहीं है?


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

@AndrewMurtagh: हाँ, यह बहुत अच्छा है कि मैं इसे कैसे डालूँगा। हालाँकि इसके तकनीकी कारण भी हो सकते हैं; मैं C / C ++ विकास से परिचित नहीं हूं - हो सकता है कि एक पुस्तकालय के रूप में कोड का हिस्सा रखना आवश्यक है, इसलिए इसे वैकल्पिक रूप से लोड किया जा सकता है या यहां तक ​​कि लोड किया जा सकता है और मांग पर लोड किया जा सकता है, और इस तरह से स्मृति उपयोग को कम किया जा सकता है जब fuctionality की आवश्यकता नहीं है?
माइकल बोर्गवर्ड

मेरा मानना ​​है कि साझा पुस्तकालयों के माध्यम से यह संभव हो सकता है। स्पष्ट करने के लिए धन्यवाद, मैं आपके उत्तर को स्वीकार करूँगा।
एंड्रयू मुर्टाग

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

रख-रखाव में भी सोचें। 1) परिवाद को स्वतंत्र और समानांतर रूप से बनाए रखा जा सकता है। 2) क्या कोड को बदलना आसान है। 3) छोटे कोड का आधार छोटी टीमों के लिए प्रबंधन करना आसान है और हर किसी के लिए समझना आसान है। 4) यदि समय-समय पर बाजार महत्वपूर्ण है, तो आप तेजी से निर्माण करना पसंद करेंगे। कोड ऑफ लिबास में वह कोड होता है जिसे आप पाइपलाइन (IMO) में बार-बार संकलित नहीं करते हैं। 5) यह विश्वसनीय पुन: प्रयोज्य कोड है ... आपने इसे बनाया ;-)
Laiv

1

मैं लंबे समय में आपके समाधान की लागतों पर विस्तार से बताना चाहूंगा।

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

हालाँकि, जैसा कि आपकी परियोजना बढ़ती है, "छद्म-पुस्तकालय" की लागत भी होगी। मान लें कि आपके पास "छद्म-पुस्तकालय" है Aजिसका उपयोग किसी एप्लिकेशन और इकाई परीक्षक द्वारा किया जाता है। हर बार जब आप एक सीपीयू जोड़ते हैं A, तो आपको इसे दोनों परियोजनाओं में जोड़ना होगा, अन्यथा वे लिंक नहीं करेंगे।

यदि आपका "छद्म-पुस्तकालय" किसी अन्य "छद्म-पुस्तकालय" द्वारा उपयोग किया जाता है तो क्या होगा B? आपको परियोजनाओं के एक समूह में अपने नए सीपीपी को जोड़ना होगा। और अगर Bएक और पुस्तकालय का उपयोग करने के लिए स्विच? आपको Aसभी परियोजनाओं में से केवल के आधार पर cpps को हटाना होगा B

यह सब मुफ्त में होगा यदि एक वास्तविक पुस्तकालय का उपयोग किया जाएगा। तो सवाल यह है कि एक वास्तविक पुस्तकालय में कदम को सही ठहराने के लिए कितने cpps की आवश्यकता है?

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

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


0

लेकिन जब मुझे हेडर और कार्यान्वयन फ़ाइलों तक पहुंच होती है तो एक आंतरिक पुस्तकालय को केवल एक आंतरिक अनुप्रयोग से जुड़ा होने के लिए क्यों विकसित किया जाना चाहिए और उन्हें सिर्फ अपने स्रोत के पेड़ में शामिल कर सकते हैं और उन सभी को एक साथ संकलित कर सकते हैं?

यदि पुस्तकालय का उपयोग केवल एक आवेदन द्वारा किया जाता है, तो संभवतः आपको एक अलग पुस्तकालय के रूप में इसकी आवश्यकता नहीं है

पुस्तकालय 3500 अनुप्रयोगों के द्वारा प्रयोग किया जाता है, तो आप पूरी तरह से करना एक अलग पुस्तकालय के रूप में यह की जरूरत है।

क्या होगा अगर लाइब्रेरी में कोई बग है और आपको इसे ठीक करने की आवश्यकता है? या कुछ सांविधिक या नियामक परिवर्तन यह है कि इसका मतलब है आप साथ आता है जिस तरह से काम करता है पुस्तकालय को बदलने के लिए?

यदि यह एक अलग पुस्तकालय में है तो आप (संभावित रूप से) पुस्तकालय को ठीक कर सकते हैं, इसका पुन: परीक्षण कर सकते हैं और इसे फिर से तैनात कर सकते हैं और हर आवेदन को फिक्स से लाभान्वित कर सकते हैं।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.