हमारे पास लगभग 8 वर्षों से एक लंबा जीवित उत्पाद है। समय के साथ, अवधारणाओं और संस्थाओं के नाम बदल जाते हैं। क्या हमें इन नए नामों से मिलान करने के लिए सभी कोड आधार और डेटाबेस तालिकाओं और स्तंभों का नाम बदलने के लिए काम करना चाहिए?
क्या इस पर कोई अध्ययन किया गया है या कुछ सर्वोत्तम प्रथाओं को प्रकाशित किया गया है?
धन्यवाद
जवाबों:
आंतरिक और बाहरी नामों के बीच बेमेल निश्चित रूप से बदबू आ रही है। जैसे रिन्ज़विंड बताते हैं, होमोफ़ोन और समानार्थी शब्द सबसे खराब होते हैं।
आपको जिस वास्तविक प्रश्न का उत्तर देने की आवश्यकता है, वह है: परिवर्तन करने में लागत / लाभ वाला ट्रेडऑफ क्या है?
बदलते समय की लागत नई टीम के सदस्यों के लिए एक सीखने की अवस्था है और भविष्य के कीड़े की संभावना बढ़ जाती है। बदलने की लागत में स्पष्ट समय शामिल है, परियोजना पर पुराने टाइमर के लिए एक नया सीखने की अवस्था, और नए कीड़े की संभावना।
यदि आप नई टीम के सदस्यों की अपेक्षाकृत बड़ी संख्या की उम्मीद कर रहे हैं, तो परिवर्तन करने के लिए समझ बनाने की अधिक संभावना है। यदि आप किसी टर्नओवर की उम्मीद नहीं कर रहे हैं, तो वर्तमान टीम भ्रमित नहीं होती है, और टीम यथास्थिति से संतुष्ट है, तो यह वास्तव में चीजों का नाम बदलने के लिए कोई मतलब नहीं है।
यदि कोड लंबे समय तक रहने की उम्मीद है और इस पर नए डेवलपर्स काम करेंगे, तो मैं बदलाव करूंगा।
किसी नए डेवलपर के लिए किसी प्रोजेक्ट में प्रवेश करने और संस्थाओं के नाम गुमराह करने वाले हैं।
वहाँ भी मान्य तर्क है ... अगर यह नहीं टूटा है, तो इसे ठीक न करें।
आपके दूसरे प्रश्न के संबंध में, मैं किसी भी प्रकाशित अध्ययन या सर्वोत्तम प्रथाओं से अवगत नहीं हूँ। पहले प्रश्न के संबंध में, मैं व्यक्तिगत अनुभव से कुछ समान लंबे समय तक रहने वाले उत्पाद के साथ कुछ टिप्पणियों की पेशकश कर सकता हूं जहां 'आंतरिक' और 'बाहरी' नाम कभी-कभी भिन्न होते हैं।
जिन नामों को मैं वास्तव में ठीक करना चाहूंगा, वे हैं "होमोफोन्स", जहां एक नाम का इस्तेमाल आंतरिक और बाहरी दोनों तरह से अलग-अलग चीजों के लिए किया जाता है । यह वास्तव में भ्रामक हो सकता है, खासकर यदि दो चीजें पूरी तरह से अलग नहीं हैं (जैसे कि संदर्भ में मदद मिलती है)। मेरे व्यक्तिगत अनुभव में इसका एक (अमूर्त) उदाहरण है, जहां आंतरिक रूप से आपके पास कुछ ऐसा है Fooजो कई का संग्रह है FooEntity; बाह्य रूप से, केवल बाद वाला दिखाई देता है और इसे "फू" कहा जाता है। मुझे यह पता लगाने में थोड़ा समय लगा कि जब ग्राहक मैनुअल एकाधिक "फू" की बात कर रहा था , तो वास्तव में इसका मतलब कई FooEntity(एक ही Foo) में था, अगर वह अभी भी आपके लिए कोई मतलब रखता है।
दूसरे, मैं किसी भी "समानार्थक शब्द" को ठीक करना चाहूँगा जहाँ कुछ बाहरी नाम आंतरिक रूप से उपयोग किए गए हैं। चर नामों की तरह, विधि / कार्य नामों के कुछ हिस्सों और इतने पर। ऐसा अक्सर तब होता है जब डेवलपर्स ग्राहक की आवश्यकताओं के विवरण से सीधे कुछ लागू करते हैं और नामों को "अनुवाद" करना भूल जाते हैं। एक बार ऐसा होने पर, 'गलत' नाम भी फैल जाता है, क्योंकि अन्य डेवलपर्स उदाहरण के लिए नए कोड के लिए टेम्पलेट के रूप में उपयोग करने के लिए उस कोड में से कुछ को कॉपी / पेस्ट करते हैं। ये समानार्थी शब्द इतने भ्रामक नहीं हैं, लेकिन वे कष्टप्रद हो सकते हैं क्योंकि यदि आप किसी संदर्भ के लिए कोड खोज रहे हैं तो आपको यह Barध्यान रखना होगा कि कुछ भाग इसका उल्लेख कर सकते हैंQux, इसलिए आपको दो बार खोजना होगा। (यह स्थैतिक रूप से टाइप की गई भाषाओं की तुलना में गतिशील रूप से टाइप की जाने वाली भाषाओं में बदतर हो सकता है, क्योंकि आपको चर / कार्यों के नाम के कुछ हिस्सों को खोजना होगा ... / बल्कि उनके प्रकार के नाम पर।) "पर्यायवाची शब्द के रूप में। ", जहां एक आंतरिक नाम का बाहरी रूप से उपयोग किया गया है: यह अक्सर ग्राहक के सहायक कर्मचारियों और इतने पर नहीं होता है, क्योंकि आमतौर पर आंतरिक नामों के बारे में कम जानते हैं, हालांकि मुझे लगता है कि ऐसा होने पर ग्राहकों के लिए यह भ्रामक है।
यदि आप कम से कम उपरोक्त दो स्थितियों को टाल सकते हैं या ठीक कर सकते हैं, तो मुझे यकीन नहीं है कि आपको बाहरी लोगों के समान ही सभी आंतरिक नामों को बनाने के लिए जाना चाहिए। बाहरी नाम पहली बार में आंतरिक से अलग किए जाने के कारण आंतरिक नाम भी नहीं बदले जाने का शायद एक अच्छा कारण है। मेरे व्यक्तिगत अनुभव में, वह अच्छा कारण उत्पाद के पुराने संस्करणों का समर्थन करने की आवश्यकता है; यदि कोड को बहुत अधिक बदलना पड़ता है, तो पहले-से-नामों-क्लीनअप संस्करण से बग फिक्स को मर्ज करना मुश्किल हो सकता है।
यह एक काफी आम समस्या है। उत्पाद नाम (जो उस बिंदु पर तय नहीं किया जा सकता है) के बजाय उपयोग कोड नामों पर काम किया है, और उपयोगकर्ता के लिए प्रदर्शित की तुलना में कोड में बेतहाशा अलग शब्दावली का उपयोग करें। जब तक आप कोड के एक बड़े पैमाने पर पुन: उपयोग कर रहे हैं या यदि कुछ विशिष्ट समस्याएँ हैं, तो मैं संभवतः चीजों को छोड़ दूंगा। सेब की गाड़ी को परेशान करने में कोई फायदा नहीं। इसके अलावा, अब से 5 साल बाद कौन ज्यादा बदलाव नहीं करेगा? और फिर आपको नाम बदलने के माध्यम से फिर से जाना होगा। और मत भूलो, यह आपके द्वारा प्रकाशित (प्रकाशित एपीआई) के किसी भी अलग कोड प्रलेखन को भी प्रभावित कर सकता है, जो कि एक विशेष रूप से महंगा मुद्दा हो सकता है यदि इसकी मुद्रित (हार्ड कॉपी)।
मुझे लगता है कि अक्सर "विपणन" संस्थाएं आंतरिक संस्थाओं के साथ बिल्कुल मेल नहीं खाती हैं। ऐसे मामलों में, एक इकाई को अमूर्तता के एक अलग स्तर पर पेश करना अधिक समझ में आता है, जो शब्दावली के अंतर को एक म्यूट बिंदु बनाता है।
उदाहरण के लिए, हमारे पास एक मॉडल है जो एक पदानुक्रम का प्रतिनिधित्व करता है। पदानुक्रम में प्रत्येक स्तर पर इससे जुड़ा एक शब्द होता है, जिसके आधार पर पदानुक्रम का उपयोग वास्तविक दुनिया के रिश्तों को मॉडल बनाने के लिए किया जाता है, लेकिन आंतरिक रूप से पदानुक्रम के एक स्तर से दूसरे स्तर तक व्यवहार में कोई अंतर नहीं होता है। शब्दावली अनिवार्य रूप से पदानुक्रम में उस स्तर के लिए सिर्फ एक नाम है, इसलिए पेड़ में एक विशेष नोड के लिए नाम केवल यह बताता है कि नोड क्या है; यह किसी विशेष व्यवहार को निर्धारित नहीं करता है।
इसके अलावा, पेड़ बहु-जड़ है, इसलिए माता-पिता के बिना कई नोड हैं। भले ही वैचारिक रूप से एक जड़ मौजूद है (यह अनिवार्य रूप से ब्रह्मांड का प्रतिनिधित्व करेगा), और मॉडल में इसे शामिल करने से कई ऑपरेशन बहुत सरल हो जाएंगे, इसके लिए कोई "विपणन शब्द" नहीं है।
बेशक, हमारे सिस्टम में विभिन्न घटक विभिन्न शब्दावली का उपयोग करते हैं। वे अलग-अलग समय पर अलग-अलग टीमों द्वारा विकसित किए गए थे, और उन सभी पर हमारा नियंत्रण नहीं है। दरअसल, किसी बिंदु पर, किसी ने एक घटक में एक स्तर जोड़ा या हटा दिया, और इसलिए अन्य स्तरों को एक दूसरे के सापेक्ष स्थानांतरित कर दिया जाता है। समान तीन स्तरों को एक घटक में ए, बी और सी द्वारा दर्शाया जाता है, लेकिन दूसरे में बी, सी और डी के रूप में।
अमूर्तता में कदम बढ़ाते हुए और बस एक "नोड" के रूप में सब कुछ मॉडलिंग करना या समान रूप से सामान्य रूप से इस प्रकार के मॉडल के साथ तर्क करना बहुत आसान होता है। प्रत्येक नोड जानता है कि उसका "मार्केटिंग टर्म" क्या है, और एक प्रकार जो किसी विशेष मार्केटिंग शब्द का प्रतिनिधित्व करता है, यह जान सकता है कि प्रत्येक संदर्भ में उस शब्द का क्या अर्थ है।