কোনও সার্ভারকে যা গ্রহণ করবে তাতে "বিনীত হতে হবে" এবং "ত্রুটিযুক্ত ইনপুটটি নিঃশব্দে বাতিল করা উচিত"?


27

আমি এই ছাপে ছিলাম যে এখন পর্যন্ত সকলেই এই ম্যাক্সিমটি ভুল বলে সম্মত হন। তবে আমি সম্প্রতি এই উত্তরটি দেখেছি যার 137 বার (আজকের হিসাবে) একটি "বিনীত" মন্তব্য রয়েছে oted

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

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

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


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

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

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

সুতরাং, কিছু এপিআই প্রকাশকারী কোনও সার্ভারটি কি হালকা হওয়া উচিত বা এটি খুব খারাপ ধারণা?


এখন ব্যবহারকারী ইনপুট লেন্সিয়েন্ট হ্যান্ডলিং উপর। YouTrack (একটি বাগ ট্র্যাকিং সফ্টওয়্যার) বিবেচনা করুন। এটি পাঠ্য প্রবেশের জন্য এমন ভাষা ব্যবহার করে যা মার্কডাউনের স্মরণ করিয়ে দেয়। এটি "লেনিয়েন্ট" বাদে। উদাহরণস্বরূপ, লেখা

- foo
- bar
- baz

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

সুতরাং, আমার সফ্টওয়্যারটি কোন ব্যবহারকারী এটি গ্রহণ করে তা লেনিয়েন্ট হওয়া উচিত ?


4
"ত্রুটিযুক্ত ইনপুটটি নিঃশব্দে বাতিল করুন" সম্পর্কিত আমি প্রতিটি ক্ষেত্রে জিজ্ঞাসা করব যেটি ত্রুটিযুক্ত ইনপুট হিসাবে বিবেচনা করা উচিত। আপনি যদি কোনও ব্যবহারকারীকে প্রশ্ন জিজ্ঞাসা করেন এবং "হ্যাঁ" বা "না" প্রত্যাশা করেন, তবে "হ্যাঁ" ত্রুটিযুক্ত ইনপুট কি? কিভাবে "y"? কীভাবে "ওউই"? সাধারণভাবে, ব্যবহারকারীকে বলার ব্যাপারে লজ্জা পাবেন না যে তাদের ইনপুটটি আপনার প্রত্যাশা মতো নয়। তবে নিশ্চিত করুন যে আপনি যথাসম্ভব অন্তর্ভুক্ত হয়ে পড়েছেন - মনে মনে, এটিই "বিনীত হন" বলতে বোঝায়।

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

2
প্রকৃতপক্ষে এইচটিএমএলটির লেন্সিটিই কেন এটি এত জনপ্রিয় হয়েছিল (এবং এটি কেন বাদ দেওয়া হয়েছিল এক্সএইচটিএমএল এর কঠোরতা)।
অলিভার ওয়েইল

1
আমি মনে করি কীটি হ'ল এটি যদি এমন কোনও দৃশ্যের হয় যেখানে আপনি এটিকে চূড়ান্তভাবে ব্যর্থ হওয়ার অনুমতি দিতে পারেন তবে আপনি খুব কম সময়ে ইভেন্টটি লগইন করেন।
রিগ

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

উত্তর:


9

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

বেশিরভাগ সময় যখন ভুল / অবৈধ ডেটা সরবরাহ করা হয়, তখন সেই ডেটা সরবরাহকারী (এটি ব্যবহারকারী বা অন্য কোনও প্রোগ্রামের আউটপুট হোক) সম্ভবত তা অবৈধ তা জানেন না। ত্রুটিটি গ্রাস করা তাদের বিশ্বাসে রাখবে যে এটি বৈধ (বা হতে পারে) বৈধ, যা অবৈধ ডেটা প্রসারিত করে।

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


25

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

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

শেষ পর্যন্ত, আমি মনে করি যে গুরুত্বপূর্ণটি হ'ল: আপনার ব্যবহারকারীরা কীসের বিষয়ে যত্নশীল হন?


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

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

@ টিমউই: যে ক্ষেত্রে, সেই ইউনিক্সি কমান্ড-লাইনের সরঞ্জামগুলি খারাপভাবে নকশাকৃত;)
ডেমিয়ান ব্রেচট

3
@ ক্রমিনস - আমি মনে করি এটির একটি ভাল উদাহরণ হবে: ডিবাগ মোডে, আপনি কোনও সমস্যাটি থামাতে চান এবং কোনটি ভুল হয়েছে তা আপনাকে বলতে চান want প্রোডাকশন মোডে আপনি চান আপনার প্রোগ্রামটি পাশাপাশি চালিয়ে যেতে পারে এবং এটি পরিচালনা করতে পারে এমন কোনও সমস্যা লগ করুন। এইভাবে, প্রোগ্রামাররা তারা কী ভুল করেছে তা দেখতে এবং এটি ঠিক করতে পারে, তবে ব্যবহারকারীরা যে জিনিসগুলি ঠিক করতে পারেন না সেগুলি নিয়ে উদ্বিগ্ন হবেন না। কিছু সমস্যা স্পষ্টতই ঠিক করা যায় না, তবে একটি ভাল উদাহরণ হ'ল সিএসএস শৈলীর নিয়ম, যেখানে আপনি কোনও শৈলীর নিয়ম না বুঝতে পারলেও আপনি এখনও কোনও সাইট রেন্ডার করতে পারেন।
মনিকা

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

7

দুটি ধরণের "লেনিয়েন্ট" রয়েছে: একটি হ'ল ভুল ইনপুট গ্রহণ করা এবং এটি বোঝার চেষ্টা করা এবং অন্যটি হ'ল বিভিন্ন ধরণের ইনপুট গ্রহণ করা।

সাধারণত, যখন আপনি এটি সম্ভব হয় তখন আপনি সর্বদা দ্বিতীয়টি চান। প্রথমটি হ'ল আপনি যখন দ্রুত এবং কঠোরভাবে মারা যান। একটি উদাহরণ: তারিখ।

এখানে বৈধ, অবৈধ এবং দ্ব্যর্থহীন কিছু উদাহরণ রয়েছে।

  • 2011-01-02
  • 01/02/2011
  • Jan 2, 2011
  • 2-Jan-2011
  • Green

শুধুমাত্র এক অবৈধ এখানে ইনপুট আছে: Green। এমনকি এটি একটি তারিখ হিসাবে গ্রহণ করার চেষ্টা করবেন না। যেহেতু Greenঅবশ্যই তারিখ নয়, এটি এমন একটি ক্ষেত্রে যেখানে নীরব ব্যর্থতা গ্রহণযোগ্য।

01/02/2011বৈধ, তবে অস্পষ্ট। এটি মার্কিন তারিখ (জানুয়ারী 2) হিসাবে প্রবেশ করা হয়েছে কি না তা আপনি অগত্যা জানেন না (ফেব্রুয়ারি 1)। এখানে, জোরে জোরে ব্যর্থ হওয়া এবং ব্যবহারকারীকে একটি দ্ব্যর্থহীন তারিখের জন্য জিজ্ঞাসা করা ভাল।

2011-01-02সাধারণত এটি দ্ব্যর্থহীন বলে বিবেচিত হয়, তাই এটি এগিয়ে যেতে এবং এটি "YYYY-MM-DD" ফর্ম্যাটটি ধরে নেওয়া প্রায়শই ভাল, এবং কেবল এই লাইনে আরও ব্যর্থ হয়। ব্যবহারকারী ইনপুট নিয়ে কাজ করার সময় এটি কিছুটা রায় রায়।

Jan 2, 2011এবং 2-Jan-2011বৈধ এবং দ্ব্যর্থহীন, তাদের গ্রহণ করা উচিত। যাইহোক, The Second of January of the year 2011হয় এছাড়াও বৈধ এবং দ্ব্যর্থহীন কিন্তু যাচ্ছে যে পর্যন্ত ধৈর্য অনুরোধে জন্য Overkill হয়। এগিয়ে যান এবং নীরবে এটি ব্যর্থ, ঠিক যেমন Green

সংক্ষেপে , উত্তরটি "এটি নির্ভর করে"। কী ইনপুট করা যায় তা একবার দেখুন এবং নিশ্চিত হন যে আপনি কখনও বিরোধমূলক ধরণের ইনপুট গ্রহণ করছেন না (যেমন DD/MM/YYYYবনাম MM/DD/YYYY)।

সংযুক্ত প্রশ্ন / মন্তব্য প্রসঙ্গে, এটি একটি ঘটনা 2011-01-02। ইনপুটটি JSON এর মতো দেখাচ্ছে এবং মাইমটাইপটি ভুল হলেও জেএসএনের মতো বৈধতা দেবে; এগিয়ে যান এবং এটি ব্যবহার করার চেষ্টা করুন এমনকি যদি এটি লাইনে আরও কিছু সময় ব্যর্থ হয়।


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

1
@ ক্রমিন্স আমি মনে করি আপনি যেখানে লেন্সি রয়েছেন তা ভুল বোঝাবুঝি। এপিআই এটা কি কোমল হওয়া উচিত গ্রহণ (এটা সব বুঝতে হবে 2011-01-02, Jan 2, 2011এবং 2-Jan-2011এটা কি, যদি এটা খুব কঠিন বাস্তবায়ন না), আউটপুট । সেই এপিআই-র ভবিষ্যতের ক্লায়েন্টদের যতক্ষণ না তারা কোনও একটিকে সঠিকভাবে ইনপুট করে চলেছে ততক্ষণ তাদের প্রদত্ত কোনও সম্পর্কে জানার দরকার নেই। আদর্শভাবে, API স্তরটি সমস্তগুলি একই অভ্যন্তরীণ উপস্থাপনায় রূপান্তরিত করবে যা কোডটি এটি পাশ করার আগে ব্যবহার করে।
ইজকাটা

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

4
@ ইজকাটা: আপনি ভুল বুঝে গেছেন। কল্পনা করুন যে একটি পুরানো প্রোগ্রাম ছিল যা কেবল বাইনারি হিসাবে উপলভ্য। আপনাকে একটি নতুন প্রোগ্রাম লিখতে হবে যা পুরানো হিসাবে একই ইনপুট গ্রহণ করে। যদি পুরানো প্রোগ্রামটি যা গ্রহণ করে তাতে সুনির্দিষ্টভাবে সংজ্ঞায়িত করা হয়, আপনার কাজটি সুনির্দিষ্টভাবে সংজ্ঞায়িত হয়েছে। যদি এটি হালকা হয় তবে আপনার কাজটি অসম্ভব।
টিমউই

1
একটি দৃ strongly়ভাবে একমত না। এটি ব্যবহারকারী-প্রবেশ করা ইনপুট না থাকলে, ইনপুট এবং আউটপুট উভয় ক্ষেত্রে সর্বদা কঠোর থাকুন। যখন আপনার পরিষেবাটি পুনরায় প্রয়োগ করা দরকার তখন কী ঘটে? আপনি কি সমস্ত সম্ভাব্য তারিখের ফর্ম্যাটগুলি নথি করেছিলেন? আপনি পুরানো ক্লায়েন্টদের বিরতি না চান সেহেতু আপনার এগুলি সমস্ত বাস্তবায়ন করতে হবে। দয়া করে, সমস্ত মেশিন উত্পাদিত তারিখের উদাহরণ এবং সময়সীমার জন্য আইএসও 8601 ব্যবহার করুন: এটি ভালভাবে নির্দিষ্ট এবং লাইব্রেরিতে বিস্তৃতভাবে উপলব্ধ। যাইহোক, 2011-01-02 আসলে কী বোঝায়? সময়কাল ২ য় 00:00 থেকে 3 য় তারিখ পর্যন্ত 00:00? কোন সময় অঞ্চলে?
ডিবিবেকে

6

নিঃশব্দে ব্যর্থ হওয়া আপনি সম্ভবত সবচেয়ে খারাপ কাজ করতে পারেন। আপনি কি নিরব ব্যর্থতা নিয়ে কোনও API ডিবাগ করার চেষ্টা করেছেন? এটা অসম্ভব

"পুনরুদ্ধার করতে আপনার যথাসাধ্য চেষ্টা করুন তবে বিশদ ত্রুটি পাঠান" এবং সেখানে "নিরব ব্যর্থতা" রয়েছে।


3

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

ইউআই গঠনমূলক ব্যবহারকারীর প্রতিক্রিয়া এবং ব্যবহারকারীর ইনপুটকে প্রতিরোধ করার জন্য আমরা ব্যবহৃত থাম্বের নিয়ম।


তবে আপনি যদি এখানে উত্তরগুলি লক্ষ্য করেন তবে সকলেই সম্মত হন বলে মনে হয় এটি কেবলমাত্র ইউআই-এর জন্য অর্থাত্ মূল আইনের বিপরীতে makes
রোমান স্টারকভ

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

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

3

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

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

ত্রুটিপূর্ণ ইনপুট খারিজ তাই চুপটি জরিমানা, তাই যতদিন আপনি হয় হয় যে ইনপুট হ্যান্ডলিং। এটি কখনও যেমন মেঝেতে ফেলে দেওয়া উচিত নয়।


একটি এপিআই-এর জন্য, আমি মনে করি যে বিন্যস্ত হওয়া কোনও প্রোগ্রামের মতোই। ইনপুটটি এখনও ভুল , তবে আপনি যতটা সম্ভব মেরামত করার চেষ্টা করছেন। পার্থক্যটি হ'ল বৈধ মেরামতের বিবেচনা করা হয় । আপনি চিহ্নিত হিসাবে, একটি লেন্সিয়েন্ট এপিআই সমস্যা সৃষ্টি করতে পারে কারণ লোকেরা উপস্থিত নেই এমন "বৈশিষ্ট্য" ব্যবহার করে।

অবশ্যই, একটি এপিআই রচনার নিয়মের একটি নিম্ন স্তরের সংস্করণ । যেমনটি, এটি সত্যই অন্তত বিস্ময়ের নিয়মের আওতায় আসে কারণ এটি একটি ইন্টারফেস।

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

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


2

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

  1. মূল্যবান সার্ভারের সময় হ্রাস। প্রতি সেকেন্ডে 1000+ অনুরোধের সাথে, প্রতিটি অনুরোধে ত্রুটিগুলি পরীক্ষা করা প্রতিটি ক্লায়েন্টের জন্য ধীর সাড়া দেয় in
  2. সঠিক ইনপুট সরবরাহ করে এমন ক্লায়েন্ট / ক্লায়েন্ট-প্রোগ্রামগুলির প্রতি অন্যায় তা ছাড়া, যখন কোনও সার্ভার সাইড প্রোগ্রামার সার্ভার কোডে বসে থাকে তখন তাকে ত্রুটিযুক্ত ইনপুটগুলি কী হতে পারে তার বিভিন্ন ক্ষেত্রে চিন্তা করতে হবে। কে সিদ্ধান্ত নেবে?

সার্ভার প্রোগ্রামগুলি ত্রুটিযুক্ত ইনপুট গ্রহণ করা উচিত নয়, তবে ত্রুটিযুক্ত ইনপুট থাকলে সার্ভারগুলিকে ক্লায়েন্টকে একটি ত্রুটি বার্তা ফেরানো উচিত।


2

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

একটি বিষয় যা প্রোটোকল ডিজাইনে, ফর্ম্যাটিং স্পেক বা "ভাষা" তৈরিতে অত্যন্ত সহায়ক হতে পারে তার মধ্যে সম্ভাব্য অ-বোঝা আইটেমগুলির চার বিভাগের পার্থক্য করার উপায় থাকতে পারে:

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

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

যে কোনও ক্ষেত্রে সর্বাধিক গুরুত্বপূর্ণ বিষয় হ'ল অস্পষ্ট বা ভুল বুঝে নেওয়া ডেটাটিকে ভুল তথ্যতে রূপান্তর করা এড়ানো avoid কিছু ক্ষেত্রে, অস্পষ্ট ডেটা আদৌ প্রচার করা থেকে প্রত্যাখ্যান করা ভাল, যদিও অন্যান্য ক্ষেত্রে প্রাপক এটিকে দ্ব্যর্থহীন বলে বিবেচনা করবেন সে ক্ষেত্রে যথাযথভাবে প্রচার করা ভাল। সত্যিকারের বিপজ্জনক যদি না হয় তবে তা হ'ল বিভিন্ন অনুমানের সাহায্যে ডেটা রূপান্তর, যেমন তারিখের তালিকাকে রূপান্তরিত করা:

01/12/12
13/12/12
99/12/12

তারিখগুলির মতো তালিকায়

2012-01-12
2012-12-13
1999-12-12

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


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

1

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

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

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

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


0

বিবৃতিটি ইন্টারনেটে তথ্য প্রেরণের বিষয়ে। ইন্টারনেটে তথ্য প্রেরণের সাথে একটি বিষয় হ'ল এটি সর্বদা লক্ষ্যমাত্রায় পাওয়া যায় না বা খণ্ডিত হয় না।


0

এখানে এমন কিছু মনে হচ্ছে যা মনে হচ্ছে - ব্যর্থতার পরিণতিগুলি কী?

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

অন্যদিকে, যদি এটি কোনও মিনিটম্যান তৃতীয়টির লক্ষ্য জিজ্ঞাসা করে আপনি "মস্কো "টিকে ইনপুট হিসাবে প্রত্যাখ্যান করেন কারণ এটি সম্ভবত অস্পষ্ট।


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

@ ক্রমিনস: আপনার কাছে সেই ধরণের জিনিসটির জন্য ডিবাগ মোড রয়েছে যা ত্রুটিগুলি সম্পর্কে ঝাঁকুনির বিষয়ে কঠোর।
লোরেন পেচটেল
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.