খারাপ অনুশীলন - পরিবেশ নির্ধারণের ক্ষেত্রে স্যুইচ কেস

Question

আমি গত তিন বছরে বিকাশকারী হিসাবে কাজ করেছি, আমি অনেকগুলি উদাহরণ দেখেছি যেখানে লোকেরা একটি URL- এর জন্য পথ (ব্যাক-এন্ড এবং ফ্রন্ট-এন্ড উভয়) সেট করতে একটি সুইচ স্টেটমেন্ট ব্যবহার করে। নীচে এর উদাহরণ দেওয়া হল:

পিছনের শেষ উদাহরণ (সি #):

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এটিকে সি # তে কোড করার একটি অনেক পরিষ্কার উপায়। আইডোন / 45455xO দেখুন । অথবা জেএসে একটি ভাল-পুরানো অবজেক্ট ব্যবহার করুন, jsfiddle.net/1ouhovqq দেখুন ।

— ড্যানি বেকেট

আপনার সংস্থার নাম "কিউ" রয়েছে এমন কিছুতে পরিবর্তন হলে কী হবে?

— ব্যবহারকারী 253751

মনে রাখবেন যে আপনি যদি কোনও কনফিগার ফাইল ব্যবহার করেন তবে এটি উত্স কোড নিয়ন্ত্রণে নিয়ন্ত্রণ করা দরকার .... যে কোনও নতুন দিন আপনি যখন নতুন পরীক্ষা মেশিন সেটআপ করেন তখন আপনাকে কনফিগার ফাইলটি দিনে অনেকবার সম্পাদনা করতে হতে পারে। আমি এখনও মনে করি একটি কনফিগার ফাইল সবচেয়ে ভাল তবে আপনি ডিটাউল কনফিগারেশন ফাইলটি দেখার আগে প্রথমে পরিবেশ ভিত্তিক একটি ফাইল অনুসন্ধান করতে পারেন।

— আয়ান

আমার মনে হয় না যে বিষয়গুলিকে খারাপ অভ্যাস বলার জন্য আপনার কাছাকাছি যাওয়া উচিত, যদি আপনি কেন এটি একটি খারাপ অভ্যাস বলে মনে করেন না

— রায়

Answer 1

আপনার পক্ষে কাজ করে এবং বজায় রাখা সহজ কোডটি সংজ্ঞা দ্বারা "ভাল"। আপনার কোডটিতে সমস্যা কী তা যদি সেই ব্যক্তিটি উল্লেখ করতে না পারেন তবে "ভাল অনুশীলন" সম্পর্কে কারও ধারণার প্রতিপালনের জন্য আপনার কখনই জিনিসগুলি পরিবর্তন করা উচিত নয়।

এই ক্ষেত্রে, সর্বাধিক সুস্পষ্ট সমস্যাটি হ'ল সংস্থানগুলি আপনার অ্যাপ্লিকেশনটিতে হার্ড-কোডড হয় - এমনকি যদি তারা গতিশীলভাবে নির্বাচিত হয় তবে তারা এখনও শক্ত কোডড। এর অর্থ হ'ল আপনি আপনার অ্যাপ্লিকেশনটি পুনরায় সংশোধন / পুনরায় প্রচার না করে এই সংস্থানগুলি পরিবর্তন করতে পারবেন না। একটি বাহ্যিক কনফিগারেশন ফাইলের সাহায্যে আপনাকে কেবলমাত্র সেই ফাইলটি পরিবর্তন করতে হবে এবং আপনার অ্যাপ্লিকেশনটি পুনরায় চালু করতে / পুনরায় লোড করতে হবে।

সমস্যা কিনা বা না তা নির্ভর করে আপনি এটি দিয়ে কী করেন। যে কোনও জাভাস্ক্রিপ্ট ফ্রেমওয়ার্কে যে কোনওভাবেই প্রতিটি অনুরোধের সাথে স্বয়ংক্রিয়ভাবে পুনরায় বিতরণ করা হয়, এটি কোনও সমস্যা নয় - পরিবর্তিত মান প্রতিটি ব্যবহারকারীর পরের বার তারা অ্যাপ্লিকেশনটি ব্যবহার করার সময় প্রচার করবে। অ্যাক্সেসযোগ্য স্থানে একটি সংকলিত ভাষায় অন-প্রাঙ্গনে স্থাপনার সাথে এটি সত্যই একটি খুব বড় সমস্যা। অ্যাপ্লিকেশনটি পুনরায় ইনস্টল করতে দীর্ঘ সময় নিতে পারে, প্রচুর অর্থ ব্যয় করতে পারে বা প্রাপ্যতা রক্ষার জন্য রাতে কাজ করতে হবে।

আপনার হার্ড-কোডেড মানগুলি সমস্যা কিনা তা নির্ভর করে আপনার পরিস্থিতি প্রথম উদাহরণের মতো বা দ্বিতীয় উদাহরণের মতো আরও।

Comments

আমি আপনার প্রথম অনুচ্ছেদ পছন্দ। অবশ্যই, আপনি সমস্যাগুলি কী তা নির্দেশ করে ... এর সাথে এটি অনুসরণ করেন ... তবে "এটি খারাপ কারণ ব্লগ এক্সওয়াইজেড তাই বলেছে" এই ধারণাটি আসলে এটি প্রতিরোধ করার চেয়ে আরও খারাপ কোডের কারণ।

— কর্সিকা

নবজাতকদের বেঁচে থাকার জন্য সময়-পরীক্ষিত নীতিগুলি দেওয়া উচিত, কেবল "যদি এটি আপনার পক্ষে কাজ করে তবে এটি ঠিক আছে" আপেক্ষিকতা। আমি অনুমান করি যে হার্ড-কোডিং পরিবেশের মানগুলি যে কোনও আলোকে নিখরচায় খারাপ অভ্যাস বলে আমি ভুল হই না।

— তুলাইনস কর্ডোভা

@ jpmc26: আপনি অবশ্যই ধরে নিচ্ছেন যে সার্ভার সাইড কোড মোতায়েন করা তুচ্ছ নয়, এবং এটির একটি পৃথক প্রক্রিয়া রয়েছে যার মাধ্যমে কম ওভারহেড দিয়ে কনফিগারেশন মানগুলি আপডেট করা যেতে পারে। দুটোই অগত্যা সত্য নয়। অনেক দোকান তাদের স্থাপনার প্রক্রিয়া খুব কম ওভারহেড আছে। অন্যদিকে, আসলে কিছু দোকান রয়েছে যেখানে কনফিগারেশনের পরিবর্তনগুলি মূলত পরিবর্তিত কোড মোতায়েন করার মতোই ওভারহেডে থাকে। (বৈধকরণ, পুরো গোষ্ঠীর লোকের কাছ থেকে অনুমোদনের প্রয়োজন ইত্যাদি)। সদৃশ উদ্বেগ যদিও অবশ্যই বৈধ।

— কেভিন ক্যাথকার্ট

আপনার অ্যাপ্লিকেশন কোডটির সাথে মিশ্রিত পরিবেশের সেটিংসের সাথে আপনি এক যুক্তি ত্রুটি production বা কার্যকর পরিবেশে অপ্রত্যাশিত পরিবর্তন production উত্পাদন থেকে পরীক্ষার আঘাত, বা পরীক্ষা থেকে উত্পাদন, বা অন্য কোনও অপ্রত্যাশিত এবং সম্ভবত বিপর্যয়কর সংমিশ্রণ থেকে দূরে। সি # তে কোড থেকে পৃথক পরিবেশ-নির্দিষ্ট বৈশিষ্ট্য বজায় রাখা সাধারণত তুচ্ছ। কেন অপ্রয়োজনীয় ঝুঁকি নিবেন?

— জন এম গ্যান্ট

@ ব্যবহারকারী 18১5৫২ "আমি অনুমান করি যে হার্ড-কোডিং পরিবেশের মানগুলি যে কোনও আলোকে নিখরচায় খারাপ অভ্যাস বলে আমার পক্ষে ভুল হবে না।" "হার্ড-কোডিং পরিবেশের মানগুলি সর্বদা খারাপ অনুশীলন" এর বিশ্লেষণ করা যদি এটি সর্বদা খারাপ অনুশীলন হয় তবে হার্ড কোডিং পরিবেশগত মানগুলির কারণে কমপক্ষে একটি সমস্যা চিহ্নিত করা সর্বদা সম্ভব হওয়া উচিত।

— ইমোরি

Answer 2

আপনি ভেবে একেবারে ঠিক বলেছেন এটি একটি খারাপ অভ্যাস। আমি এটি প্রোডাকশন কোডে দেখেছি এবং এটি আপনাকে কামড় দেওয়ার জন্য সর্বদা ফিরে আসে।

আপনি যখন অন্য পরিবেশ যুক্ত করতে চান তখন কী হয়? বা আপনার বিকাশ সার্ভার পরিবর্তন? অথবা আপনার কোনও আলাদা জায়গায় ব্যর্থ হওয়া দরকার? আপনার কনফিগারেশনটি সরাসরি কোডের সাথে আবদ্ধ হওয়ায় আপনি পারবেন না।

কনফিগারেশনটি কোডের বাইরে এবং পরিবেশের মধ্যেই বাধ্য করা উচিত। এটি দ্বাদশ-ফ্যাক্টর অ্যাপের একটি নীতি ( http://12factor.net/config) ) , তবে এটি কোনও অ্যাপ্লিকেশনের জন্য একটি ভাল অনুশীলন। আপনি দেখতে পাবেন যে পরিবেশের ভেরিয়েবলগুলি আপনার অবস্থার জন্য উপযুক্ত নয়, এক্ষেত্রে আমি কোডটি কনফিগারেশন ফাইলের একটি ডাটাবেসে (তবে চেক ইন না করে) কোডের সাথে সেই কনফিগারেশনটি সংরক্ষণ করার পরামর্শ দিয়েছি।

Comments

আপনি যদি কনফিগারেশন ফাইলটি ট্র্যাক না করেন তবে আপনি কীভাবে জানবেন যে আপনার কাছে থাকা কনফিগারেশন ফাইলটি আপনার ভিসিএস থেকে সন্ধান করা সফ্টওয়্যারটির সংস্করণের জন্য বৈধ কিনা তা আপনি কীভাবে জানবেন। (উদাহরণস্বরূপ, একটি চিহ্নবিহীন কনফিগারেশন ফাইলটি একটি অপ্রত্যাশিত উত্স ফাইলের চেয়ে আলাদা নয় - আপনি এটি ছাড়া

— ভিসিএস

আমি একমত নই যে একটি চিহ্নবিহীন কনফিগারেশন ফাইল একটি কঠিন প্রস্তাব। এর আগে আমি যেভাবে এর সাথে ডিল করেছি তার দ্বিগুণ: এক, স্থাপনার ক্ষেত্রে বাইনারিতে এটির কনফিগারেশন সংজ্ঞায়িত করে একটি এক্সএমএল স্কিমাও রয়েছে (যাতে আপনি যাচাই করতে পারেন যে প্রদত্ত কনফিগার ফাইলটি কাজ করবে)। দ্বিতীয়ত, প্রতিটি পরিবেশের জন্য কনফিগারেশন ফাইলগুলি প্রতিটি পরিবেশের জন্য বিভিন্ন ফোল্ডার সহ একটি ডকুমেন্ট নিয়ন্ত্রণ সিস্টেমে সংরক্ষণ করা হয়েছিল। গিটে শাখাগুলি সহ এমন কিছু করা যেতে পারে - সংস্করণটি নিয়ন্ত্রিত, তবে পরিবেশ-কম কোড থেকে বৈষম্যমূলক।

— এমজিডব্লিউ 854

Answer 3

একটির জন্য, (যেমন অন্যরা উল্লেখ করেছেন) এটি একটি খারাপ ধারণা কারণ আপনি নিজের কোডটিতে প্রয়োগের বিশদটি বেঁধে রাখছেন। এটি জিনিস পরিবর্তন করতে অসুবিধা সৃষ্টি করে।

এই উত্তরে উল্লিখিত হিসাবে , আপনি যদি এখন নতুন পরিবেশ যুক্ত করতে চান তবে আপনাকে নিজের কোড আপডেট করতে হবে আপনার প্রোগ্রামটি নতুন পরিবেশে যুক্ত করার পরিবর্তে সর্বত্র ।

আপনার জাভাস্ক্রিপ্ট কোডটিতে এটি করার সাথে আরও একটি গুরুতর ত্রুটি রয়েছে: আপনি আপনার সংস্থার অভ্যন্তরীণ সম্ভাব্য আক্রমণকারীদের সামনে প্রকাশ করছেন। অবশ্যই, আপনি ফায়ারওয়ালের পিছনে থাকতে পারেন, তবে এখনও আপনার মধ্যে একজন অসন্তুষ্ট কর্মচারী বা ভাইরাস প্রবেশ করতে দেবেন এমন কেউ থাকতে পারে।

খারাপ খবর ভাল্লুক।

সেরা করতে জিনিস (আগের লিঙ্ক উত্তর হিসাবে, বারো ফ্যাক্টর অ্যাপ বিষয়ে মহান পরামর্শ আছে) পরিবেশ থেকে আপনার কনফিগারেশন সেট করতে হয়। আপনার ভাষার উপর নির্ভর করে এটি করার বিভিন্ন উপায় রয়েছে। অন্যতম সহজতম (সাধারণত) কেবলমাত্র পরিবেশের ভেরিয়েবলগুলি সেট করা। তারপরে আপনি কোথায় চলছেন তার উপর নির্ভর করে আপনি কেবল ভেরিয়েবলগুলি পরিবর্তন করেন - এটি স্থানীয় ডেভ বক্স, কিউএ, বা উত্পাদন whether অন্য বিকল্পটি কোনও .iniফাইল বা জেএসএনে মানগুলি সংরক্ষণ করে । তবুও অন্য বিকল্পটি আপনার কনফিগার মানকে প্রকৃত কোড হিসাবে সংরক্ষণ করবে। আপনি কোন ভাষা বা পরিবেশ এটি ব্যবহার করছেন তার উপর নির্ভর করে একটি ভাল ধারণা হতে পারে এবং নাও পারে।

তবে চূড়ান্ত লক্ষ্যটি হ'ল আপনাকে একটি কোড বেস নিতে, এটি যে কোনও মেশিনে সমর্থনযোগ্য আর্কিটেকচার / সংযোগ রয়েছে তা ফেলে দিন এবং কোনওভাবে কোড পরিবর্তন না করে এটি চালাতে সক্ষম হবেন।

Answer 4

আমি যদি আমার নিজস্ব মেশিনে ব্যান্ডএন্ডটি চালাতে চাই তবে 55793 পোর্টে না, উদাহরণস্বরূপ যদি আমি একই সাথে একাধিক সংস্করণগুলি তুলনা করি তবে? যদি আমি একটি মেশিনে অ্যাপ্লিকেশন ব্যাকএন্ড চালাতে চাই তবে অন্যটি থেকে এটি অ্যাক্সেস করতে পারি? আমি যদি চতুর্থ পরিবেশ যুক্ত করতে চাই? অন্যরা যেমন উল্লেখ করেছে, আপনাকে কেবলমাত্র প্রাথমিক কনফিগারেশনটি পরিবর্তন করতে পুনরায় সংকলন করতে হবে।

আপনি যে পদ্ধতির বর্ণনা করেছেন তা আপনার দলের পক্ষে অনুশীলনে এখনও কাজ করেছে, তবে এটি অর্থহীনভাবে সীমাবদ্ধ। একটি কনফিগারেশন সিস্টেম যা এই পথের মতো পরামিতিগুলিকে কেন্দ্রীয় কনফিগারেশন ফাইলটিতে নির্বিচারে সেট করার অনুমতি দেয় যা কেবলমাত্র স্থির বিকল্পগুলি সরবরাহ করে তার চেয়ে অনেক বেশি নমনীয় এবং স্যুইচ বিবৃতি পদ্ধতির সাথে আপনি কী সুবিধা অর্জন করবেন? কোনটি!

Answer 5

এটি খারাপ অভ্যাস ।

সফ্টওয়্যার ডিজাইনের একটি প্রাথমিক নীতি: আপনার প্রোগ্রামগুলির মধ্যে হার্ড-কোড কনফিগারেশন মানগুলি রাখবেন না। ভবিষ্যতে পরিবর্তনের যুক্তিসঙ্গত সুযোগ রয়েছে এমন যে কোনও ক্ষেত্রে এটি বিশেষত সত্য।

আপনি যে প্রোগ্রাম কোডটি বিকাশ করেন তা একই কোড হওয়া উচিত যা কোনও পরিবেশে যেমন QA টেস্টিং, ইউএটি এবং উত্পাদনে যায়। কারওর পরে যদি কনফিগারেশন পরিবর্তন করতে হয় কারণ পরিবেশ পরিবর্তিত হয়েছে, বা তাদের এটি একটি নতুন পরিবেশে ব্যবহার করা দরকার, ঠিক আছে। তবে এটি করার জন্য তাদের কখনই আপনার প্রোগ্রামের কোডটি স্পর্শ করা উচিত নয়। এবং প্রতিটি পরিবেশের জন্য আপনার কোডের বিভিন্ন সংস্করণ থাকা উচিত নয়। যদি আপনার প্রোগ্রামটি পরীক্ষা করার পরে পরিবর্তন হয়ে থাকে, তবে আপনি সেই সংস্করণটি পরীক্ষা করেননি। যে কোনও সফটওয়্যার ইঞ্জিনিয়ার, কোনও সফ্টওয়্যার মানের নিশ্চয়তা পেশাদার, কোনও আইটি প্রকল্প পরিচালন পেশাদার, কোনও আইটি অডিটরকে জিজ্ঞাসা করুন।

কেউ অন্য সার্ভারে পরীক্ষার স্থানান্তর করতে পারে। কেউ সিদ্ধান্ত নিতে পারে যে ব্যবহারকারী প্রশিক্ষণের পরিবেশ বা বিক্রয় প্রদর্শনের জন্য পরিবেশও চাই। প্রশাসনিক কনফিগারেশনের জন্য তাদের কোনও প্রোগ্রামারের কাছে যেতে হবে না।

সফ্টওয়্যারটি কারণের মধ্যে অপ্রত্যাশিত পরিস্থিতিগুলি পরিচালনা করতে যথেষ্ট নমনীয় এবং মজবুত হতে হবে।

তদ্ব্যতীত, সফ্টওয়্যারটি সহজভাবে লেখা উচিত নয় তবে এই মুহূর্তে আপনার পক্ষে এটি সবচেয়ে সহজ বলে মনে হচ্ছে। তার জীবদ্দশায় সফ্টওয়্যার রক্ষণাবেক্ষণ ব্যয়ের তুলনায় সফটওয়্যার বিকাশের ব্যয়টি খুব কম। এবং এখন থেকে এক বছর বলি, আপনি সেই কোডটিতে কাজ করা ব্যক্তি নাও হতে পারেন। আপনি পরবর্তী দরিদ্র বোকা লোকটির জন্য আপনি কী রেখে যাচ্ছেন তা ভেবে দেখা উচিত যা আপনি সবুজ চারণভূমিতে যাচ্ছেন তার কয়েক বছর পরে আপনি সম্ভবত যা পিছনে ফেলে রেখেছেন তা বেছে নিতে হবে। অথবা আপনিই সেই ব্যক্তি হতে পারেন যে কয়েক বছর পরে কোডটি তুলেছে, আপনি তখন যা করেছিলেন তা বিশ্বাস না করে।

জিনিসগুলি যথাযথভাবে কোড করুন, সেরা হিসাবে আপনি পারেন। এটি পরে সমস্যা হওয়ার সম্ভাবনা কম।