বাগগুলি ঠিক করার ক্ষেত্রে কি প্রান্তিক সুবিধা রয়েছে [বন্ধ]


27

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

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

বাগ সংশোধন করার ক্ষেত্রে কি সত্যিই প্রান্তিক সুবিধা রয়েছে? এই ধারণাটি ব্যাখ্যা করে এমন কোনও আলাদা শব্দ রয়েছে?



2
আপনার প্রশ্নটি বেশ অস্পষ্ট। মানে আছে "সমস্ত বাগ সংশোধন করা প্রয়োজন হয়" কিছু যা মূল্য সংশোধন করা হয় না। "বাগ সংশোধন করার ক্ষেত্রে কি আসলেই প্রান্তিক সুবিধা আছে" শোনায় আপনি কিছু আলাদা বোঝাতে চাইছেন। আপনি দয়া করে ব্যাখ্যা করতে পারেন?
ডক ব্রাউন

2
এটি কি পণ্য মালিকের পক্ষে বের করার জন্য নয়? আপনি তাদের কেন এটি সম্পর্কে বোঝানোর প্রয়োজন মনে করেন?
মনিকার ক্ষতি করা বন্ধ করুন

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

2
@ গুখনকুর্ট: "সমস্ত বাগগুলি সংশোধন করা দরকার" থেকে এগুলি অনুসরণ করা হয় না যে এগুলি সবই সমান গুরুত্বপূর্ণ। কিছু অন্যের চেয়ে বেশি বিঘ্নিত হতে পারে এবং এর জন্য উচ্চতর অগ্রাধিকার থাকতে পারে।
জ্যাকবিবি

উত্তর:


66

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

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

অগ্রাধিকার দেওয়ার সময় এই সমস্ত বিষয়গুলি বিবেচনায় নেওয়া উচিত।

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


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

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

3
আমি যুক্ত করব যে কোনও ত্রুটি প্রোগ্রামের চিত্রের উপরও বড় প্রভাব ফেলতে পারে (এবং সামগ্রিকভাবে পণ্যটির উপর এবং এটি যে সংস্থাগুলি উত্পাদন করেছিল) ... এটি বিবেচনায় নেওয়া উচিত: এক কি চায় একটি বাগ ছেড়ে দিলে, যদি পাওয়া যায়, সংস্থাকে কিছু ক্লায়েন্ট এবং / অথবা ব্যবসায় ব্যয় করতে পারে?
অলিভিয়ার ডুলাক

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

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

12

এখানে একটি ভাল রেফারেন্স

http://www.joelonsoftware.com/articles/fog0000000043.html

নতুন কোড লেখার আগে আপনি কি বাগগুলি ঠিক করেন? উইন্ডোজের জন্য মাইক্রোসফ্ট ওয়ার্ডের প্রথম সংস্করণটিকে একটি "ডেথ মার্চ" প্রকল্প হিসাবে বিবেচনা করা হয়েছিল। [...] কারণ বাগ ফিক্সিং পর্বটি আনুষ্ঠানিক তফসিলের অংশ ছিল না [...]

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

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

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


3

এই ধারণাটি সম্পর্কে আমাদের পণ্য মালিককে বোঝানোর প্রয়াসে আমি কোনও ভাল সংস্থান খুঁজে পাইনি।

ধরে নিই যে আপনি একটি বাণিজ্যিক প্রতিষ্ঠানের হয়ে কাজ করছেন, অবশ্যই সেখানে কেউ আছেন যিনি কস্ট-বেনিফিট বিশ্লেষণ সম্পর্কে অবগত আছেন ।

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

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

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

সফটওয়্যার ইঞ্জিনিয়ারিং এ এই দুটি পোস্ট দেখুন:

কোন বাগগুলি সমাধান করা সর্বাধিক ব্যয়ের সুবিধা দেয়

প্রায় প্রতিবেদন করা বাগটি উচ্চ-অগ্রাধিকারের বাগ


2

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

উপরের মতো পরিস্থিতিতে, কার্যক্ষম দুটি যুক্তিসঙ্গত কোর্স থাকবে:

  1. সমস্যাটি সমাধান করুন, যদি তা করা হয় তবে ব্যবহারিক।

  2. প্রোগ্রামের আউটপুটটি নির্ভরযোগ্য হবে এমন ব্যাপ্তিগুলি নির্দিষ্ট করুন এবং উল্লেখ করুন যে প্রোগ্রামটি কেবলমাত্র ডেটা ব্যবহারের জন্য উপযুক্ত যা বৈধ ব্যাপ্তির মধ্যে মান উত্পাদন করতে পারে।

# 1 পদ্ধতির ফলে বাগটি দূর হবে। অ্যাপ্রোচ # 2 অগ্রগতিটি অন্যথায় হতে পারে এমন কিছু উদ্দেশ্যে কম উপযোগী করে তুলতে পারে, তবে যদি সমস্যাযুক্ত মানগুলি পরিচালনা করার জন্য প্রোগ্রামগুলির প্রয়োজন না হয় যা সমস্যা নাও হতে পারে।

এমনকি যদি 99.95 থেকে 100.0 মান সঠিকভাবে পরিচালনা করতে অক্ষমতা কোনও প্রোগ্রামিং ভুলের ফলস্বরূপ [যেমন দশমিক পয়েন্টের বামে দুটি অঙ্কের আউটপুট স্থির করার পরে এক জায়গায় গোল করার আগে সিদ্ধান্ত নেওয়া হয়] তবে এটি কেবল একটি বিবেচনা করা উচিত প্রোগ্রামটি অন্যথায় এই জাতীয় ক্ষেত্রে অর্থপূর্ণ আউটপুট উত্পাদন হিসাবে নির্দিষ্ট করা হবে যদি বাগ। [প্রসঙ্গত, টার্বো সি ২.০০ প্রিন্টফ কোডে পূর্বোক্ত সমস্যাটি দেখা দিয়েছে; সেই প্রসঙ্গে, এটি স্পষ্টত একটি বাগ, তবে যে কোডটি ত্রুটিযুক্ত প্রিন্টফকে ডাকে শুধুমাত্র এটি বগী হবে যদি এটি সমস্যাযুক্ত পরিসরে আউটপুট তৈরি করতে পারে]।


0

আলগা অর্থে, হ্যাঁ, সমস্ত বাগ সংশোধন করার দরকার নেই। ঝুঁকি / বেনিফিট অনুপাত বিশ্লেষণ সম্পর্কে এগুলিই।

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

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

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

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

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


-4

কারণ আপনি বাগগুলির অগ্রাধিকার তালিকায় যাওয়ার সাথে সাথে ব্যবহারের ক্ষেত্রে ত্রুটি আরও বেশি অস্পষ্ট হয়ে যায় বা গ্রাহকের তৃপ্তি কম হয়।

সুতরাং তাদের "যুক্তি" আসলে

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

বাগ অগ্রাধিকারের এবং "অনুক্রমে" সঙ্গে মোকাবিলা করতে হবে ঠিক নতুন বৈশিষ্ট্য অনুরোধ (কিন্তু তর্কসাপেক্ষে, ওভার এবং উপরোক্ত সব পরেরটির)।


3
না, তার যুক্তিটি হ'ল নিম্ন-অগ্রাধিকারের বাগগুলি খুব কমই ঘটতে পারে এবং সংশোধন করার ক্ষেত্রে সত্যিকার অর্থে খুব বেশি মূল্য যোগ করতে পারে না (যেমন, আপনার ওয়েবসাইটে যদি আপনার একটি ঘড়ি থাকে যা আধ মিনিটের বাইরে থাকে, বা আপনি ওয়েবসাইট হন তবে জানুয়ারীর মধ্যরাতে ত্রুটিগুলি
নামটি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.