सह-कार्यकर्ता ने मेरे सभी प्रश्नों का नाम बदल दिया [बंद]


63

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

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

मैं यह जानने की कोशिश कर रहा हूं:

1) क्या मैं ओवररिएक्ट कर रहा हूं?

2) इससे निपटने का सबसे अच्छा तरीका क्या है? मुझे अपने बॉस से इस बात का जिक्र करने से नफरत है, लेकिन कल अपने सहकर्मी के साथ बात करने के बाद, मैं पहले ही बता सकती हूं कि उसे लगता है कि उसने कुछ गलत नहीं किया।


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

30
द्वंद्वयुद्ध में! ...

46
आपके पास एक बैकअप / एसवीएन सही है? उसके बदलावों से पहले, और आराम करें।
जेल्टन

11
अगर किसी ने मेरे कोड का नाम बदल दिया तो मैं शांग त्सुंग की तरह उनमें से जीवन को छीन लूंगा!
ग्लेन फेर्री

24
यदि उसके कोई बच्चे हैं, तो उनका नाम बदलें।
मैट

जवाबों:


81
  1. वास्तव में नहीं - यह एक अविश्वसनीय रूप से अपमानजनक बात है।

  2. आपने उससे बात की है और हमने ऐसा नहीं किया है, लेकिन ऐसा लगता है कि आप अपने अधिकारों के भीतर होंगे एक बैकअप से पिछले नामकरण सम्मेलनों को बहाल करने या यदि वे एक स्रोत नियंत्रण में हैं, तो उन्हें वापस कर दें। यदि आप ऐसा करते हैं, तो अपने बॉस और सहकर्मी को सूचित करें और अपना कारण प्रदान करें (आप अपना काम खुद नहीं कर सकते)।

आखिरी चीज जिसे आप चाहते हैं वह इस पर आगे और पीछे हो सकता है, हालांकि इसे संभालना चाहिए क्योंकि स्थिति योद्धा लगती है, लेकिन इसे कम से कम दस्तावेज में होना चाहिए क्योंकि यह अनादर के पैटर्न का हिस्सा बन जाता है।


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

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

2
उसे समझाएं कि आप किस तरह से कन्वेंशन का नामकरण करते हैं
GerManson

13
सुनिश्चित करें कि आप उसके संपादन अधिकार डेटाबेस पर ले जा रहे हैं, जबकि आप उस पर हैं ...
Ant

1
@Ant: यदि ओपी का उदाहरण पूरी कहानी है, तो मुझे लगता है कि थोड़ा कठोर हो सकता है। यदि इसमें कुछ और है (या उन्हें पहली बार में अधिकार संपादित नहीं करने चाहिए) तो आप सही हो सकते हैं।
बीसीएस

117

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

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

क्या समस्या का नामकरण योजना है या आपको लगता है कि आपको कोई सम्मान नहीं मिला है? यदि ऐसा है तो शायद आप अपने कामकाजी संबंध पर काम कर सकते हैं। अगर आपको लगता है कि यह इसके लायक नहीं है, तो आपको इस बात की परवाह क्यों है कि वह वैसे भी क्या सोचती है? :) एक और विकल्प यह हो सकता है कि वह वास्तव में यह महसूस नहीं करता है कि यह एक बड़ी बात है और यदि आप अच्छी तरह से समझाते हैं कि आपको सामान खोजने में परेशानी हो रही है तो आप इसे वापस बदल सकते हैं।


2
मैं इसे वापस बदलने और उसे ऐसा न करने के लिए कहने जा रहा था, लेकिन आपका जवाब और भी बेहतर है।
माइक डनलैवी

इस पर सुंदर जगह है।
वेन मोलिना

20
और फिर उसे नए बदलाव के लिए कन्वेंशन पर सहमति दें :)

7
@konrad, आप एक महत्वपूर्ण मुद्दे को देख रहे हैं - एक परीक्षक के पास न तो अधिकार है और न ही किसी प्रकार का व्यवसाय है जो इस तरह का संपादन कर रहा है । @anon प्रोग्रामर इंचार्ज हैं, नामकरण परंपराएं ठीक से उनके निर्णय लेने के लिए हैं, और वे एक समिति के वोट के लिए नहीं हैं, अकेले किसी ऐसे व्यक्ति द्वारा परिवर्तन करें, जिसे बाद में कोड को डिबग करना कभी नहीं होगा।
शादुर

36
  1. डेटाबेस डिज़ाइन में अनुमतियाँ (GRANT और REVOKE) शामिल हैं।
  2. परीक्षण में परीक्षण अनुमतियाँ शामिल हैं।
  3. अपेक्षाकृत कम लोगों को डेटाबेस ऑब्जेक्ट का नाम बदलने की अनुमति होनी चाहिए।
  4. आपका सहकर्मी कुछ में से एक नहीं है।

यह बहुत अच्छी बात है। मैं सोच रहा था कि एक परीक्षक को पहली बार में भी इस तक पहुंच क्यों होगी।
जस्टिन ओम्स

क्योंकि यह एक्सेस है। एक्सेस में कोई GRANT और REVOKE नहीं है। इसकी कोई अनुमति नहीं हैं।
कबि

7
वास्तव में प्रवेश की अनुमति है, लेकिन मुझे अभी तक किसी ऐसे व्यक्ति से मिलना है जो समझता है कि वे कैसे उपयोग किए जाने वाले हैं (अकेले उन्हें लागू करें)
Mchl

1
इसमें कोई संदेह नहीं है, यह वही कंपनी शायद स्रोत नियंत्रण प्रणाली भी नहीं है, अकेले एक योग्य डीबीए को एक्सेस करने के लिए बंद कर दिया है। btw आपको यह देखना चाहिए कि यह बहुत मुश्किल नहीं है।
बेनामी टाइप

21

"नया नामकरण सम्मेलन बिल्कुल भी समझ में नहीं आता है" ऐसा लगता है कि इनमें से एक मामला हो सकता है:

  1. उसने कंपनी के कुछ मानदंडों को लागू किया। इनका उपयोग अक्सर यह सुनिश्चित करने के लिए किया जाता है कि कोड कम से कम सुसंगत हो, और सर्वोत्तम मामलों में कोड को आसानी से खोजने के लिए छोटी कस्टम स्क्रिप्ट जैसी परिधीय चीजों की मदद कर सकते हैं। इस मामले में, आपको आदर्श को समझने की आवश्यकता है और यह आपकी स्थिति में "समझ में नहीं आता" क्यों है। यदि आप अभी भी सोचते हैं कि सभी डेवलपर्स के लिए इसे छोड़ना बेहतर है जैसा कि यह था, तो उन्हें समझाएं कि वास्तव में आपका तरीका श्रेष्ठ क्यों है, और पूछें कि क्या आप मानदंड बदल सकते हैं (शायद ठीक है यदि वे सहमत हैं कि यह श्रेष्ठ है) या अपने मामले में इसे त्याग दें (दीर्घकालिक में असंभाव्य और गन्दा)।
  2. उसने मौके पर ही अपने मानक का आविष्कार किया और इसे लागू किया। यह अधिक संभावना है अगर वह नया है, और उसे अपने तर्क की व्याख्या करनी चाहिए। आप कुछ सीख सकते हैं, और / या वह कुछ सीख सकती है यदि आप अपने तर्क को स्पष्ट करते हैं।

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


2
+1 अच्छी बात। हर कोई उत्तर देने वाले प्रश्नकर्ता को मान्य नामकरण स्कीमा रखने के लिए मानता है। क्या होगा अगर वह वास्तव में कंपनियों "सूचना hoarder" है। शायद इसके परीक्षक जो वास्तव में कंपनी में हर किसी के लिए (और किसी भी नए) प्रश्नों को ढूंढना आसान बना रहे हैं।
बेनामी टाइप

अच्छे अंक। यदि नामकरण योजना अच्छी है, तो दोनों पक्ष इसका उपयोग करने में सक्षम होंगे (एक बार जब वे इसकी अभ्यस्त हो जाएंगे) तो कोई बात नहीं जो इसके साथ आए।
BCS

2
@ बीकेएस उस मामले में भी, ऐसा करने का उचित तरीका प्रोग्रामर को सूचित करना होगा और उसे अगले दिन काम करने के लिए आने का इंतजार करने के बजाए खुद को नामकरण सम्मेलन बदलने के लिए कहेंगे। और उसकी / उसके पूरे ढांचे की खोज की।
शादुर

16

मैंने ज़िम्मेदार व्यक्ति के साथ बात की, और उसने पूरी बात को गलत बताया।


फिर मैं आपको बताऊंगा,

परिवर्तन वापस करें।

इस युद्ध को जीतो। आपके प्रबंधक को आपको वापस करना चाहिए और अपने अधिकार को मजबूत करना चाहिए।


माना। उसके साथ पहले जाँच लें कि कोई अच्छा कारण नहीं है कि नए नाम बेहतर क्यों हैं। यदि नहीं तो इसे वापस बदल दें।
रिचर्ड

11
जब "युद्ध इस युद्ध" कभी अच्छी सलाह है?
सेवर्रे रबेलियर 12

3
@Sverre Rabbelier: ... जब एक n00b उप-डोमेन सॉफ़्टवेयर प्रथाओं को स्थापित करने का प्रयास करता है। ओपी ने उसके साथ तर्क करने की कोशिश की। अब समस्या को ठीक करने का समय आ गया है। N00b के साथ विज्ञापन nauseum के बारे में कुछ स्पष्ट तो अनुत्पादक और व्यर्थ गति है।
जिम जी।

4
@ जीम शायद ओपी नयाब है?
जो फिलिप्स

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

10

1) नहीं, आप प्रतिक्रिया नहीं कर रहे हैं। किसी ने आपको बताए बिना अपना काम बदल दिया और जब आपने उनसे पूछा कि आपने ऐसा क्यों किया। यह बहुत ही अपमानजनक और असभ्य है।

2) क्या आप आधिकारिक डीबीए हैं, या कम से कम वह व्यक्ति जिसे डीबी का रक्षक बनाया गया है? यदि हां, तो नामों को वापस बदलें और चीजों को कैसे करें, इसके लिए एक कन्वेंशन दस्तावेज़ लिखें। इसके अलावा, 'यूजर्स गाइड' स्टाइल डॉक्यूमेंट लिखें, ताकि अगर किसी को डीबी में जाना हो और वह कुछ खोज सके।

मैं एक उपयोगी नोट के साथ किसी भी उंगलियों को इंगित नहीं करते हुए, समूह के लिए इसे बाहर भेजूंगा, जो आपको संरचना के कुछ बारीकियों के माध्यम से लोगों को बैठाने और चलने में खुशी होगी।

यदि नहीं, तो एक टीम के रूप में सम्मेलनों के साथ आएं और एक टीम के रूप में उनका अनुसरण करें।

एक साइड नोट पर, किसी ऐसे व्यक्ति के लिए जिसे 300+ प्रश्नों के नाम बदलने के लिए कुछ परीक्षण करना था, बहुत ही बचकाना लगता है। उसने ऐसा करने में कितना समय बर्बाद किया, और केवल इतना है कि उसे सामान मिल सकता है? किसी के पास जाने और कुछ मदद मांगने के बजाय, उसने अपना समय, अपना समय और कंपनी का समय बर्बाद किया। कोड का उल्लेख करने के लिए नहीं जब वह ऐसा करता था तो टूट जाता था, इस प्रकार टीम के दूसरे सदस्य का समय भी बर्बाद होता था।

अगर मैं तुम होते, मैं तब तक प्रतीक्षा करता, जब तक तुम थोड़ा शांत नहीं हो जाते, कोशिश करो और उससे फिर बात करो। अगर वह काम नहीं करता है तो इसे बॉस के साथ करें। उस तरह की चरवाहा मानसिकता पूरी टीम को आखिरकार बांध देगी।


8

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


5

ऐसा लगता नहीं है कि कहीं और छुआ जा सकता है, लेकिन किसी भी स्रोत (जैसे, एक क्वेरी) को सार्वजनिक स्थान पर रखा जाना एक संस्करण नियंत्रण प्रणाली के तहत होना चाहिए।

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


2

मुंह में एक उपहार घोड़ा मत देखो।

सबसे पहले, सामूहिक कोड स्वामित्व - उन्हें 'आपका' नहीं होना चाहिए।

दूसरे, अगर उन्होंने उनका नाम बदल दिया है, तो नई नामकरण योजना के आसपास तर्क पूछें। या तो वे प्रश्नों का उपयोग कर रहे हैं - किस मामले में यह उनके कॉल की तरह है; या यह उनमें से एक पहला कदम है जो आपको इन्हें बनाए रखने में कुछ मदद देगा।

अगर हर कोई सोचता है कि वे 'आपके' हैं, तो आप उनसे कभी छुटकारा नहीं लेंगे, और कुछ नया करने के लिए आगे बढ़ेंगे


2

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

किसी भी मामले में, मुझे लगता है कि "युद्ध" को छेड़ना जवाब नहीं है। यदि आप जीतते हैं, तो भी आप हार जाते हैं।


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

1

यह भयावह व्यवहार है। ऐसा लगता है कि उसे कोई पछतावा नहीं है, इसलिए इसे अपने बॉस के पास ले जाएं और जब तक उसे आश्वस्त नहीं किया जा सकता है, तब तक उसकी पहुंच रद्द करने के लिए एक मामला बनाएं।

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

यह अशिष्टता से परे है। मैं उग्र हो जाऊंगा।


1

यादृच्छिक लोगों को उन्हें बदलने से रोकने के लिए अनुमतियाँ सेट करने के अलावा, आपको यह भी समझाना चाहिए कि कार्यक्षमता का परीक्षण करना उसका काम है, यदि आप यादृच्छिक लोगों को कोड में परिवर्तन कर रहे हैं तो आप विश्वसनीयता की कोई गारंटी नहीं दे सकते।


1

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

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

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

यहाँ मुझे लगता है कि कोई भी अलगाव में काम नहीं करता है और एक-दूसरे के पैर की उंगलियों से बचने से बचने का सबसे अच्छा तरीका है कि आम जमीनी नियमों पर बातचीत और सहमति हो।


0

मैं उसी तरह से जवाब दूंगा - सब कुछ वापस करने के आपके निर्णय को गलत ठहराते हुए। बस उसके परिवर्तनों को वापस लें और अपने सहकर्मियों को वास्तव में संक्षिप्त ईमेल लिखें:

"अभी के लिए rXXXX में बदला गया परिवर्तन, क्योंकि यह समझ में नहीं आ रहा है कि यह कन्वेंशन नामकरण है। हालांकि कोशिश करने के लिए धन्यवाद। :)"


0

हां आप ओवररिएक्ट कर रहे हैं।

कुछ चीज़ों को संस्करण नियंत्रण कहा जाता है कि अन्य चीज़ों के बीच इसका इस्तेमाल $ # को हराने के लिए नहीं किया जाता है! जब वे आपके सामान में गड़बड़ करते हैं तो सहकर्मियों से $ 7! बस पिछले संस्करण में रोलबैक करें और फ़ाइल को लॉक करें इसलिए उसे क्रोध को संभालने दें। यह आपके लिए यह समझाने का अवसर खोलेगा कि कोड पर आमूल-चूल परिवर्तन करना जिसकी ठोस वजह के बिना किसी और के सामान पर निर्भरता हो और बिना पूछे पहले सिर्फ गलत, अत्यंत अव्यावहारिक और व्यावहारिक रूप से पाप न हो।

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

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

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