আপনি যা গ্রহণ করেন তাতে উদার হোন… না?

Question

[অস্বীকৃতি: এই প্রশ্নটি বিষয়গত, তবে আমি তথ্য এবং / বা প্রতিক্রিয়ার দ্বারা সমর্থন পেয়ে উত্তর পেতে পছন্দ করব]

আমি মনে করি সবাই দৃ the ়তা নীতি সম্পর্কে জানে , সাধারণত পোস্টেলের আইনে সংক্ষিপ্ত:

আপনি যা প্রেরণ করেন তাতে রক্ষণশীল হন; আপনি যা গ্রহণ করেন তাতে উদার হন।

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

যদিও আমি লক্ষ্য করেছি যে সেখানে টিসিপি প্রোটোকলের আরএফসি "নীরব ব্যর্থতা" গ্রহণযোগ্য বলে মনে করে, অন্যথায় নির্দিষ্ট না করা পর্যন্ত ... যা একটি আকর্ষণীয় আচরণ, অন্তত বলতে গেলে।

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

• জাভাস্ক্রিপ্ট আধা-কোলন সন্নিবেশ
• সি (নীরব) অন্তর্নির্মিত রূপান্তর (এটি যদি কেটে না যায় তবে এটি এত খারাপ হবে না ...)

এবং "স্মার্ট" আচরণ বাস্তবায়নে সহায়তা করার জন্য সরঞ্জামগুলি রয়েছে:

• নাম মেলে ফোনেটিক অ্যালগরিদম ( ডাবল মেটাফোন )
• স্ট্রিং দূরত্ব অ্যালগরিদম ( লেভেনস্টেইন দূরত্ব )

তবে আমি দেখতে পেয়েছি যে প্রযুক্তিবিহীন ব্যবহারকারীর সাথে কথা বলার ক্ষেত্রে বা ত্রুটি পুনরুদ্ধারের প্রক্রিয়াতে ব্যবহারকারীদের সহায়তা করার ক্ষেত্রে এটি কার্যকর হতে পারে, যখন গ্রন্থাগার / শ্রেণি ইন্টারফেসের নকশার ক্ষেত্রে প্রয়োগ হয় তখন কিছুটা ত্রুটি রয়েছে:

• এটি অ্যালগরিদম "সঠিক" অনুমান করে কিনা কিছুটা বিষয়গত হয় এবং সুতরাং এটি সর্বনিম্ন বিস্ময়ের নীতিবিরোধী হতে পারে
• এটি বাস্তবায়ন আরও কঠিন করে তোলে, এভাবে বাগ প্রবর্তনের আরও সম্ভাবনা রয়েছে ( YAGNI লঙ্ঘন ?)
• আচরণটি পরিবর্তনের জন্য আরও সংবেদনশীল করে তোলে, কারণ "অনুমান" রুটিনের কোনও পরিবর্তন পুরানো প্রোগ্রামগুলি ভেঙে দিতে পারে, প্রায় রিফ্যাক্টরিং সম্ভাবনাগুলি বাদ দিয়ে ... শুরু থেকেই!

এবং এটিই আমাকে নিম্নলিখিত প্রশ্নের দিকে নিয়ে গেল:

একটি ইন্টারফেস ডিজাইন করার সময় (গ্রন্থাগার, শ্রেণি, বার্তা), আপনি দৃ principle়তার নীতিটির দিকে ঝুঁকছেন কিনা?

আমি নিজেই আমার ইন্টারফেসগুলিতে বিস্তৃত ইনপুট বৈধতা ব্যবহার করে বেশ কঠোর হতে থাকি এবং আমি ভাবছিলাম যে আমি সম্ভবত খুব কঠোর কিনা।

Comments

আমি ভাবছি এইচটিএমএল এবং সাধারণ তথ্যগুলির মধ্যে পার্থক্য কী? দৃust়তা নীতি যোগাযোগ সম্পর্কে হয়। একজন লিখেছেন - একজন পড়েন। নেটওয়ার্ক যোগাযোগ ভিজ্যুয়াল বা এপিআইর চেয়ে আলাদা কেন? আমার একটি এপিআই উদাহরণ রয়েছে যেখানে আমরা যা গ্রহণ করি তাতে উদার হওয়ার নীতিটি প্রোগ্রামারগণের ব্যবহারকারীর জীবনকে সহজতর করে , কোডের আকার হ্রাস করে এবং অতএব, পারফরমেন্সগুলি উন্নত করে + বাগগুলি সরিয়ে দেয়। লুক stackoverflow.com/questions/18576849

— Val,

@ ভ্যাল: আসলে আপনার উদাহরণ মেলে না। "আপনি যা গ্রহণ করেন তাতে উদার হওয়া" কেবল ভিত্তি / উত্পন্ন বিষয় নয়, এটি এর বাইরেও চলেছে এবং কিছুটা ভ্রান্ত ইনপুট গ্রহণ করে (এবং ব্যাখ্যাও করছে)।

— ম্যাথিউ এম।

কিভাবে কিছু কেস দেখানো সেই মামলাটি দেখায় না?

— Val,

Answer 1

আমি দৃ say ়তা বলব যখন এটি অস্পষ্টতার পরিচয় দেয় না ।

উদাহরণস্বরূপ: কমা দ্বারা বিচ্ছিন্ন তালিকার বিশ্লেষণ করার সময়, কমা এর আগে / পরে কোনও স্থান নেই কিনা তা কমেটার অর্থটি পরিবর্তন করে না।

স্ট্রিং গাইডের বিশ্লেষণ করার সময় এটি কোনও প্রচলিত বিন্যাস (ড্যাশ সহ বা ছাড়া, কোঁকড়া ধনুর্বন্ধনী সহ or

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

আমি অবশ্যই একমত যে যদি কোনও কিছুর একাধিক উপায়ে ব্যাখ্যা করা যায় বা এটি যদি 100% স্পষ্ট না হয় তবে খুব বেশি দৃust়তা যদিও ব্যথার কারণ হতে পারে তবে অস্পষ্ট না হয়ে দৃ rob়তার অনেক সুযোগ রয়েছে।

Comments

আমি সম্মতি জানাই, দৃust়তা যখন এর জন্য খুব বেশি খরচ হয় না তা মূল্যহীন।

— ম্যাথিউ এম।

এমনকি কমা দ্বারা পৃথকীকৃত তালিকা সমস্যার কারণ ঘটায়, এ জাতীয়: ক্রোম এবং ফায়ারফক্সের জাভাস্ক্রিপ্ট ইঞ্জিনটি {"key": "value",}বৈধ হিসাবে গ্রহণযোগ্য বলে মনে হচ্ছে , আইআই তা গ্রহণ করে না। আমি জেএসলিন্টের সাথে আমার বিল্ড প্রক্রিয়াটির উন্নতি না করা পর্যন্ত আমি প্রায়শই এই বিশেষ সমস্যাটিকে ডেকে আছি।

— কেপলা

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

— ডেভি 8

@ Davy8: ট্রেলিং কমা অবৈধ (হবে বলে মনে হচ্ছে stackoverflow.com/questions/5139205/... )। আমি এটির উপর নির্ভর করতে চাই না, আমার বক্তব্যটি হ'ল পর্যাপ্ত লোকেরা যখন ইনপুট গ্রহণ করে, তখন এটি ডি-ফ্যাক্টো স্ট্যান্ডার্ড হয়ে যায় (কারণ এটি কোনও ত্রুটি হিসাবে লক্ষ্য করে না), যা আমাদের এইচটিএমএল-এ এসেছিল এমন কিছু দিকে নিয়ে যায়: যে ত্রুটিগুলি এত সাধারণ হয়ে উঠুন যে আপনি এগুলিকে খারাপ ইনপুট হিসাবে উপেক্ষা করতে পারবেন না।

— কেপলা

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

— এরিক রেপেন

Answer 2

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

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

Answer 3

দৃ Rob়তার ওভার্যাপ্লিকেশন আপনাকে অনুমান করতে পারে যে ব্যবহারকারী কী চেয়েছিলেন, যা আপনি ভুল না হওয়া অবধি ঠিক আছে। এটির জন্য সম্পূর্ণরূপে বিভ্রান্ত বিশ্বাসেরও প্রয়োজন যে আপনার গ্রাহকরা আপনার বিশ্বাসকে অপব্যবহার করবে না এবং এলোমেলো গীব্রিশ তৈরি করবে না যা ঠিক কাজ করার জন্য ঘটে তবে আপনি সংস্করণ 2-এ সমর্থন করতে সক্ষম হবেন না।

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

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

Comments

জন্য +1 থামিয়ে দেওয়া , এটা প্রকৃতপক্ষে একটি গুরুত্বপূর্ণ ধারণা এবং আমি অবাক হলাম এটা এখন পর্যন্ত উপেক্ষিত হয়েছিল।

— ম্যাথিউ এম।

Answer 4

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

ব্রাউজারটি কভারগুলির নীচে এটি ঠিক করার চেষ্টা করার পরিবর্তে কেবল একটি ত্রুটি বার্তা প্রদর্শন করা উচিত। এটি সমস্ত বাঙ্গালারকে তাদের জগাখিচুড়ি ঠিক করতে বাধ্য করেছিল।

Comments

নিজেকে উদ্ধৃত করে (অবশ্যই বৃদ্ধ হতে হবে): "তবে আমি সবসময়ই ভেবেছি যে এইচটিএমএল / সিএসএসের প্রয়োগ এটি সম্পূর্ণ ব্যর্থতা"

— ম্যাথিউ এম।

সত্য, তবে খুব একই ত্রুটি সহনশীলতাও ওয়েবকে এত জনপ্রিয় করতে সহায়তা করেছিল।

— এমআর

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

— এরিক রেপেন

আপনি বলছেন যে ব্যর্থ-দ্রুত, যা "শক্ত" এর বিপরীতে রয়েছে আরও দক্ষ।

— Val,

@ মার: তাই নাকি? খুব বিতর্কিত, সম্ভবত বৈশিষ্ট্যগুলি গুরুত্বপূর্ণ ছিল।

— উত্সাহক

Answer 5

আমি ইন্টারফেসগুলি কয়েকটি গ্রুপে বিভক্ত করি (যদি আপনি চান তবে আরও যোগ করুন):

1. আপনার নিয়ন্ত্রণে থাকাগুলি কঠোর হওয়া উচিত (সাধারণত ক্লাস)
2. লাইব্রেরির এপিআইগুলি, এটি কঠোর পক্ষে থাকা উচিত, তবে অতিরিক্ত বৈধতা দেওয়ার পরামর্শ দেওয়া হয়
3. সর্বজনীন ইন্টারফেস যা অবশ্যই আসে প্রতিটি ধরণের অপব্যবহারকে হ্যান্ডেল করতে হবে (সাধারণত প্রোটোকল, ব্যবহারকারীর ইনপুট ইত্যাদি)। এখানে ইনপুটটিতে দৃust়তা অর্থাত্ প্রতিদান দেয়, আপনি আশা করতে পারবেন না যে প্রত্যেকে তাদের স্টাফগুলি ঠিক করবে। এবং ব্যবহারকারীর জন্য মনে রাখবেন অ্যাপ্লিকেশনটি যদি কাজ না করে তবে এটি আপনার দোষ হবে, যে পক্ষটি কিছু খারাপ-ফর্ম্যাটে ছাঁটাই পাঠিয়েছে not

আউটপুট সর্বদা কঠোর হতে হবে।

Answer 6

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

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

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

Comments

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

— ম্যাথিউ এম।

আমি প্রকৃতপক্ষে মনে করি IE টিম সমস্ত ব্রাউজার বিকাশকারীদের মধ্যে সবচেয়ে খারাপ অবস্থানে রয়েছে। জোয়েল আমার চিন্তাভাবনাগুলি বেশ সুন্দরভাবে জাগিয়ে তুলেছে ।

— ডিন হার্ডিং

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

— FinnNk

এছাড়াও, যদিও দৃ Rob়তা নীতি ওয়েব বিকাশকারীদের পক্ষে জীবনকে শক্ত করে তুলতে পারে, তবে ওয়ার্ল্ড ওয়াইড ওয়েবকে (বর্তমানে গ্রহের প্রায় প্রতিটি বড় প্রতিষ্ঠানের একটি অবিচ্ছেদ্য অঙ্গ) একটি বিশাল ব্যর্থতা বলা শক্ত ।

— ডিফোর্ড

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

— ডিফোরে

Answer 7

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

তবে আপনি যদি কোনও লাইব্রেরি লিখছেন তবে আপনার সম্ভবত একাধিক পক্ষের পারস্পরিক বেমানান উপায়ে একটি সাধারণ মান ব্যাখ্যা করার সমস্যা নেই। সেক্ষেত্রে আমি বলব আপনি যা গ্রহণ করবেন তাতে কঠোর হোন, কারণ এটি অস্পষ্টতা দূর করে।

জারগন ফাইলটিতে একটি ব্যবহারকারীর অভিপ্রায় "অনুমান" করার বিষয়ে একটি হরর গল্প রয়েছে।

Comments

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

— ম্যাথিউ এম।

আসলে, যদি আপনার ফোনটি অন্যান্য বেশিরভাগ ফোনের সাথে কাজ না করে তবে আপনার ফোনটি খারাপ ।

— সাম্ব

@ স্যামবি: ভাঙ্গা দিয়ে খারাপ প্রতিস্থাপন করুন ।

— ডিফোর্ড

Answer 8

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

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

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

Comments

"আপনি প্রোগ্রামিংয়ের সময় যদি কোনও টাইপ তৈরি করেন, আপনি সংকলন করার সাথে সাথেই একটি ত্রুটি পাবেন" আমি আপনাকে লক্ষ লক্ষ সংকলক সতর্কতার সাথে উল্লেখ করছি যে একটি স্ট্যান্ডার্ড সংকলক থুতু ফেলবে, এখনও পুরোপুরি সম্পাদনযোগ্য টাস্কগুলি তৈরি করার সময়।

— defere

Answer 9

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

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

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

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

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

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

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

Comments

"20 টি আর্গুমেন্ট গ্রহণকারী কোনও পদ্ধতির জন্য"> আরও তাকাতে হবে না, 5/6 পরে পদ্ধতিটি ভুল । যদিও উত্তরের জন্য ধন্যবাদ :)

— ম্যাথিউ এম।

Answer 10

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

তদ্ব্যতীত, যেমন ইতিমধ্যে চিহ্নিত করা হয়েছে, এটি ব্যবহারকারী কতটা প্রত্যাশা করেছিল তা অনুমান করা আসলে কতটা শক্ত তা নির্ভর করে। যদি এটি খুব সহজ হয় তবে আপনার দুটি মামলা রয়েছে:

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

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

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

আমি আপনাকে অনুরূপ একটি মামলার আমার এই প্রশ্নটি পড়ার পরামর্শ দিচ্ছি ।