अंत उपयोगकर्ताओं के नामकरण में परिवर्तन करने के लिए हमें कितनी बार कोड और डेटा का नाम बदलना चाहिए?


50

बहुत समय पहले हमने एक फीचर जोड़ा था जहाँ हमारे उपयोगकर्ता वर्कफ़्लो कतार में जोड़ने के बाद एक छवि को "स्वीकार" कर सकते थे। पता चला, हमने गलत शब्द का उपयोग किया, और उपयोगकर्ता वास्तव में छवि को "स्वीकृत" करते हैं।

हमारे इंटरफ़ेस पर स्वीकृति को बदलना आसान है, बस एक शब्द को बदलें। लेकिन हमने सीएसएस वर्ग नाम से डेटाबेस मानों तक "स्वीकार" शब्द के साथ सभी परतों को क्रमादेशित किया।

  • CSS वर्ग जो बटन को हरा करता है: ".accepted";
  • वह मॉडल विधि जो DOM नोड पर क्लास की विशेषता को सत्यापित और बांधती है: "isAccepted";
  • जावास्क्रिप्ट स्थिति विशेषता: "बिना पढ़े", "स्वीकृत" और "प्रकाशित" के साथ सरणी;
  • मैसकल स्थिति स्तंभ: ENUM के साथ "बिना पढ़े", "स्वीकृत" और "प्रकाशित";
  • परीक्षण के नाम;

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

यह विशिष्ट मामला सरल है, लेकिन मैंने अपने करियर के दौरान समान, फिर भी अधिक जटिल मामलों का सामना किया है। जब एक फ़ाइल का नाम भी बदल दिया जाता है और तैनाती दर्जनों सर्वरों पर होती है, या जब प्रॉक्सी कैशिंग, मेम्केड और mysql शामिल होते हैं।

इंटरफ़ेस को छोड़कर हर दूसरी परत पर "स्वीकृत" छोड़ना एक बुरा विचार है, क्योंकि टीम में शामिल होने वाले नए प्रोग्रामर इस निर्णय के लिए ऐतिहासिक कारणों को नहीं सीख सकते हैं, और स्वीकार करते समय -> स्वीकृत अर्थ के संदर्भ में करीबी शब्द हैं, अगर यह "प्रबंधकीय अगली स्थिति की बैठक के लिए कतारबद्ध" का नाम बदल दिया गया था, यह निश्चित रूप से कोई मतलब नहीं होगा। और यह महसूस होता है कि अगर हम यहां और वहां समझौता करते हैं, तो कुछ पुनरावृत्तियों में उपयोगकर्ता इंटरफ़ेस अवधारणाओं में सिस्टम इंटर्नल्स के लिए कोई बीयरिंग नहीं होगा, और मैं निश्चित रूप से ऐसी प्रणाली पर काम नहीं करना चाहता हूं जहां आधे उत्पादन का इसके सराय से कोई संबंध नहीं है।

इसलिए, क्या जरूरत पड़ने पर आप हमेशा अपना नाम बदल लेते हैं? यदि आपके साथ ऐसा हुआ है, और आपने फैसला किया कि व्यापार बंद होने लायक नहीं था, तो क्या यह आपको काटने के लिए वापस आया था? क्या इस समस्या से बचने के लिए कोड टिप्पणी या डेवलपर प्रलेखन पर्याप्त है?


6
प्रोग्रामिंग में कई चीजों की तरह, यह एक व्यापार है। आप या तो नाम बदलने के सापेक्ष फायदे और नुकसान के आधार पर निर्णय लेते हैं, या इसे वैसे ही छोड़ देते हैं।
रॉबर्ट हार्वे

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

मुझे केवल db में डेटा माइग्रेट करने के बारे में सोचना होगा। यदि यह 1000 रिकॉर्ड है, तो इसमें कोई संदेह नहीं है। इसे माइग्रेट करें! अगर यह 1000000 है शायद मैं सोचता हूँ। लेकिन फिर भी सोचते हैं कि 1 मिलिट्री सिंपल अपडेट बहुत जल्दी मिलेगा। आपके द्वारा उल्लेखित अन्य सभी चीजें मेरे लिए नया नाम हैं।
पायोत्र पेरक

इसके लिए डेटा को माइग्रेट करने की आवश्यकता नहीं होनी चाहिए, इसे MySQL से आईडी (या
एनम के

जवाबों:


31

मेरे लिए, प्रश्न में आइटम से संबंधित सभी चीजों को बदलना निश्चित रूप से सबसे अच्छा है।

यह कोड गिरावट का एक रूप है, और जबकि 1 आइटम नहीं बदला जा सकता है यह एक बड़ी बात नहीं है, यह कोड आधार के लिए टोन सेट करता है।

यह भविष्य में भ्रम की स्थिति पैदा कर सकता है और नए देवों के लिए कोड आधार / डोमेन को समझना कठिन बना सकता है।


8
+1। केवल एक चीज जिसे मैं जोड़ूंगा (और दूसरे उत्तर में जोड़ा गया है) शब्द है "तकनीकी ऋण।" आप यह कहने में सही हैं कि यह कोड गिरावट है। इस गिरावट की लागत, हालांकि 1-ऑफ़ नहीं है। इसके बजाय, यह समय के साथ अधिक से अधिक कठिन कोड के साथ काम करेगा।
मेटाफ़ाइट

14

प्रश्न सामग्री और टैग से मैं मान सकता हूँ कि आप सर्वव्यापी भाषा का उपयोग कर रहे हैं।

मेरे अनुभव में उल महान है, लेकिन जैसा कि आपने उल्लेख किया है, भाषा के विकसित होते ही अतिरिक्त रखरखाव कार्यों को जन्म दे सकता है। यह, अपने आप में, एक बुरी बात नहीं है। ज़रूर, यह असुविधाजनक है, लेकिन यह भी अपेक्षित है।

मैंने आमतौर पर जो किया है (और देखा गया है) या तो है:

  • 1-शॉट अपफ्रंट रीफैक्टरिंग: अपडेट की गई भाषा को अपनाने के लिए एप्लिकेशन की सभी परतों को रिफलेक्टर करें; या
  • लॉग तकनीकी ऋण: आप उपयोगकर्ता-सामना करने वाले कोड को तुरंत बदल सकते हैं, और फिर अपडेट की गई भाषा के अनुरूप शेष एप्लिकेशन परतों को लाने के लिए तकनीकी ऋण कार्यों को लॉग इन कर सकते हैं। यह आमतौर पर मुट्ठी भर उबाऊ (लेकिन प्रबंधनीय) कार्यों में परिणत होता है। (शाम 5 बजे के लिए बिल्कुल सही!)

मुझे लगता है कि मुख्य बात यह है कि आप जो वर्णन कर रहे हैं वह तकनीकी ऋण है और इसे इस तरह से मान्यता दी जानी चाहिए।

मेरे पास ऐसे प्रबंधक हैं जिन्होंने तर्क दिया है कि हमें ऐसे तुच्छ कार्यों पर समय बर्बाद नहीं करना चाहिए जो किसी भी दृश्य कार्यक्षमता को नहीं जोड़ते हैं। यह तब होता है जब ऋण सादृश्य वास्तव में काम आता है। यह इसे उबालता है:

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


6

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

उस जगह के साथ, बस अपने कोड में उन शब्दों का उपयोग करें जो सबसे व्यापक रूप से समझे जाते हैं। डोमेन से नाम चुनें क्योंकि डेवलपर्स इसे जानते हैं और उम्मीद कर सकते हैं।


2
मुझे लगता है कि ओपी एक अलग समस्या के बारे में बात कर रहे हैं। उनके द्वारा बताई गई बाधाएं एक सर्वव्यापी भाषा ( c2.com/cgi/wiki?UbiquitousLanguage ) का उपयोग करने से उपजी प्रतीत होती हैं । यूएल का उपयोग करते समय आप वास्तव में अपने कोड को यूआई के समान भाषा (संज्ञा, क्रिया) का उपयोग करना चाहते हैं।
मेटाफाइट

3
@ मीटाफाइट यह वास्तव में दर्शन पर निर्भर करता है। कोड के विचार को संचार के रूप में मान लीजिए, आप कुछ ऐसा लिख ​​रहे हैं जो सिस्टम और अन्य डेवलपर्स को बताता है कि आप क्या करना चाहते हैं। यदि क्लाइंट कोड का उपयोग नहीं करने जा रहा है, तो मैं कोड का उपयोग कर भाषा को लिखने का प्रस्ताव कर रहा हूं जो डेवलपर्स के लिए सबसे अधिक सहज है, और फिर उपयोगकर्ताओं के लिए यूआई का अनुवाद करें। दो अलग-अलग ऑडियंस हैं। यदि आपका क्लाइंट स्पैनिश बोलता है, और आप अंग्रेजी बोलते हैं, तो क्या आपके चर स्पैनिश या अंग्रेजी में लिखे जाएंगे? इसलिए मैं दोनों दर्शकों की सेवा करने के तरीके के रूप में l10n का प्रस्ताव करता हूं।
क्रिस

2
L10n के लिए एक और मामला है जब विपणन अपनी शर्तों का आविष्कार करने का फैसला करता है।
बार्ट वैन इनगेन शानौ

@BartvanIngenSchenau hrm, यह कुछ ऐसा है जिसे मैंने कभी खुद से नहीं किया, लेकिन स्पष्ट रूप से एक संभावना है। इस मामले में मैं देख सकता हूं कि जब टीम और डोमेन एक्सपर्ट्स मार्केटेबल भाषा से भिन्न भाषा का उपयोग करते हैं तो l10n कैसे उपयोगी हो सकता है। बहुत ही रोचक।
मेटाफ़ाइट

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

6

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

स्रोत में उपयोगकर्ता के नामकरण को ट्रैक करना एक निवेश है क्योंकि कई घटक प्रकार हैं जहां यह प्रकट होता है और इन सभी घटकों पर एक साथ काम करने के लिए कोई जादू की छड़ी नहीं है। शायद इस तरह के जादू की छड़ी विकसित करना, घटक के बाद घटक, एक दिलचस्प निवेश है जिसे आप परियोजना के जीवनकाल में पतला कर सकते हैं।

मैंने 30 साल पुराने कोडबेस पर काम किया, जहां एंड-यूज़र नामकरण और आंतरिक नामकरण के बीच का बहाव विशेष रूप से बड़ा हुआ। यहां इस स्थिति की कुछ कमियां हैं, जो सभी के हर काम में सुधार लाती हैं:

  1. पर्याप्त नीति की अनुपस्थिति में, नया विकास वर्तमान एंड-यूज़र नामकरण का उपयोग करता है। इस प्रकार, एक ही अवधारणा के विभिन्न घटकों में दो या अधिक नाम हो सकते हैं। चूंकि घटक एक साथ बातचीत करते हैं, इसलिए कई समान नामों में यह कोड के कुछ स्थानीय भागों में simulatenously मौजूद है।

  2. जब हॉटलाइन / हेल्प डेस्क को कॉल किया जाता है, तो वे एंड-यूज़र नामकरण का उपयोग करके एक उपयोगकर्ता कहानी लिखते हैं। समस्या को ठीक करने के प्रभारी डेवलपर को स्रोत नामकरण से मेल करने के लिए अंतिम-उपयोगकर्ता नामकरण का अनुवाद करना चाहिए। बेशक यह संग्रहीत नहीं है, और निश्चित रूप से यह एक गड़बड़ है। (देखें 1.)

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

  4. पर्याप्त नीति के अभाव में, अप्रचलित नामकरण का उपयोग करने वाले स्रोत का रखरखाव समय-समय पर इस अप्रचलित नामावली को फिर से उपयोगकर्ताओं के सामने रखता है। यह खराब छाप पैदा करता है और ओवरहेड का कारण बनता है।

मैंने पहले से ही दो दिनों के लिए बहुत जगह पर नज़र रखी, जहाँ कुछ डेटा को डेटाबेस से पढ़ा जाता है और इस कोडबेस के कुछ घटक में इंजेक्ट किया जाता है। क्योंकि मैं या कोई भी कंपनी जिस पर मैंने काम किया था, वह इस स्थान पर जाने वाले नाम का पता लगाने में सक्षम था, जिसे मैंने खारिज कर दिया और उस समस्या का एक और समाधान खोजने का फैसला किया।

[1] दो दिन से अधिक रखरखाव के बिना कुछ भी खर्च किए बिना (कोई ज्ञान, कोई फिक्स, कुछ भी नहीं) शायद उतना ही बुरा है जितना कि यह प्राप्त कर सकता है, उपयोगकर्ता-नामकरण और स्रोत के बीच की विसंगतियों के बीच विसंगतियों को बनाए रखने में कई नियमित कार्यों के लिए ओवरहेड जोड़ते हैं एक सॉफ्टवेयर।

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

[१] एक से अधिक डेवलपर शामिल होने के कारण।


0

मैं हमेशा कोड और डेटा का नाम नहीं लेता क्योंकि कुछ पैकेज ग्राहकों के बीच साझा किए जाते हैं। वे मूल रूप से एक ही चीज़ का उपयोग कर रहे हैं लेकिन इसे अलग तरह से कहते हैं। उदाहरण, एक CMS में, एक ग्राहक अपने ग्राहक को "ग्राहक" कहता है और दूसरा "ग्राहक" का उपयोग करता है। इसलिए हमने ग्राहक को एक क्लाइंट के लिए सतह पर ग्राहक के साथ बदल दिया, लेकिन सीएमएस हमेशा एक ग्राहक प्रबंधन प्रणाली होगी।

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

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

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