खराब प्रैक्टिस - वातावरण सेट करने के लिए स्विच केस

Question

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

बैक-एंड उदाहरण (C #):

public static string getHost(EnvironmentEnum environment){
    var path = String.Empty;
    switch (environment)
    {
        case EnvironmentEnum.dev:
            path = "http://localhost:55793/";
            break;
        case EnvironmentEnum.uat:
            path = "http://dev.yourpath.com/";
            break;
        case EnvironmentEnum.production:
            path = "http://yourpath.com/";
            break;
    }
    return path;
}

फ्रंट-एंड उदाहरण (जावास्क्रिप्ट):

(function () {
    if (window.location.host.indexOf("localhost") !== -1) {
        window.serviceUrl = "http://localhost:57939/";
    }
    else if (window.location.host.indexOf("qa") !== -1) {
        window.serviceUrl = "http://dev.yourpath.com/";
    }
    else {
        window.serviceUrl = "http://yourpath.com/";
    }
})();

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

क्या कोई इसे ऊपर के अभ्यास के पेशेवरों और विपक्षों को समझा सकता है?

Comments

यह रेखा अकेली नहीं है। पथ = " yourpath.com "; कॉन्फ़िगरेशन कोड के लिए बाहरी होना चाहिए।

— पापाराज़ो

शुद्ध कोड समीक्षा के नजरिए से, Dictionaryयह C # में कोडिंग का एक बहुत साफ तरीका है। Ideone.com/45g5xO देखें । या जेएस में एक अच्छी-पुरानी वस्तु का उपयोग करें, देखें jsfiddle.net/1ouhovqq ।

— डैनी बेकेट

यदि आपकी कंपनी का नाम "qa" वाली किसी चीज़ में बदल जाए तो क्या होगा?

— user253751

याद रखें कि यदि आप एक कॉन्फ़िगर फ़ाइल का उपयोग करते हैं, तो इसे स्रोत कोड नियंत्रण में नियंत्रित करने की आवश्यकता होती है .... आपको नई परीक्षण मशीनों को सेट करने के लिए दिन में कई बार कॉन्फ़िगरेशन फ़ाइल को संपादित करना पड़ सकता है। मुझे अभी भी लगता है कि एक कॉन्फ़िगर फ़ाइल सबसे अच्छी है, लेकिन आप पहले detaul config फाइल को देखने से पहले एक फ़ाइल का नाम आधारित पर्यावरण की तलाश कर सकते हैं।

— इयान

मुझे नहीं लगता कि आपको चीजों को खराब करने के बारे में कहना चाहिए, अगर आप यह नहीं कह सकते हैं कि आपको क्यों लगता है कि यह एक बुरा अभ्यास है

— रॉय

Answer 1

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

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

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

हार्ड-कोडेड मूल्य एक समस्या है या नहीं यह इस बात पर निर्भर करता है कि आपकी स्थिति पहले उदाहरण की तरह है या दूसरे उदाहरण की तरह।

Comments

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

— corsiKa

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

— तुलसी कोर्डोवा

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

— केविन कैथार्ट जूल

आपके एप्लिकेशन कोड के साथ मिश्रित पर्यावरण सेटिंग के साथ, आप एक तर्क त्रुटि हैं - या निष्पादन वातावरण में अप्रत्याशित परिवर्तन - उत्पादन से परीक्षण से दूर, या परीक्षण से उत्पादन, या कुछ अन्य अप्रत्याशित और संभवतः विनाशकारी संयोजन। C # में कोड से अलग पर्यावरण-विशिष्ट गुण बनाए रखना आमतौर पर मामूली है। एक अनावश्यक जोखिम क्यों लें?

— जॉन एम गैंट जूल

@ user61852 "मुझे लगता है कि यह कहना गलत नहीं है कि हार्ड-कोडिंग पर्यावरण मूल्य किसी भी प्रकाश के तहत खराब बुरा व्यवहार है।" "हार्ड-कोडिंग पर्यावरण मूल्यों के लिए परेड हमेशा खराब अभ्यास है" यदि यह हमेशा खराब अभ्यास है, तो कम से कम एक समस्या की पहचान करना संभव होना चाहिए जो हार्ड कोडिंग पर्यावरण मूल्यों का कारण होगा।

— एमरी

Answer 2

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

जब आप दूसरा वातावरण जोड़ना चाहते हैं तो क्या होता है? या अपना विकास सर्वर बदलें? या आपको किसी भिन्न स्थान पर विफल होने की आवश्यकता है? आप ऐसा नहीं कर सकते क्योंकि आपका कॉन्फ़िगरेशन सीधे कोड से जुड़ा हुआ है।

कॉन्फ़िगरेशन को कोड से बाहर और पर्यावरण में ही मजबूर किया जाना चाहिए। यह एक बारह-फैक्टर ऐप ( http://12factor.net/config ) का एक सिद्धांत है , लेकिन यह किसी भी एप्लिकेशन के लिए एक अच्छा अभ्यास है। आप पा सकते हैं कि पर्यावरण चर आपकी स्थिति के लिए उपयुक्त नहीं हैं, जिस स्थिति में मैं विन्यास फाइल के डेटाबेस में उस विन्यास को एक साथ देखने का सुझाव दूंगा (लेकिन साथ में चेक नहीं किया गया)।

Comments

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

— मैट्नज़

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

— mgw854

Answer 3

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

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

आपके जावास्क्रिप्ट कोड में ऐसा करने के साथ एक और गंभीर दोष है: आप संभावित हमलावरों के लिए अपनी कंपनी के इंटर्नल को उजागर कर रहे हैं। ज़रूर, आप एक फ़ायरवॉल के पीछे हो सकते हैं, लेकिन आपके पास अभी भी एक असंतुष्ट कर्मचारी या कोई ऐसा व्यक्ति हो सकता है जो वायरस को अंदर आने देता है।

बुरी खबर भालू।

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

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

Answer 4

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

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

Answer 5

यह एक बुरा व्यवहार है ।

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

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

कोई अन्य सर्वर पर परीक्षण को स्थानांतरित कर सकता है। कोई यह भी तय कर सकता है कि उपयोगकर्ता प्रशिक्षण परिवेश, या बिक्री प्रदर्शन के लिए एक वातावरण चाहते हैं। उन्हें प्रशासनिक कॉन्फ़िगरेशन के लिए किसी प्रोग्रामर के पास नहीं जाना चाहिए।

अप्रत्याशित कारणों को संभालने के लिए सॉफ्टवेयर को लचीला और मजबूत होना चाहिए।

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

चीजों को ठीक से कोड करें, जितना कि आप कर सकते हैं। यह बाद में एक समस्या बनने की संभावना कम है।