किसी और ने अभी तक दोधारी तलवार का उल्लेख नहीं किया है, इसलिए मैं अपने 2 सेंट जोड़ूंगा। यदि आपके पास कई परियोजनाएं हैं और वे सभी कुछ पुन: प्रयोज्य कोड साझा करते हैं, तो अच्छी प्रोग्रामिंग प्रथाओं / सिद्धांतों (उदाहरण के लिए DRY) के अनुसार, आपको कोड को एक वैश्विक स्थान पर रखना चाहिए और इसे इस तरह से संरचना करना चाहिए ताकि इसे सभी द्वारा साझा किया जा सके बिना किसी संशोधन के आपकी परियोजनाएँ। दूसरे शब्दों में, हर किसी के अनुरूप सामान्य और सामान्य होने के लिए इंटरफेस को परिभाषित करें।
ऐसा करने के लिए कुछ विकल्प हैं: 1) एक आधार परियोजना बनाएं जो दूसरों पर निर्भर करता है। यह परियोजना एक द्विआधारी वितरण बना सकती है जो अन्य परियोजनाएं खपत करती हैं। 2) अपने संगठन के भीतर एक ओपन-सोर्स मॉडल खींचो। कॉमन कोड की अपनी कोड ब्रांच हो और अन्य प्रोजेक्ट्स उसी तरह से कोड में हों, जैसे आप किसी ओएसएस ऑनलाइन से सोर्स कोड लेते हैं।
अब यहाँ जहाँ तलवार आती है ...
कोड को एक सामान्य स्थान पर रखना जो अन्य परियोजनाओं / लोगों पर निर्भर करता है, बल्कि महंगा हो सकता है। मान लें कि आपके पास कोड का एक टुकड़ा है और 4 अन्य परियोजनाएं इस पर निर्भर हैं। आपका एक ग्राहक जो प्रोजेक्ट ए का उपयोग करता है, वह बग ढूंढता है और आपको एक फिक्स करना पड़ता है। आप फ़िक्स आउट करते हैं और वह ग्राहक खुश होता है। लेकिन आपने अभी कुछ कोड को संशोधित किया है जो 3 अन्य परियोजनाओं पर निर्भर करता है। क्या आप सुनिश्चित करने के लिए उन सभी को फिर से तैयार करते हैं कि कोई किनारे की स्थिति पेश नहीं की गई थी?
कॉमन कोड को भी अधिक सावधानी से तैयार किया जाना चाहिए और मॉड्यूल इंटरफेस को बहुत बेहतर तरीके से डिज़ाइन किया जाना चाहिए क्योंकि उस कोड को एक नहीं बल्कि 4 क्लाइंट्स को समायोजित करना होगा और उनमें से प्रत्येक को इस कोड का उपयोग कभी भी बहुत कम अंतर के साथ करना होगा।
यदि आपकी परियोजनाएं अलग-अलग रिलीज चक्रों पर हैं, तो आपको कॉमन कोड के प्रबंधन के बारे में और भी अधिक सावधान रहने की आवश्यकता है। यदि आप प्रोजेक्ट C के लिए अंतिम छवि को काटने से 3 दिन दूर हैं, तो आप केवल सामान्य कोड में परिवर्तन नहीं कर सकते क्योंकि प्रोजेक्ट B को नई कार्यक्षमता की आवश्यकता है।
मैं यह नहीं कह रहा हूँ कि सामान्य पुस्तकालय सही समाधान नहीं है। मैं DRY का एक मजबूत समर्थक हूं और मैंने इससे पहले भी कॉमन कोड बनाया और सपोर्ट किया है। बस इसे बाहर रखना चाहता था कि बस कोड को सामान्य बनाने के अपने खर्च होंगे।
यदि आप इस कोड का पुन: उपयोग कर रहे हैं, तो यह उतना बुरा नहीं है। यदि आपके पास इंजीनियरों की एक टीम है और वे सामान्य कोड का उपयोग करना शुरू करते हैं, तो खर्च और भी अधिक बढ़ जाता है। यदि अन्य लोग शामिल हैं, तो उम्मीद करें कि कोड को एक सामान्य लाइब्रेरी में रखने के लिए 3 गुना ज्यादा समय लगेगा क्योंकि इसे एक बिंदु पर ले जाना होगा जहां आपको लगता है कि यह "पूर्ण" है। आपको सभी प्रकार की किनारे की स्थितियों और अवैध उपयोग से बचाने के लिए पुस्तकालय को और अधिक मजबूत बनाने की आवश्यकता होगी, बी) प्रलेखन प्रदान करें ताकि अन्य पुस्तकालय का उपयोग कर सकें और सी) अन्य लोगों को डिबग करने में मदद करें जब वे पुस्तकालय का उपयोग इस तरह से करते हैं कि आप प्रत्याशित नहीं है और आपके दस्तावेज़ ने उनके विशिष्ट उपयोग के मामले को कवर नहीं किया है।
कुछ सुझाव जो मैं दे सकता हूं:
- स्वचालित इकाई परीक्षणों द्वारा कवर किया गया सामान्य कोड होने से आप एक लंबा रास्ता तय कर सकते हैं और आपको कुछ मन दे सकते हैं कि जब आप कोई बदलाव करते हैं, तो आप किसी अन्य परियोजना को तोड़ नहीं सकते।
- मैं केवल बहुत स्थिर कार्यक्षमता को सामान्य कोड में रखूंगा। यदि आपने टाइमर प्रबंधन करने के लिए पिछले साल एक वर्ग लिखा था और आपने इसे 9 महीनों में नहीं बदला है और अब आपके पास 3 अन्य परियोजनाएं हैं जिनकी समयबद्धता की आवश्यकता है, तो सुनिश्चित करें कि यह एक अच्छा उम्मीदवार है। लेकिन अगर आपने अभी पिछले हफ्ते कुछ लिखा है, तो ठीक है ... आपके पास इतने विकल्प नहीं हैं (और मुझे कॉपी / पेस्ट कोड से शायद अगले आदमी से ज्यादा नफरत है) लेकिन मैं इसे आम बनाने के बारे में दो बार सोचूंगा।
- यदि कोड का टुकड़ा तुच्छ है, लेकिन आपने इसे कई स्थानों पर उपयोग किया है, तो शायद बुलेट को काटने के लिए बेहतर है, अकेले DRY छोड़ दें और कई प्रतियों को लाइव होने दें।
- कभी-कभी यह सामान्य कोड को एक सामान्य स्थान में नहीं रखने के लिए भुगतान करता है और सभी को इसका संदर्भ मिलता है। लेकिन इसके बजाय कॉमन कोड को संस्करणों, रिलीज की तारीखों और हर चीज के साथ अपनी तरह के भरोसेमंद माना जाता है। इस तरह प्रोजेक्ट C कह सकता है, "मैं सामान्य पुस्तकालय v1.3 का उपयोग करता हूं" और यदि प्रोजेक्ट D को नई कार्यक्षमता की आवश्यकता है, तो आप v1.3 को अकेले छोड़ दें, v1.4 को छोड़ दें और प्रोजेक्ट C प्रभावित नहीं होता है। ध्यान रखें, यह एक समान स्थान पर जाँच करने के बजाय अपने स्वयं के उत्पाद के रूप में आम कोड का इलाज करने के लिए अधिक महंगा है, बहुत महंगा है।