घर पुन: प्रयोज्य पुस्तकालयों में - डीएल या परियोजनाओं के रूप में पुन: उपयोग करें?

Question

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

(सुनिश्चित नहीं हैं, क्योंकि वहाँ केवल दो जवाब हैं अगर यह सीडब्ल्यू होना चाहिए और मैं अपनी प्राथमिकताएँ के बारे में सीखने में रुचि होगी)

Answer 1

यहां पर विचार करने के लिए कुछ चीज़ें हैं।

• उन पुस्तकालयों को संकलन में कितना अतिरिक्त समय लगता है, और क्या आपको परवाह है?
• आपको उनमें बग को ठीक करने की कितनी बार आवश्यकता है?

मैं किसी भी कोड के लिए precompiled पुस्तकालयों का उपयोग करता हूं जो महीनों में नहीं बदलता है। यदि मुझे पैकेज में महीने में एक से अधिक बार कुछ कोड बदलने की ज़रूरत है तो वह पैकेज प्रीकंपल नहीं किया गया है।

मैं मुख्य कार्यक्रम के संकलन को तेज करने के लिए precompiling पसंद करते हैं। लेकिन मैं हमेशा प्रीकंपाइल में डीबग प्रतीकों को शामिल करता हूं, इसलिए यदि कोई त्रुटि होती है तो मैं प्रीकंपिल्ड असेंबली के माध्यम से जितनी आसानी से आराम कर सकता हूं।

Answer 2

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

Answer 3

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

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

मेरा दृष्टिकोण संबंधित पुस्तकालयों के समाधान बनाने के लिए है; उदाहरण के लिए, मेरे पास कोर इंटरफेस और अमूर्त कक्षाओं के लिए एक असेंबली हो सकती है, विभिन्न ठोस कार्यान्वयन के लिए कुछ अन्य असेंबली, यूनिट परीक्षणों के लिए दूसरा, और इसी तरह। यदि निर्भर पुन: प्रयोज्य पुस्तकालयों की परतें हैं तो वे अक्सर एक ही समाधान में फंस जाएंगे।

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

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

Answer 4

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

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

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

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

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