পরিচিত বাগ সহ কোনও পণ্য পাঠানো কখন ঠিক হবে?

Question

পরিচিত বাগ সহ কোনও পণ্য পাঠানো কখন ঠিক হবে?

Comments

প্রশ্নটি সম্ভবত খুব বিস্তৃত। কারণগুলি অসীম।

— জেএমকিউ

প্রশ্নটি হ'ল: বাগ সহ শিপ করুন বা শিপ করা মোটেও নয় :)

— ভিজিটর পাই

সমস্ত পণ্য বাগ সহ প্রেরণ করে।

— জোয়েল ইথারটন

বিগিকে সংজ্ঞায়িত করুন। আমরা সম্প্রতি এমন একটি পণ্য প্রেরণ করেছি যা ইনস্টল করতে পারে না। দুর্দান্ত বাগ: ডি

— বারফিল্ডমভি

আপনার অর্থ কি 'জানা বাগ'?

— কেউ 15

Answer 1

আমি ধরে নিয়েছি আপনি একটি "জ্ঞাত" বাগের কথা বলছেন (অন্যথায় প্রশ্নটি অর্থহীন)। ঠিক আছে, উত্তর এই কারণগুলির উপর নির্ভর করে:

1) ব্যবহারকারী কে এবং কীভাবে সে / তারা বাগটি পাওয়া যায় তা গ্রহণ করবে?

2) বাগের সম্ভাব্য প্রভাব (ক্ষতি) কী?

3) বাগটি ঠিক করার জন্য সফ্টওয়্যারটির চালানের ক্ষেত্রে বিলম্ব করা কি সম্ভব?

৪) সর্বাধিক গুরুত্বপূর্ণ: আপনি আপনার সফ্টওয়্যার থেকে কী আশা করবেন? বাজার করার সময়? মান কেমন? আপনি কি দেখতে চান যে আপনার গ্রাহকরা বাগটি খুঁজে পেতে সফটওয়্যারটি যথেষ্ট দীর্ঘ ব্যবহার করেন?

Answer 2

এটি সর্বদা ঠিক থাকতে হবে, কারণ বুগলেস সফটওয়্যার বলে কোনও জিনিস নেই।

Comments

তবে মনে হচ্ছে তিনি বাগটি সম্পর্কে অবগত আছেন ... সুতরাং সেই মুহুর্তে মনে হবে যে কোনও প্রোগ্রামার সচেতন হওয়ার কারণে এটি ঠিক না করার জন্য অলস হয়ে উঠছেন ...

— কেনেথ

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

— ম্যাট এলেন

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

— কেনেথ

সম্ভবত আমার কটূক্তি পরিষ্কার ছিল না ... তবে এটি যে বগি সফ্টওয়্যারটি জাহাজে পাঠানো "সর্বদাই ঠিক" তা দায়বদ্ধ হওয়ার মতো। এটি "যেমন পৃথিবীতে সর্বদা খুনি থাকবেন, তাই বলার মতো, তাই আমি গিয়ে কয়েকজনকে মেরে ফেললে কিছু যায় আসে না"।

— অসন্তুষ্ট গোট

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

— কোডেক্সআর্কানিয়াম

Answer 3

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

সুতরাং এটি ব্যয় / উপকারের দৃষ্টিকোণ থেকে দেখুন।

আপনি বাগগুলি নির্ধারণের মোট ব্যয় এবং ঝুঁকিটি বাগের বাইরে যাওয়ার কারণে যে কোনও সমস্যা এবং নেতিবাচক প্রভাব দেখা দিতে পারে তার চেয়ে বেশি হলে আপনি পরিচিত বাগগুলি সহ পণ্যগুলি পাঠান।

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

ঝুঁকির মধ্যে রয়েছে কেবলমাত্র বাগ সংশোধন করার ক্ষেত্রেই নয়, একটি নতুন ইনস্টলেশন তৈরির ফলে উদ্ভব হতে পারে এমন বিষয়গুলির মধ্যেও একটি নতুন সমস্যা প্রবর্তনের ঝুঁকি রয়েছে।

নেতিবাচক প্রভাব হ'ল গ্রাহকদের সাথে বাগের প্রতিবেদন করার সময় এবং প্রচেষ্টা এবং খ্যাতির ক্ষতির মতো জিনিস।

Comments

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

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

— গ্লেনাস্ট্রন

প্রকৃতপক্ষে, আপনার ইউআইতে টাইপসগুলি একটি পণ্যের মানের প্রতি বিশ্বাসকে ছিন্নবিচ্ছিন্ন করে দেয় (ভুলভাবে, অনেক দুর্দান্ত প্রোগ্রামাররা কেবল ভাল ইংরেজি বলতে পারে না) তবে আমি আপনার বক্তব্যটি দেখি - তুচ্ছ বাগগুলি যা সত্যিকারের ক্ষতি করতে পারে না এবং সম্ভবত কখনই আসবে না won't আপ একটি রিলিজ পিছনে রাখা ঝামেলা মূল্যহীন। 1.01 এ এটি বুলেট পয়েন্টের জন্য রেখে দিন।

— ফোশি

আপনার অ্যাপ্লিকেশনটিতে বানান ত্রুটিগুলি যেন না ঘটে। বেশ স্পষ্টভাবে আমি তাদের দ্বারা আরও বিব্রত তখন একটি প্রকৃত বাগ।

— কেওসপ্যান্ডিয়ন

আপনি কী সম্পর্কে কথা বলছেন তা আমার কোনও ধারণা নেই ...;)

— আন্দ্রেয়াস জোহানসন

Answer 4

বাগ বিভিন্ন তীব্রতায় আসে। যে সফ্টওয়্যার সংস্থাগুলিতে আমি কাজ করেছি তাতে আমরা P0 থেকে P4 তে অগ্রাধিকারের ভিত্তিতে বাগগুলি শ্রেণীবদ্ধ করেছি।

P0- এ কি সফটওয়্যারটি কাজ করে না / ক্র্যাশ হয় এবং গ্রাহকদের ব্যবসায়ের ক্ষতি করতে পারে। পি 1 এটি নকশাযুক্ত হিসাবে কাজ করছে না এবং মূল কার্যকারিতাটিতে ধারাবাহিকভাবে ক্র্যাশ হয় P2 এটি মাঝে মধ্যে ক্র্যাশ হয় এবং বা পার্শ্ব কার্যকারিতাটির কোনও অংশটি কাজ নাও করতে পারে। পি 3 সফ্টওয়্যারটির কিছু উপাদান নকশা করা / প্রত্যাশিত পি 4 কসমেটিক সমস্যা হিসাবে কাজ করছে না।

আমি যে জায়গাগুলিতে পি 4 কেবল ঠিক হয়ে উঠছে না সেগুলিতে কাজ করেছি কারণ সফ্টওয়্যারটিতে এগুলির একটি ছোট প্রভাব রয়েছে।

আমি বলব যে যদি আপনার সফ্টওয়্যারটি পি 3 / পি 4 সমস্যাগুলি জেনে থাকে তবে শিপিং করা ঠিক আছে, আমি এটি প্রকাশের নোটগুলিতে রেখেছি এবং নোট করুন যে সেগুলি নিয়ে কাজ করা হচ্ছে।

আমি কখনই কোনও P0, P1 বা P2 ইস্যু নিয়ে সফটওয়্যার প্রকাশ করিনি।

Answer 5

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

Answer 6

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

Answer 7

যখন এটি একটি "বৈশিষ্ট্য"! ;)

---

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

অতএব, বাস্তববাদী হোন, আপনার পরীক্ষার মুখোমুখি সমস্ত কিছু যদি স্থির হয়ে থাকে, তবে অতিরিক্ত কিছু প্রয়োজনীয় ভিত্তিতে স্থির করা উচিত।

Answer 8

যতক্ষণ আপনি আপনার গ্রাহকদের প্রতি সৎ হন আপনি ততক্ষণে বাগ সহ প্রেরণ করতে পারবেন। সমস্ত বিদ্যমান বাগ সম্পর্কে তাদের জানানো তাদের দেখায় যে আপনার সফ্টওয়্যার সম্পর্কে আপনার ভাল জ্ঞান রয়েছে এবং এটি অবশ্যই ভালভাবে পরীক্ষিত (যদি তা হয় ..)। :)

স্পষ্টতই সবচেয়ে ভাল জিনিসটি বাগ সহ শিপিং এড়ানো।

Answer 9

একেবারে শিপিং না করেই জ্ঞাত সমস্যার একটি তালিকা সহ সময়মতো পণ্য জাহাজ রাখাই ভাল।

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

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

Answer 10

আমি বলব যে থাম্বের একটি ভাল নিয়ম হ'ল "এই বাগটি কি শোস্টোপার?"

বাগটি যদি "হ্যাপি-প্যাথ দৃশ্যাবলী" ব্যর্থ হওয়ার কারণ হয়ে থাকে, তবে অবশ্যই সেই বাগটি দিয়ে প্রেরণ করবেন না।

বাগটি যদি "ট্যানজেন্ট-টু-দ্য হ্যাপি-পাথ দৃশ্যের" ব্যর্থ হয় এবং কোনও কার্যকারিতা নেই, তবে সেই বাগটি দিয়ে জাহাজটি রাখবেন না।

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

Answer 11

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

Answer 12

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

Answer 13

এফএমইএ (ব্যর্থতা মোড এবং এফেক্টস অ্যানালাইসিস) নামক কিছু রয়েছে যা জানা বাগ কখন গুরুত্বপূর্ণ বা এর ভিত্তিতে না হয় তা স্থির করে নেওয়া খুব কার্যকর:

1. ঘটা
2. নির্দয়তা
3. সনাক্তকরণ

Answer 14

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

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

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