हम जल्द ही हमारी कंपनी के नाम को बदलने की योजना बना रहे हैं। हमारे सभी नामस्थान, प्रोजेक्ट इत्यादि XYZ.ComponentName का उपयोग करते हैं।कंपनी का नाम बदल रहा है ... क्या हम नामस्थान बदलते हैं?
मेरा प्रश्न आपको हमारे नामस्थानों को बदलना चाहिए? सभी पुराने घटकों को एबीसी में बदलें। कॉम्पोनेंटनाम? पुराने लोगों को छोड़ दें लेकिन कोई भी नया विकास एबीसी बन गया है। कॉम्पोनेंटनाम? बस पुराने नाम से चिपके रहें?
यह निर्भर करता है।
कुछ चीजों पर विचार करना: यदि नामस्थान बदलना मतलब है सीवीएस में फ़ाइलों को ले जाना, तो एक दंड है क्योंकि आप इतिहास खो देते हैं। यदि नेमस्पेस को बदलना मैन्युअल काम है, तो आप स्थानों को याद करने और बग का कारण बनने जा रहे हैं।
इसके अलावा, क्या आपके पास कोड/पुस्तकालयों के बाहरी उपयोगकर्ता हैं? अगर उन्हें अपना कोड बदलना है क्योंकि आपने कंपनी का नाम बदल दिया है, तो वे नाराज होंगे।
मैं कोड को जिस तरह से छोड़ सकता हूं उसे छोड़ने के इच्छुक हूं। टकराव को रोकने के अलावा नेमस्पेस व्यर्थ हैं; इस बिंदु पर यह केवल विपणन है। लेकिन नए उत्पादों के लिए मैं निश्चित रूप से एक नए नाम का उपयोग करना चाहता हूं।
जहां मैं काम करता था, हमारे पास कुछ कंपनी-नाम या ऐप-नाम परिवर्तन होते थे और यह हमेशा समस्याग्रस्त था। आखिरी मिनट में वैश्विक नामस्थान परिवर्तन से बग को बाहर निकालने के दौरान एक आवेदन में कुछ हफ्तों तक देरी हुई थी। एक अन्य एप्लिकेशन ने नए नामों को कभी नहीं अपनाया और हमेशा अप्रचलित नाम से आंतरिक रूप से संदर्भित किया गया, संभावित रूप से नए उपयोगकर्ताओं के लिए भ्रमित। कल्पना करें कि जावा में सब कुछ अभी भी 'ओक' कहा जाता है।
एफवाईआई: यदि आप संस्करण नियंत्रण के लिए पर्सफोर्स का उपयोग करते हैं, तो आप उस इतिहास को खोना नहीं चाहते हैं। यह शाखाओं में भी एक फ़ाइल का इतिहास ट्रैक करता है (एक नाम वास्तव में एक शाखा होता है और संचालन हटाता है)। उन्होंने पिछले वर्ष या दो में बहुत उपयोगी कार्यक्षमता को जोड़ा। – raven
@ रेवेन .. वीएसएस के लिए भी एक स्ट्राइक करें - बदलाव के लिए .. lol –
@raven: हाँ, सीवीएस नामों में फ़ाइल संशोधन को ट्रैक करने के बारे में सबसे खराब अपराधी है।लेकिन यह अभी भी बहुत आम है। हम अभी इसके लिए मेरे काम पर फंस गए हैं ... श्वास। –
नामांकनों को मिलाकर मिलान करना अक्सर रखरखाव दृष्टिकोण से बहुत परेशानी और भ्रमित होता है। मैं कहूंगा कि यह वास्तव में उन घटकों की संख्या पर निर्भर करता है जिनके साथ आप काम कर रहे हैं और कितने एप्लिकेशन उनके पर निर्भर हैं।
शायद निर्भरताओं को मानचित्रित करना और आपके हाथों पर कितना काम मिल गया है, यह महसूस कर लेंगे।
यही पर निर्भर करता है, तो घटक स्थिर रहे हैं, ज्यादा इस्तेमाल किया है, अगर यह ज्यादा समय बदलने के लिए करने के लिए नहीं है, इसे बदलने के लिए वहाँ है अगर समय पैसा और डेवलपर्स ...
अगर के बहुत सारे।
मैं शायद उन्हें बस छोड़ दूंगा। उन्हें बदलने से काम, परीक्षण और सत्यापन में एक दुःस्वप्न पैदा होता है, और यदि कोई बाहरी रूप से आपकी लाइब्रेरी का उपयोग करता है तो उन्हें भी इस बदलाव को समायोजित करने के लिए अपनी बाइंडिंग बदलनी होगी।
जब ऐप्पल द्वारा अगला खरीदा गया था, तो उन्होंने एनएस उपसर्ग को छोड़ दिया है, आप आज इसे ऐप्पल के विकास ढांचे के साथ देख सकते हैं। यह आपको उन्हें छोड़ने के लिए मार नहीं देगा।
नए नामस्थानों के लिए आप इसे एबीसी में बदल सकते हैं लेकिन फिर आप स्थिरता तोड़ देंगे, जो लोगों को भ्रमित कर सकता है - खासकर नए डेवलपर्स।
बस इसे छोड़ के रूप में है और अन्य बातों :)
इसके अलावा, देखना है, तो आपको लगता है कि तब तोड़ सकते हैं के रूप में प्रतिबिंब का उपयोग करता है निर्भरता इंजेक्शन किसी भी प्रकार का कर रहे हैं के बारे में चिंता।
एक और समस्या तीसरी पार्टी कोड या अन्य परियोजनाएं हैं जो आपकी परियोजना का उपयोग करती हैं, यदि नाम हैं तो नामस्थान बदलना उन्हें तोड़ देगा।
सबसे सुरक्षित विकल्प नामस्थानों को छोड़ना है।
जो भी विकल्प आप बनाते हैं, नए विकास पर दो नामस्थानों को मिश्रण न करें। निरतंरता बनाए रखें। यदि आप पुराने व्यक्ति के साथ रहना चुनते हैं, तो नए विकास को भी इसका इस्तेमाल करना चाहिए। यदि आप एक नए स्थान पर जाते हैं, तो सब कुछ ले जाएं।
इसे अपने विशेष परिदृश्य से जुड़े कार्यों के कुछ और विश्लेषण की आवश्यकता हो सकती है ताकि यह तय किया जा सके कि यह स्विच करने के लायक है या नहीं।
हम अपने नामस्थानों को मिलाते हैं ... यह बिल्कुल कोई समस्या नहीं पैदा करता है। यह नए आर्किटेक्चर से विरासत आर्किटेक्चर को अलग करने का एक शानदार तरीका है :) – Precipitous
प्रीपिस के लिए +1, केवल इसलिए कि यह ऐसा करने का लाभ बताता है। जैसा कि मैंने नीचे बताया है, मुझे लगता है कि आपको इसके लिए नामस्थान का उपयोग नहीं करना चाहिए, और यह स्थिति दिखाती है कि क्यों। –
क्या आप उन घटकों को तीसरे पक्षों को बेच रहे हैं? यदि नहीं, तो यह प्रयास के लायक नहीं है। यदि आप हैं, तो नामस्थान आपके विपणन का हिस्सा है और इसलिए बदला जाना चाहिए।
यह इस तरह के परिदृश्यों में मेरा अनुभव रहा है, कि वर्तमान में नामस्थान छोड़ना सबसे अच्छा है। विकसित कोई भी नई पुस्तकालय नामस्थान में नई कंपनी के नाम का उपयोग कर सकते हैं।
वर्तमान अचार के लिए आप स्वयं को पाते हैं, मैं कोड को ठीक करने के लिए साइनेज बदलने वाले बजट से कुछ $$ मांगूंगा। अगर वे आपको यह नहीं देते हैं, तो पुराना नाम छोड़ दें।
मुझे लगता है कि उचित उत्तर यह है कि आप अपनी कंपनी के नाम के साथ नाम स्थान बनाते हैं पहले स्थान पर। बहुत सारे लोग जानते हैं कि उनके पेचेक पर हस्ताक्षर कौन करते हैं; आप कोड में नाम को स्थापित करके कोई भ्रम नहीं करते हैं।
मेरे पास एक सहकर्मी था जिसने एक दिन नामस्थान खोजे, और अगली बात मुझे पता था कि हमारी पूरी सॉफ्टवेयर लाइब्रेरी को हमारी कंपनी, विभाजन और परियोजना को नामित नामस्थानों की कई परतों के माध्यम से पहुंचा जाना है। बात यह है कि, हमारे पास केवल एक परियोजना है (हालांकि आप मुझे इसके लाभ के बारे में समझ सकते हैं), अन्य डिवीजन सॉफ्टवेयर नहीं करते हैं, और कोड जो हम अन्य कंपनियों से लेते हैं, उनकी योजना का पालन नहीं करते हैं। तो वास्तव में यह सिर्फ इतना बेकार अतिरिक्त टाइपिंग है जो हमें करना है। हां, हम "उपयोग" कर सकते हैं, लेकिन तब नामस्थानों के लिए कोई वास्तविक लाभ नहीं है। ओह, और निश्चित रूप से हमारे विभाजन का नाम कुछ साल बाद बदल गया, जब प्रबंधन ने "विभाजन" को विचलित करने का फैसला किया, और अब हमें "टीम" कहा जाना चाहिए। % - (
जब भी आपके पास कई कक्षाएं होती हैं, तो आप वास्तव में सबसे अच्छी तरह से उपयोग किए जाते हैं, जिन्हें आप उसी स्ट्रिंग के साथ स्टार्टिम (या कहीं भी) नाम देने के लिए लुभाने के लिए प्रेरित होंगे। वे आपके सॉफ़्टवेयर विकास समूह की वर्तमान प्रबंधन रिपोर्टिंग संरचना को मिरर करने के लिए नहीं हैं।
ठीक है, कंपनी के नाम का उपयोग नहीं करना चीजों से संपर्क करने का एक तरीका है, लेकिन कभी-कभी उद्योग मानक नहीं होता है: जावा के पैकेज नामकरण दिशानिर्देश विशेष रूप से आपको अपने टीएलडी के बाद अपने पैकेजों का नाम देने के लिए कहते हैं। तो एसओ क्लास जो टिप्पणियों को पार्स करने के लिए ज़िम्मेदार है, उसका नाम com.stackoverflow.commenting.CommentHTMLParser जैसा होगा। –
मैंने पढ़ा है कि 9 0 के उत्तरार्ध में जब वे पहली बार जावा के साथ आए थे तो उनकी गाइडलाइन में। मुझे लगता है कि उनकी दृष्टि यह थी कि वेब संकुल से भरा होगा जो लोग साझा कर सकते हैं (या खरीद सकते हैं), और इस तरह कुछ इस तरह की आवश्यकता होगी। मैं इन दिनों जावा लड़का नहीं हूं, लेकिन यह बिल्कुल इस तरह से काम नहीं करता है, है ना? –
जावा के नामस्थान दिशानिर्देश वे हैं जिस तरह से वे हैं क्योंकि इस तरह वैश्विक स्तर पर अद्वितीय नामस्थानों के लिए एक आसान तरीका है। पैकेजों का बिल्कुल "वेब-पूर्ण" नहीं है लेकिन निश्चित रूप से बहुत सारे संगठन हैं जो जावा पुस्तकालयों को छोड़ते हैं, और बड़े संगठनों से छोटी दुकानों तक एकल देवताओं तक वे सभी जानते हैं कि यह सुनिश्चित करने के लिए कि उनके पैकेज के साथ टकराव नहीं होता है एक और नामस्थान। –
इन नामस्थानों में कौन सी भाषाएं या वातावरण हैं? क्या XYZ आसानी से बिना किसी (कई) झूठी सकारात्मकताओं के लिए खोजा गया है? क्या आपका कोड सभी आंतरिक है या इससे अन्य लोगों को प्रभावित होगा? आप इस पर कितना काम करना चाहते हैं? –
आप पता है कि यह एक अच्छा सवाल है, और एस/ओ "सदस्यों के लिए ब्याज है।" लेकिन - यह प्रोग्रामिंग से संबंधित नहीं है। क्यों कुछ लोग यहां इस तरह के करीबी प्रश्न हैं? मैं 1) निश्चित रूप से मानसिकता को समझने की कोशिश कर रहा हूं , ओह, लोग, और 2) समझते हैं कि मैं कैसे अपना अर्ध प्राप्त कर सकता हूं -प्रोग्रामिंग से संबंधित प्रश्न बंद होने के बजाय उत्तर दिया। सोच के लिए भोजन। बुद्धिमान करने के लिए: http://stackoverflow.com/questions/1364304/what-companies-are-using-rowe-in-a-software-development-environemt-closed। कोई मुझे बताता है कि मेरी गलती क्या है। –
@ डॉन: जो आप लिंक करते हैं वह बहस योग्य है। हालांकि, यह भी करीब नहीं है। यह प्रोग्रामिंग के लिए पूरी तरह अद्वितीय है। उनमें पुराने कंपनी के नाम के साथ कुछ अन्य आंतरिक दस्तावेज हो सकते हैं, लेकिन यदि आप केवल कुछ संदर्भों को स्विच करते हैं तो एक फ्लैट दस्तावेज़ के साथ कुछ तोड़ नहीं आता है। –