"সফট কোডিং" আসলে কী?

Question

ইন এই নিবন্ধটি অ্যালেক্স Papadimoulis করে আপনি এই স্নিপেট দেখতে পারেন:

private void attachSupplementalDocuments()
{
  if (stateCode == "AZ" || stateCode == "TX") {

    //SR008-04X/I are always required in these states
    attachDocument("SR008-04X");
    attachDocument("SR008-04XI");
  }

  if (ledgerAmnt >= 500000) {
    //Ledger of 500K or more requires AUTHLDG-1A
    attachDocument("AUTHLDG-1A");
  }

  if (coInsuredCount >= 5  && orgStatusCode != "CORP") {
    //Non-CORP orgs with 5 or more co-ins require AUTHCNS-1A
    attachDocument("AUTHCNS-1A");
  }
}

আমি সত্যিই এই নিবন্ধটি বুঝতে পারি না।

আমি উদ্ধৃতি:

প্রতিটি ব্যবসায়ের নিয়ম ধ্রুবকটি যদি কোনও কনফিগারেশন ফাইলে সংরক্ষণ করা হয় তবে সফ্টওয়্যারটি রক্ষণাবেক্ষণ করা প্রত্যেকের পক্ষে জীবন অনেক বেশি [আরও বেশি ( sic )] হয়ে পড়েছিল: অনেকগুলি কোড ফাইল যা একটি, বড় ফাইল (বা, রূপান্তর, একটি সম্পূর্ণ প্রচুর পরিমাণে কনফিগারেশন ফাইল); ব্যবসায়ের নিয়মে পরিবর্তন মোতায়েনের জন্য নতুন কোডের প্রয়োজন হয় না, তবে ম্যানুয়ালি কনফিগারেশন ফাইলগুলি পরিবর্তন করতে হবে; এবং ডিবাগিং এটি আরও অনেক কঠিন।

এটি একটি কনফিগারেশন ফাইলে "500000" ধ্রুবক পূর্ণসংখ্যা, বা "AUTHCNS-1A" এবং অন্যান্য স্ট্রিং ধ্রুবক থাকার বিরুদ্ধে একটি যুক্তি।

এটি কীভাবে খারাপ অভ্যাস হতে পারে?

এই স্নিপেটে, "500000" কোনও সংখ্যা নয়। উদাহরণস্বরূপ, এটি একই নয়:

int doubleMe(int a) { return a * 2;}

যেখানে 2, এমন একটি সংখ্যা যা বিমূর্ত হওয়া প্রয়োজন। এর ব্যবহার সুস্পষ্ট, এবং এটি এমন কোনও কিছু উপস্থাপন করে না যা পরে আবার ব্যবহার করা যেতে পারে।

বিপরীতে, "500000" কেবল একটি সংখ্যা নয়। এটি একটি তাৎপর্যপূর্ণ মান, যা কার্যকারিতার মধ্যে একটি ব্রেকপয়েন্টের ধারণার প্রতিনিধিত্ব করে। এই সংখ্যাটি একাধিক স্থানে ব্যবহার করা যেতে পারে তবে আপনি যে নম্বরটি ব্যবহার করছেন তা এটি নয়; এটি সীমা / সীমান্তরেখার ধারণা, যার নীচে একটি নিয়ম প্রযোজ্য এবং উপরেরটি অন্যটি।

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

এছাড়াও, যদি আগামীকাল, সরকার দাবি করে "5/3/2050 থেকে, আপনাকে AUTHLDG-122B যুক্ত করতে হবে AUTHLDG-1A এর পরিবর্তে", এই স্ট্রিং ধ্রুবকটি কোনও সাধারণ স্ট্রিং ধ্রুবক নয়। এটি এমন একটি যা একটি ধারণাকে প্রতিনিধিত্ব করে; এটি কেবলমাত্র সেই ধারণার বর্তমান মান (যা "খাত যখন 500k এর উপরে হয় তবে আপনি যে জিনিসটি যুক্ত করেন এটি")।

আমাকে স্পষ্ট করতে দিন। আমি নিবন্ধটি ভুল বলে দিচ্ছি না; আমি ঠিক এটি পাই না; সম্ভবত এটি খুব ভালভাবে ব্যাখ্যা করা হয়নি (অন্তত আমার চিন্তাভাবনার জন্য)।

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

Comments

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

— লুয়ান

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

— বিজিকলপ

উপযুক্ত উন্নত ভাষার জন্য কনফিগারেশনটি স্ট্রিং নয় বরং প্রকৃত সাবরুটাইনগুলির আকার ধারণ করে।

— থরবজর্ন রাভন অ্যান্ডারসন

Answer 1

লেখক অকাল বিমূর্তনের বিরুদ্ধে সতর্ক করছেন।

লাইনটি if (ledgerAmt > 500000)এমন ধরণের ব্যবসায়ের নিয়মের মতো দেখায় যা আপনি বড় জটিল ব্যবসায়িক সিমেটগুলির জন্য দেখতে প্রত্যাশা করবেন যার প্রয়োজনীয়তা অবিশ্বাস্যরকম জটিল তবে সুনির্দিষ্ট এবং ডকুমেন্টেড।

সাধারণত সেই ধরণের প্রয়োজনীয়তা ব্যতীত পুনরায় ব্যবহারযোগ্য যুক্তির চেয়ে ব্যতিক্রমী / প্রান্তের ক্ষেত্রে। ইঞ্জিনিয়ারদের চেয়ে এই প্রয়োজনীয়তাগুলি সাধারণত ব্যবসায় বিশ্লেষক এবং বিষয় বিশেষজ্ঞের মালিকানাধীন এবং রক্ষণাবেক্ষণ করা হয়

(দ্রষ্টব্য যে এই ক্ষেত্রে ব্যবসায় বিশ্লেষক / বিশেষজ্ঞদের প্রয়োজনীয়তার 'মালিকানা' সাধারণত ঘটে থাকে যেখানে বিশেষজ্ঞ ক্ষেত্রে কাজ করা বিকাশকারীদের পর্যাপ্ত ডোমেন দক্ষতা না থাকে; যদিও আমি এখনও বিকাশকারী এবং ডোমেন বিশেষজ্ঞদের মধ্যে রক্ষা করার জন্য সম্পূর্ণ যোগাযোগ / সহযোগিতা আশা করবো) অস্পষ্ট বা দুর্বল লিখিত প্রয়োজনীয়তা।)

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

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

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

500000প্রয়োজনীয়তার নথিতে একাধিক জায়গায় উপস্থিত যেখানে অন্যান্য (সমানভাবে সম্ভবত) পরিস্থিতিটি বিবেচনা করুন তবে সাবজেক্ট ম্যাটার বিশেষজ্ঞরা কেবলমাত্র তার মধ্যে একটি পরিবর্তন করার সিদ্ধান্ত নেন; সেখানে আপনার আরও খারাপ ঝুঁকি রয়েছে যে কেউ constমান পরিবর্তন করে বুঝতে পারে না যে এটি 500000বিভিন্ন জিনিস বোঝার জন্য ব্যবহৃত হয়েছিল - তাই বিকাশকারী এটির মধ্যে এটি পরিবর্তন করে এবং কেবল কোডটিতে এটি খুঁজে পায় এবং কিছু শেষ করে যা তারা ভেঙে ফেলে বুঝতে পারিনি তারা বদলে গেছে।

এই দৃশ্যটি অনেকটা আইনানুগ / আইনি সফটওয়্যার (উদাহরণস্বরূপ বীমা কোটেশন যুক্তি) তে ঘটে থাকে - যারা এই জাতীয় নথিগুলি লেখেন তারা প্রকৌশলী নন এবং তাদের কোনও সমস্যা অনুলিপি নেই + কয়েকটি শব্দ / সংখ্যা সংশোধন করে, অনুমানের পুরো খণ্ডটি আটকানো, তবে এটি বেশিরভাগই একই রকম

এই পরিস্থিতিতে, অনুলিপি-পেস্ট প্রয়োজনীয়তার সাথে মোকাবিলা করার সর্বোত্তম উপায় হ'ল অনুলিপি-পেস্ট কোড লেখা এবং কোডটি প্রয়োজনীয়তার সাথে সাদৃশ্যযুক্ত করা (যতটা সম্ভব সমস্ত ডেটা হার্ড-কোডিং সহ)।

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

Comments

প্রয়োজনের নথির মতো কোডটি আরও পড়ার জন্য একটি ডোমেন নির্দিষ্ট ভাষা (ডিএসএল) একটি ভাল উপায় হতে পারে।

— ইয়ান

ডিএসএল এর আরেকটি সুবিধা হ'ল দুর্ঘটনাক্রমে অ্যাপ্লিকেশন, উপস্থাপনা বা ব্যবসায়ের নিয়মের সাথে দৃ pers়তা যুক্তি মিশ্রিত করা আরও শক্ত করে তোলে।

— এরিক tদ

আপনার অ্যাপ্লিকেশনটি তার নিজস্ব ডিএসএলকে ওয়ারেন্ট দেওয়ার পক্ষে যথেষ্ট বিশেষত ভেবে সাধারণত হুব্রিস হয়।

— brian_o

Those requirements are typically owned and maintained by business analysts and subject matter experts, rather than by engineersযা সর্বদা একটি ভাল ধারণা নয়। কখনও কখনও এই প্রয়োজনীয়তাগুলিকে কোডে রূপান্তরিত করার কাজটি কোণার ক্ষেত্রে প্রকাশিত হয় যেখানে প্রয়োজনীয়তাগুলি ভালভাবে সংজ্ঞায়িত হয় না বা এমনভাবে সংজ্ঞায়িত করা হয় যে এটি ব্যবসায়ের স্বার্থের পরিপন্থী। ব্যবসায় বিশ্লেষক এবং বিকাশকারীরা যদি একটি সাধারণ লক্ষ্য অর্জনে সহযোগিতা করতে পারে তবে প্রচুর সমস্যা এড়ানো যেতে পারে।

— ক্যাস্পার্ড

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

— ক্যাস্পারড

Answer 2

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

এছাড়াও, আগামীকাল, সরকার "5/3/2050 থেকে, আপনাকে AUTHLDG-122B যুক্ত করতে হবে AUTHLDG-1A এর পরিবর্তে"।

হ্যাঁ, তারপরে আপনি কোডটি পরিবর্তন করুন। নিবন্ধটির মূল বিষয় হ'ল একটি কনফিগারেশন ফাইল পরিবর্তনের চেয়ে কোড পরিবর্তন করা আরও জটিল নয়।

নিবন্ধে বর্ণিত পদ্ধতিটি যদি আপনি আরও জটিল যুক্তি পান তবে স্কেল হয় না, তবে মূল বিষয়টি হ'ল আপনাকে একটি রায় কল করতে হবে, এবং কখনও কখনও সহজ সমাধানটি সবচেয়ে ভাল।

আপনি কীভাবে জানবেন যে এর পরে আপনার প্রয়োজন হবে না? বা এই বিষয়ে অন্য কেউ?

এটি ইয়াজিএনআই নীতির মূল বিষয়। কোনও অজানা ভবিষ্যতের জন্য ডিজাইন করবেন না যা বর্তমানের জন্য পুরোপুরি স্বতন্ত্র, নকশা তৈরি হতে পারে। আপনি সঠিক যে যদি মান 500000 প্রোগ্রামে বিভিন্ন জায়গায় ব্যবহার করা হয় এটা অবশ্যই একটি ধ্রুবক থেকে নিষ্কাশিত করা উচিত। তবে প্রশ্নযুক্ত কোডে এটি হয় না।

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

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

Comments

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

— অরেঞ্জডগ

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

— লুয়ান

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

— ম্যাথিউ এম।

@ ওরেঞ্জডগ তাই আপনি প্রস্তাব দিচ্ছেন যে কোনও ডিভ / কিউ / রিলিজ চক্র এবং উপযুক্ত পরীক্ষা ছাড়াই কোনও সফ্টওয়্যার অ্যাপ্লিকেশনটির যুক্তিতে গুরুত্বপূর্ণ পরিবর্তন হওয়া উচিত ?

— এনপিএসএফ 3000

@ ওরেঞ্জডগ: ঠিক আছে আপনি উদাহরণটিতে লজিকটি কনফিগার করার জন্য YAML ব্যবহার করেন। যেহেতু যুক্তি শর্তাধীন নিয়মগুলি অন্তর্ভুক্ত করে, তাই আপনি ওয়াইএএমএলে এই শর্তাবলীর প্রতিনিধিত্ব করার একটি উপায় খুঁজে পান। অভিনন্দন, আপনি পাইথনকে নতুন করে এনেছেন। পাইথনে পুরো অ্যাপটি কেন লিখবেন না?

— জ্যাকবিবি

Answer 3

নিবন্ধটি 'এন্টারপ্রাইজ রুল ইঞ্জিন' সম্পর্কে আলোচনা করেছে যা সম্ভবত তিনি যেটির বিরুদ্ধে তর্ক করছেন তার একটি উত্তম উদাহরণ।

যুক্তিটি হ'ল আপনি যে বিন্দুতে আপনার কনফিগারেশনটি এত জটিল হয়ে উঠলেন যে এতে নিজস্ব প্রোগ্রামিং ভাষা রয়েছে।

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

<statecode id="AZ">
    <document id="SR008-04X"/>
    <document id="SR008-04XI"/>
</statecode>

হতে পারে আপনি খাত্তরের পরিমাণও putুকিয়ে দেবেন?

<statecode id="ALL">
    <document id="AUTHLDG-1A" rule="ledgerAmt >= 50000"/>
</statecode>

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

এটি লক্ষ করা উচিত যে এই নিবন্ধটি 2007 সাল থেকে যখন এই ধরণের জিনিসটি একটি সাধারণ দৃষ্টিভঙ্গি ছিল।

আজকাল আমরা সম্ভবত নির্ভরতা ইনজেকশন (ডিআই) দিয়ে সমস্যাটি সমাধান করব । অর্থাৎ, আপনার একটি 'হার্ড কোডড' থাকতে হবে

InvoiceRules_America2007 : InvoiceRules

যা আপনি হার্ড কোডড, বা আরও কনফিগারযোগ্য দ্বারা প্রতিস্থাপন করবেন

InvoiceRules_America2008 : InvoiceRules

আইন বা ব্যবসায়ের প্রয়োজনীয়তা পরিবর্তিত হলে।

Comments

সম্ভবত আপনার "ডিআই" সংজ্ঞায়িত করা উচিত। এবং সম্ভবত আরও কিছু ব্যাখ্যা।

— বেসিল বাউরক

সেই ফাইলটি সোর্স কন্ট্রোল সিস্টেমে থাকবে না কেন?

— জেডিগোগস

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

— জেডুগোস্জ

আপনার এক্সএমএল থেকে "50000" মানটিকে সত্যই রিফ্যাক্টর করা উচিত এবং এটি একটি আলাদা কনফিগার ফাইলে রাখা উচিত, আপনি কি ভাবেন না? ... এবং এটি 500000 হওয়ার কথা।

— ওয়াইল্ডকার্ড

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

— ইওয়ান

Answer 4

বিপরীতে, "500000" কেবল একটি সংখ্যা নয়। এটি একটি তাৎপর্যপূর্ণ মান, যা কার্যকারিতার মধ্যে একটি ব্রেকপয়েন্টের ধারণার প্রতিনিধিত্ব করে। এই নম্বরটি একাধিক স্থানে ব্যবহার করা যেতে পারে তবে আপনি যে নম্বরটি ব্যবহার করছেন এটি এটি নয়, এটি সীমা / সীমান্তরেখার ধারণা, যার নীচে একটি নিয়ম প্রযোজ্য, এবং কোনটি উপরে।

এবং তা প্রকাশ করে প্রকাশ করা হয়েছে (এবং আমি যুক্তিও দিতে পারি যে মন্তব্যটিও অপ্রয়োজনীয়):

 if (ledgerAmnt >= 500000) {
    //Ledger of 500K or more requires AUTHLDG-1A
    attachDocument("AUTHLDG-1A");
  }

কোডটি কী করছে তা এটি কেবল পুনরাবৃত্তি করছে:

LEDGER_AMOUNT_REQUIRING_AUTHLDG1A=500000
if (ledgerAmnt >= LEDGER_AMOUNT_REQUIRING_AUTHLDG1A) {
    //Ledger of 500K or more requires AUTHLDG-1A
    attachDocument("AUTHLDG-1A");
}

নোট করুন যে লেখক ধরে নিয়েছেন যে 500000 এর অর্থ এই নিয়মের সাথে আবদ্ধ; এটি এমন কোনও মান নয় যা সম্ভবত অন্য কোথাও পুনরায় ব্যবহৃত হবে:

এই পূর্ববর্তী সফট কোডিংয়ের জন্য অ্যাকাউন্টে যে একমাত্র ব্যবসায়ের নিয়ম পরিবর্তিত হতে পারে তা হ'ল লিডার পরিমাণে একটি পরিবর্তন যা AUTHLDG-1A ফর্মের প্রয়োজন। অন্য কোনও ব্যবসায়ের নিয়ম পরিবর্তনের জন্য আরও বেশি কাজ করা দরকার - কনফিগারেশন, ডকুমেন্টেশন, কোড ইত্যাদি

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

Comments

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

— জিরোওন

@ জিরোওন: যদি ব্যবসার নিয়মটি "500K বা তার বেশি লেজারের AUTHLDG-1A এবং AUTHLDG-2B প্রয়োজন হয়" বাদে, সম্ভবত attachDocument("AUTHLDG-2B");লাইনটি যুক্ত করা ব্যক্তি একই সময়ে স্থির-নাম আপডেট করতে ব্যর্থ হবে। এই ক্ষেত্রে, আমি মনে করি কোডটি কোনও মন্তব্য বা ব্যাখ্যাকারী ভেরিয়েবলের সাথে যথেষ্ট পরিমাণে পরিষ্কার । (যদিও এটা জানার জন্য হতে পারে কোড মন্তব্যের মাধ্যমে ব্যবসা প্রয়োজনীয়তা নথির উপযুক্ত অধ্যায় ইঙ্গিত একটি কনভেনশন যেমন একটি প্রচলিত রীতি অনুযায়ী, যে আছে একটি কোড মন্তব্য অধীনে আছে। যে এখানে উপযুক্ত হবে।)

— ruakh

@রুখ, ঠিক আছে, তারপরে আমি ধ্রুবককে ডেকে LEDGER_AMOUNT_REQUIRING_ADDITIONAL_DOCUMENTSআছি (যা সম্ভবত আমার প্রথম জায়গায় করা উচিত ছিল) ref আমি ব্যবসায়ের প্রয়োজনীয় আইডিগুলি গিট কমিট বার্তাগুলিতে উত্স কোডের মধ্যে রাখার অভ্যাসেও আছি।

— জিরোওন

@ জিরোওন: তবে AUTHLDG-3C এর জন্য খাত্তরের পরিমাণটি আসলে সর্বাধিক । এবং AUTHLDG-4D এর জন্য উপযুক্ত খাত্তরের পরিমাণ রাজ্যের উপর নির্ভর করে। (আপনি কী এখনও পয়েন্টটি পেয়েছেন? এই জাতীয় কোডের জন্য, আপনি আপনার কোডটি ব্যবসায়িক বিধিগুলি প্রতিফলিত করতে চান, ব্যবসায়িক বিধিগুলির বিমূর্ততা কিছু নয়, কারণ ব্যবসায়ের নিয়মগুলির বিবর্তনের সাথে লাইন ধরে যাওয়ার আশা করার কোনও কারণ নেই) বিমূর্ততা আপনি গ্রহণ করেছেন))

— রুখ করুন

ব্যক্তিগতভাবে, আমি কোডটিতে ম্যাজিক নম্বর লাগাতে আপত্তি করি না, কোডটি কাঠামোগত করতে আমি আপত্তি জানাই যাতে এটির এই মন্তব্যগুলির প্রয়োজন। এটি যদি আমিই থাকতাম তবে আমি প্রতিটি নথিকে তার নিজস্ব attachIfNecessary()পদ্ধতিতে একটি এনাম উদাহরণ তৈরি করতাম এবং সেগুলির উপরে কেবল লুপ করতাম।

— ডেভিড মোলস

Answer 5

অন্য উত্তরগুলি সঠিক এবং চিন্তাশীল। তবে এখানে আমার সংক্ষিপ্ত-মিষ্টি উত্তর।

  Rule/value          |      At Runtime, rule/value…
  appears in code:    |   …Is fixed          …Changes
----------------------|------------------------------------
                      |                 |
  Once                |   Hard-code     |   Externalize
                      |                 |   (soft-code)
                      |                 |
                      |------------------------------------
                      |                 |
  More than once      |   Soft-code     |   Externalize
                      |   (internal)    |   (soft-code)
                      |                 |
                      |------------------------------------

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

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

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

Comments

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

— ব্লক ডাউন দ্য পাব

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

— রোজিসি

Answer 6

আমরা যখন কোনও খেলনা সমস্যা ব্যবহার করি এবং তখন আমরা কেবল স্ট্রোম্যান সলিউশন তৈরি করি, তখনই আমরা এই ফাঁদটি পড়ি a

প্রদত্ত উদাহরণে, প্রদত্ত মানগুলিকে ইনলাইন মান হিসাবে হার্ডকড করা হয় বা কনসেট হিসাবে সংজ্ঞায়িত করা হয় কিনা তা কোনও পার্থক্য করে না।

এটি পার্শ্ববর্তী কোড যা উদাহরণটিকে একটি রক্ষণাবেক্ষণ এবং কোডিং হরর করে তোলে। যদি হয় কোন পার্শ্ববর্তী কোড, তারপর স্নিপেট জরিমানা, অন্তত ধ্রুবক refactoring একটি পরিবেশ রয়েছে। এমন পরিবেশে যেখানে রিফ্যাক্টরিংয়ের ঘটনা ঘটে না, সেই কোডটির রক্ষণাবেক্ষণকারীরা ইতিমধ্যে মারা গেছেন, যে কারণে শীঘ্রই স্পষ্ট হয়ে উঠবে।

দেখুন, যদি এর চারপাশে কোড থাকে তবে খারাপ জিনিস স্পষ্টভাবে ঘটে।

প্রথমটি খারাপ জিনিসটি হ'ল 50000 মানটি অন্য কোথাও অন্য কোনও মানের জন্য ব্যবহৃত হয়, বলুন, যে খাত্তরের পরিমাণের উপর কিছু রাজ্যে করের হার পরিবর্তিত হয় ... তারপরে যখন পরিবর্তন ঘটে তখন রক্ষণাবেক্ষণকারী জানার উপায় রাখে না, যখন সেগুলি খুঁজে পায় কোডটিতে 50000 টির দুটি উদাহরণ, সেগুলি একই 50k অর্থাত্, বা সম্পূর্ণরূপে সম্পর্কিত নয় 50ks 50 এবং আপনি কি 49999 এবং 50001 সন্ধান করা উচিত, যদি কেউ সেগুলিও ধ্রুবক হিসাবে ব্যবহার করে? কোনও পৃথক পরিষেবার কনফিগারেশনের ফাইলগুলিতে এই ভেরিয়েবলগুলিকে ডাকাডাকি করার জন্য এটি কল নয়: তবে তাদের ইনলাইন হার্ডকোড করা স্পষ্টতই ভুল। পরিবর্তে, তারা ধ্রুবক হতে হবে, সংজ্ঞায়িত হওয়া উচিত এবং ক্লাস বা ফাইলের মধ্যে স্কোপ করা হয় যা তারা ব্যবহৃত হয়। 50k এর দুটি উদাহরণ যদি একই ধ্রুবক ব্যবহার করে তবে তারা সম্ভবত একই আইনী বিধিনিষেধকে প্রতিনিধিত্ব করে; যদি না হয়, তারা সম্ভবত না; এবং যে কোনও উপায়েই তাদের একটি নাম থাকবে,

ফাইলনামগুলি কোনও ফাংশনে - সংযুক্তি ডকুমেন্ট () - এ প্রেরণ করা হচ্ছে যা কোনও ভিত্তি বা এক্সটেনশন ছাড়াই বেস ফাইল নামগুলি স্ট্রিং হিসাবে গ্রহণ করে। ফাইলের নামগুলি মূলত কিছু ফাইল সিস্টেম, বা ডাটাবেসের বিদেশী কী বা যেখানেই অ্যাডথডোকামেন্ট () থেকে ফাইল পায়। তবে স্ট্রিংগুলি আপনাকে এ সম্পর্কে কিছুই বলে না - কতগুলি ফাইল রয়েছে? এগুলি কি ধরণের ফাইল? আপনি কীভাবে জানবেন, নতুন বাজারে ওঠার সময়, আপনাকে এই ফাংশনটি আপডেট করার দরকার আছে কিনা? কী ধরণের জিনিসগুলির সাথে তারা সংযুক্ত থাকতে পারে? রক্ষণাবেক্ষণকারী পুরোপুরি অন্ধকারে চলে যায় এবং তার যা কিছু রয়েছে তার একটি স্ট্রিং রয়েছে যা কোডে একাধিকবার উপস্থিত হতে পারে এবং প্রতিবার প্রদর্শিত হওয়ার পরে বিভিন্ন জিনিস বোঝাতে পারে। এক জায়গায় "SR008-04X" একটি প্রতারণা কোড is অন্যটিতে এটি চারটি এসআর 8008 বুস্টার রকেট অর্ডার করার জন্য একটি আদেশ। এটা এখানে' ফাইল নাম? এগুলি কি সম্পর্কিত? কেউ সবেমাত্র সেই ফাইলটি অন্য ক্লায়েন্ট, "ক্লায়েন্ট" উল্লেখ করার জন্য পরিবর্তন করেছিলেন। তারপরে আপনাকে, দুর্বল রক্ষণাবেক্ষণকারীকে বলা হয়েছে যে "ক্লায়েন্ট" ফাইলটির নতুন নামকরণ "গ্রাহক" করতে হবে। তবে কোডটিতে স্ট্রিংটি "CLIENT" 937 বার প্রদর্শিত হচ্ছে ... আপনি এমনকি কোথায় দেখা শুরু করবেন?

খেলনা সমস্যা যে মান এই সমস্ত অস্বাভাবিক এবং যুক্তিসঙ্গতভাবে কোডে অনন্য হতে নিশ্চিত করা যেতে পারে। "1" বা "10" নয় "50,000"। "ক্লায়েন্ট" বা "রিপোর্ট" নয় "SR008-04X"।

strawman যে impenetrably অস্বচ্ছ ধ্রুবক সমস্যা মোকাবেলার শুধুমাত্র অন্যান্য উপায় তাদের কিছু সম্পর্কহীন সেবার কনফিগ ফাইলে বন্ধ মধুচক্র করা।

একসাথে, আপনি যে কোনও যুক্তি সত্য প্রমাণ করতে এই দুটি ফলস ব্যবহার করতে পারেন।

Comments

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

— লুয়ান

উদাহরণটি ভেঙে যায় না কারণ এটি খেলনার সমস্যা। পার্শ্ববর্তী কোডটি সর্বদা ভয়াবহ হবে কারণ সফ্টওয়্যারটির যে বিজনেস বিধিগুলি কার্যকর করা হয় তা হতাশ । প্রচেষ্টা পার্শ্ব-ধাপে নিয়ম ইঞ্জিন ও DSLs সঙ্গে এই মৌলিক চ্যালেঞ্জ এবং যে কোন বস্তু প্রায়ই হয় প্রোগ্রামার দীর্ঘসূত্রিতার কারণ সি এস সমস্যা সমাধানে কর ফরম এর intricacies সমাধানে চেয়ে বেশি উপভোগ্য। 'কমনীয়তা' অর্জনের চেষ্টাগুলি প্রায়শই বোকামির ভুল হিসাবে কাজ করে কারণ সফ্টওয়্যারটির চূড়ান্ত কাজটি একটি জটিল বিপর্যয়ের মডেল to

— হোসাইম

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

— ডেভিড মোলস

Answer 7

এটিতে বেশ কয়েকটি সমস্যা রয়েছে।

একটি সমস্যা হ'ল একটি নিয়মের ইঞ্জিনটি তৈরি করা উচিত যা প্রোগ্রামের বাইরেই সমস্ত নিয়মকে সহজেই কনফিগার করা যায়। এর অনুরূপ ক্ষেত্রে উত্তর বেশিরভাগ ক্ষেত্রেই হয় না no নিয়মগুলি অদ্ভুত উপায়ে পরিবর্তন করা হবে যা পূর্বাভাস দেওয়া শক্ত নয় যার অর্থ যখনই কোনও পরিবর্তন ঘটে তখন নিয়ম ইঞ্জিনটি প্রসারিত করতে হবে।

আর একটি সমস্যা হ'ল কীভাবে এই বিধিগুলি পরিচালনা করতে হয় এবং আপনার সংস্করণ নিয়ন্ত্রণে তাদের পরিবর্তনগুলি। এখানে সর্বোত্তম সমাধান হ'ল প্রতিটি নিয়মের জন্য বিধি বিভক্ত করা।

এটি প্রতিটি নিয়মের নিজস্ব বৈধতা পাওয়ার অনুমতি দেয়, কিছু নিয়ম প্রতি বছর পরিবর্তন হয়, কিছু অনুমতি দেওয়া হয় বা চালান জারি করা হয় তখন কিছু পরিবর্তন হয়। কোনও সংস্করণ প্রয়োগ করতে হবে তা যাচাই করে তা নিজেই নিয়ম করে।

এছাড়াও ধ্রুবকটি ব্যক্তিগত হওয়ায় এটিকে কোডের অন্য কোথাও অপব্যবহার করা যাবে না।

তারপরে সমস্ত নিয়মের একটি তালিকা আছে এবং তালিকাটি প্রয়োগ করুন।

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

Answer 8

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

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

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

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

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

Comments

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

— এরিক