कई परियोजनाओं पर समान कोड अंश कैसे बनाए रखें [बंद]


9

मैं कई Android परियोजनाओं पर काम करने वाला एक इंडी डेवलपर हूं। मुझे विभिन्न परियोजनाओं पर समान कार्यक्षमता बनाए रखने में समस्या हो रही है। उदाहरण के लिए, मेरे तीन ऐप्स समान 2 वर्गों का उपयोग करते हैं; चूंकि वे विभिन्न परियोजनाएं हैं, जब मुझे उन कक्षाओं में बदलाव करने की आवश्यकता होती है, तो मुझे इसे तीन बार बनाने की आवश्यकता होती है। क्या इस तरह की सामान्य समस्या का एक सरल समाधान है?


कैसे यह एक वास्तविक सवाल नहीं है ??
आंद्रे फिग्यूएरेडो

जवाबों:


15

साझा कोड को लाइब्रेरी में अलग करें, और प्रोजेक्ट्स में लाइब्रेरी शामिल करें।

Android डेवलपर के रूप में, आप संभवतः जावा का उपयोग कर रहे हैं। मावेन या आइवी जैसे निर्भरता प्रबंधन उपकरण का उपयोग करने पर विचार करें ।

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


2
निर्भरता प्रबंधन के लिए +1। सभी लोकप्रिय भाषाओं के लिए सभ्य विकल्प होने चाहिए।
एड्रियन श्नाइडर

11

संस्करण नियंत्रण। Git। गित सबमॉड्यूल।

अपने प्रोजेक्ट्स को संस्करण नियंत्रण में रखें, एक DVcs जैसे git या मर्क्यूरियल आदि का उपयोग करके साझा कोड को git में सबमॉड्यूल में रखें। जिन परियोजनाओं में इसकी आवश्यकता है, उनमें सबमॉड्यूल का उपयोग करें। जब आप सबमॉड्यूल को अपडेट करते हैं, तो एकल कमांड के साथ अन्य प्रोजेक्ट में परिवर्तन को खींच सकते हैं।


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

1
-1 के रूप में अच्छी तरह से। मैं इस बात पर भ्रमित हूं कि यह साझा पुस्तकालय से बेहतर कैसे है। यह सिर्फ गाली देने जैसा लगता है क्योंकि आप लाइब्रेरी बनाने से बिल्कुल मना करते हैं
TheLQ

5
खैर, git उपयोग करने के लिए सिर्फ एक उपकरण है। मैं इसका उपयोग कर रहा हूं, मैं इससे खुश हूं। आप इसका उपयोग कर सकते हैं, या इसका उपयोग करने से इंकार कर सकते हैं। तथ्य यह है, यह समस्या को हल करता है। मैं यह दावा नहीं करता कि यह समस्या का एकमात्र समाधान है।
हकन डेरिल सेप

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

2
लिंक के लिए +1 धन्यवाद! यदि साझा घटक सक्रिय विकास के अधीन है, तो इस समाधान में साझा पुस्तकालय समाधान की तुलना में स्पष्ट लाभ (IMHO) है।
JanDotNet

5

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

ऐसा करने के लिए कुछ विकल्प हैं: 1) एक आधार परियोजना बनाएं जो दूसरों पर निर्भर करता है। यह परियोजना एक द्विआधारी वितरण बना सकती है जो अन्य परियोजनाएं खपत करती हैं। 2) अपने संगठन के भीतर एक ओपन-सोर्स मॉडल खींचो। कॉमन कोड की अपनी कोड ब्रांच हो और अन्य प्रोजेक्ट्स उसी तरह से कोड में हों, जैसे आप किसी ओएसएस ऑनलाइन से सोर्स कोड लेते हैं।

अब यहाँ जहाँ तलवार आती है ...

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

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

यदि आपकी परियोजनाएं अलग-अलग रिलीज चक्रों पर हैं, तो आपको कॉमन कोड के प्रबंधन के बारे में और भी अधिक सावधान रहने की आवश्यकता है। यदि आप प्रोजेक्ट C के लिए अंतिम छवि को काटने से 3 दिन दूर हैं, तो आप केवल सामान्य कोड में परिवर्तन नहीं कर सकते क्योंकि प्रोजेक्ट B को नई कार्यक्षमता की आवश्यकता है।

मैं यह नहीं कह रहा हूँ कि सामान्य पुस्तकालय सही समाधान नहीं है। मैं DRY का एक मजबूत समर्थक हूं और मैंने इससे पहले भी कॉमन कोड बनाया और सपोर्ट किया है। बस इसे बाहर रखना चाहता था कि बस कोड को सामान्य बनाने के अपने खर्च होंगे।

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

कुछ सुझाव जो मैं दे सकता हूं:

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

1

यह एक आदर्श समाधान है, और काम करने के लिए कुछ प्रयास कर सकते हैं।

DRY सिद्धांत कहता है कि सत्य का एक ही आधिकारिक स्रोत होना चाहिए। यह बिना किसी दोहराव के, सभी प्रोग्राम लॉजिक के लिए एकल स्रोत रिपॉजिटरी के उपयोग को निर्देशित करता है ; फ़ाइलों को साझा करने और दस्तावेजों के पुन: उपयोग को बढ़ावा देने के लिए आयोजित किया गया।

एक वितरित, बहु-टीम वातावरण में संचार की व्यावहारिक आवश्यकताएं बताती हैं कि प्रत्येक परियोजना या सहयोग के लिए एक से अधिक स्वतंत्र भंडार होने चाहिए।

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

:-)

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

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

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

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