জটিল সফ্টওয়্যারটি কতটা বাড়াবাড়ি / দৃust়তা প্রয়োগ করতে হবে?


12

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

জটিল সফ্টওয়্যার সংজ্ঞা:

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

সম্পাদিত: জটিল কী? জটিল এবং জটিল মধ্যে একটি বড় পার্থক্য আছে দয়া করে দেখুন । (সরাসরি লিঙ্ক)

এই প্রশ্নের মধ্যে অপ্রয়োজনীয়তা / দৃust়তার সংজ্ঞা :
(মন্তব্যের ভিত্তিতে দৃ Added়তা যুক্ত করা হয়েছে)

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

যেমন সফ্টওয়্যার উদাহরণ:

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

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

সম্ভবত সম্পর্কিত:


5
এখানেই অতিরেক না, না না বলিষ্ঠতার ...

5
উত্তরটি কি "প্রয়োজনীয় যতটা প্রয়োজন?"
ডিন হার্ডিং

@ ডিয়ান - একেবারে এটি অন্যর মতো প্রয়োজন। কৌতুকটি এটি ব্যাখ্যা করতে হয় এবং এর ফলাফল এবং ব্যবহারকারীদের কাছে ব্যয় হয় তবে এটি করা যায়।
জন হপকিন্স

প্রতিক্রিয়াটির জন্য ধন্যবাদ @ থরবজর্ন আমি শিরোনাম এবং সংজ্ঞায় দৃust়তা যুক্ত করেছি।
rwong

পুরাতন কোড বেস থেকে দূরে থাকুন, যদি না আপনার 5 টি বাচ্চা খায়।
কাজ

উত্তর:


7

এটি একটি ব্যবসায়িক প্রশ্ন, কোনও প্রযুক্তিগত নয়।

কখনও কখনও আমি গবেষকদের সাথে বা প্রোটোটাইপে কোডিং করি, তাই আমরা খুব কম দৃust়তার সাথে এমন কিছু তৈরি করব build যদি এটি বিরতি দেয় তবে আমরা এটি ঠিক করি। আমরা যদি শীঘ্রই কোডটি ফেলে দিতে যাচ্ছি তবে অতিরিক্ত যাদুতে বিনিয়োগ করার কোনও অর্থ নেই।

তবে যদি আপনার সিস্টেমের ব্যবহারকারীদের এটির দৃust়তা প্রয়োজন হয় তবে আপনার এটি সেভাবে তৈরি করা উচিত। আপনার যে ধরণের অপ্রয়োজনীয়তা / দৃust়তার প্রয়োজন হয় না সেগুলি উপেক্ষা করার সময় আপনার এবং তাদের দীর্ঘমেয়াদী সাফল্যকে সর্বাধিক কার্যকর করার উপায়গুলি বিশেষভাবে শক্তিশালী করা উচিত।

সাধারণত, আমি রুক্ষ শুরু করি এবং পরে সময়ের সাথে দৃust়তা যোগ করি। আমি প্রায়শই সাধারণ পরিকল্পনা প্রক্রিয়ার এই অংশের মতো প্রশ্ন করি। আমি সাধারণত এক্সট্রিম প্রোগ্রামিং স্টাইলে কাজ করি, যেখানে আমরা কাঙ্ক্ষিত বৈশিষ্ট্যগুলির একটি দীর্ঘ তালিকা তৈরি করি এবং আমি সেখানে দৃ features়তা বৈশিষ্ট্যগুলিও রাখি। উদাহরণস্বরূপ, "সিস্টেম কোনও একক বাক্সের ব্যর্থতা থেকে বেঁচে যায়," "ব্যবহারকারী ফেসবুক শংসাপত্রগুলি ব্যবহার করে যোগ দিতে পারেন" এই জাতীয় জিনিসের সাথে মিশে যায়। যেটি প্রথমে আসে, আমি প্রথমে তৈরি করি।


5

জটিল সফটওয়্যার সাধারণত হয় আপনি সম্ভবত জানেন, কিন্তু স্পষ্টত না, কারণ এটি করতে সবচেয়ে ভালো উপায় কিন্তু মহান বিষদভাবে কিভাবে সফ্টওয়্যার কাজ বুঝতে কারণ ডেভেলপারদের বদলে বিদ্যমান কোড প্রয়াস "এ ট্যাক" ঝোঁক অপ্রয়োজনীয়।

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

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

সম্পাদনা: প্রশ্নের পুনর্বিবেচনার আলোকে, আমি দৃust়তা সম্পর্কে কিছুটা যুক্ত করব। আমার মতে, প্যারামিটার চেকিং কেবল তখনই করা উচিত যদি আপনি ক) খুব নির্দিষ্ট বিন্যাস যেমন স্ট্রিং বা বি হিসাবে একটি তারিখের মান হিসাবে গ্রহণ করেন) বিভিন্ন পরামিতিগুলি একে অপরের সাথে সংঘটিত হতে পারে বা পারস্পরিক একচেটিয়া হতে পারে।

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

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

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


4
আমি মনে করি আপনি প্রশ্নটি ভুল বুঝেছেন। তার অর্থ "রিন্ডানডেন্সি" যেমন "ত্রুটি দেখা দিলে" অগ্নিকাণ্ডে মারা না যাওয়া "" নকল কোড লেখার মতো নয় "means দৃ others়তা এটির জন্য আরও ভাল শব্দ হিসাবে অন্যরা উল্লেখ করেছে।
অ্যাডাম শিখুন

অপ্রয়োজনীয় কাজগুলি একটি ইতিবাচক বিষয়। মানবদেহ এখানে নিখুঁত উদাহরণ।
ক্লাদিউ ক্রিঙ্গা

3

সফ্টওয়্যারটি ব্যবহারকারীর ভুলগুলি ক্ষমা করতে হবে এবং প্রোগ্রামার ভুলগুলি সম্পূর্ণরূপে অসহিষ্ণু হওয়া উচিত।

অর্থ, সফ্টওয়্যারটি খুব শক্ত এবং ব্যবহারকারী ইনপুট ত্রুটি এবং সিস্টেম কনফিগারেশন ত্রুটির মতো জিনিসগুলির মসৃণ পুনরুদ্ধারের মঞ্জুরি দেওয়া উচিত। খুব কমপক্ষে একটি বন্ধুত্বপূর্ণ ত্রুটি বার্তা উল্লেখ করে যেখানে ত্রুটিটি ঘটেছে (ইনপুট বাক্স, কনফিগার ফাইল, কমান্ড লাইন আর্গুমেন্ট, ইত্যাদি ...) এবং কোন সীমাবদ্ধতা লঙ্ঘন করা হয়েছে ("অবশ্যই X অক্ষরের চেয়ে কম হওয়া উচিত," "বৈধ বিকল্পগুলি [এক্স , ওয়াই, জেড] ", ইত্যাদি ...) অতিরিক্ত দৃust়তার জন্য, সফ্টওয়্যারটি বিকল্প প্রস্তাব করতে পারে, বা যুক্তিসঙ্গত ডিফল্ট ব্যবহার করতে পারে (তবে এটি সর্বদা ইঙ্গিত করা উচিত যে এটি ব্যবহারকারী নির্দিষ্টভাবে ব্যবহার করছে না)।

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

অন্যদিকে, প্রোগ্রামার ত্রুটির বিরুদ্ধে রান-টাইম দৃ rob়তা থাকা উচিত নয়। যদি কোনও ফাংশনের প্যারামিটারগুলির জন্য পূর্ব শর্তাদি থাকে, তবে তাদেরকে রান-টাইম চেকগুলি নয়, দৃser়তার সাথে চেক করা উচিত। কল স্ট্যাকের তিন বা চার স্তরের একই প্যারামিটারে অপ্রয়োজনীয় ত্রুটি পরীক্ষা করা এবং প্রতিবেদন করা এটি আমার এক বিশাল পোষা প্রাণী e

 int A(int x)
 {
   if (x==0) return -1
   ...
 }
 int B(int x)
 {
   if (x==0) return -1
   err = A(x)
   if (err) return err;
   ...
 }
 // and so on and so on....

এটি কেবল অতিরিক্ত অনিবদ্ধ জটিলতা। কোনও ফাংশন কীভাবে অন্যটির অপব্যবহারের মাধ্যমে প্রবর্তিত ত্রুটি পরিচালনা করবে তা নির্ধারণের জন্য আপনার সময় ব্যয় করা উচিত নয়। এটি যদি 'দৃ are়তা' প্রকারের আপনি উল্লেখ করছেন - আপনার এটির দরকার নেই don't দৃser়সংস্থান এবং পুঙ্খানুপুঙ্খ একীকরণ পরীক্ষার সাথে এটি প্রতিস্থাপন করুন।


3

এটি একটি প্রয়োজনীয় জিনিস।

দৃ rob়তা জন্য কোন প্রয়োজন আছে?

"যখন যোগাযোগের লিঙ্কটি ব্যর্থ হয়, ভুল প্যাকেটগুলি ফেলে দেওয়া হয়" "লিঙ্কটি আবার কাজ শুরু করলে, কোনও লেনদেন দু'বার প্রক্রিয়াজাত করা হয় না"

ত্রুটি পুনরুদ্ধারের জন্য ব্যবহারের কেস থাকতে হবে (অন্যথায় আপনি কীভাবে এটি কীভাবে করবেন তা আপনি কীভাবে জানেন?)

প্রোগ্রামারদের যেতে যেতে দৃ rob়তা আবিষ্কার করার জন্য এটি রেখে দেওয়া (যদি প্রয়োজন হয়) ফলে "জাদুকরী" সিস্টেম তৈরি হয়।

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


2

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


যদি আবার গণনা করা এবং রিপোর্ট / দৃশ্যমান না হয়ে পুনরায় চেষ্টা করা হয়, তবে আপনার সিস্টেমগুলি হ্রাস পাবে এবং তাদের যাদুকরী স্ব-সংশোধন প্রকৃতির কারণে খারাপভাবে চলতে শুরু করবে। পুনরায় চেষ্টা এবং ত্রুটিগুলি জানার জন্য সর্বদা ফাঁস বালতি কাউন্টারগুলি (PLOPD4) ব্যবহার করুন। এইভাবে, একটি নিম্ন স্তরের অগ্রাহ্য করা হলেও সমস্যাগুলি ব্যবহারকারীদের কাছে দৃশ্যমান হয়।
টিম উইলিসক্রফ্ট
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.