বাগফিক্সিং কখন ওভারকিল হয়ে যায়, যদি কখনও হয়?


128

ভাবুন আপনি জাভাস্ক্রিপ্টে একটি ভিডিও প্লেয়ার তৈরি করছেন। এই ভিডিও প্লেয়ারটি পুনরাবৃত্তি ফাংশনটি ব্যবহার করে ব্যবহারকারীর ভিডিও বারবার লুপ করে এবং এর কারণে ব্রাউজারটি কোনও too much recursion RangeErrorসময়ে ট্রিগার করবে ।

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

  • বাগ ঠিক করুন

  • বাগ ছেড়ে দিন

লোকেরা কেবল হোঁচট খাবে এমন কি আপনার কি ঠিক করা উচিত নয়? বাগফিক্সিং কখন ওভারকিল হয়ে যায়, যদি তা কখনও হয়?

সম্পাদনা করুন:

যদি আসল বাগের কারণ না ঘটানো পুনরাবৃত্তির পদ্ধতির জন্য আপনার উদ্বেগ হয় তবে মনে করুন যে প্রতিবারের জন্য প্লেয়ার কোনও ভিডিও লুপ করেন তবে একটি পরিবর্তনশীল দ্বারা বর্ধিত হয় 1। 2 53 লুপের পরে এই পরিবর্তনশীলটি উপচে পড়বে এবং কোনও প্রোগ্রাম ব্যতিক্রম ছড়িয়ে দিয়ে আপনার প্রোগ্রামটি এটি পরিচালনা করতে সক্ষম হবে না।


95
আমার উদাহরণস্বরূপ দৃশ্যের সাথীর সাথে
গণ্ডগোল

15
@ প্লাজমাএইচএইচ আমি আমার প্রশ্নটি ব্যাখ্যা করার জন্য এই হাইপোটিক্যাল দৃশ্যটি ব্যবহার করছি। বাগটি উপস্থিত থাকলে বা তা কিছুতেই আসে যায় না
টিয়াগো মেরিনহো

13
@ টিয়াগোমারিনহো: আমি যে বিষয়টি তৈরির চেষ্টা করছি তা হ'ল: কখনও কখনও পরিস্থিতিটিকে অভ্যাসগত আচরণ হিসাবে সংজ্ঞায়িত করা ঠিক কাজ।
প্লাজমাএইচ

23
পৃথিবীতে আপনি কেন প্রথম স্থানটিতে পুনরাবৃত্তি ব্যবহার করে এই ধরনের লুপ চালাবেন? আপনি সম্ভবত বাগটি ঠিক করতে চাইছেন না, তবে আপনার অবশ্যই নিজের নকশা প্রক্রিয়াটি পুনর্বিবেচনা করা উচিত :-)
jamesqf

28
এটি আরও একটি ব্যবসায়ের প্রশ্নের মতো মনে হচ্ছে। আপনাকে ব্যয়-থেকে-ঠিক করতে এবং বাগের প্রভাব / ফ্রিকোয়েন্সি ভিত্তিতে অগ্রাধিকার দিতে হবে।
কেসি কুবল

উত্তর:


164

আপনি ব্যবহারিক হতে হবে।

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

এটি বলেছিল, আপনার এই সমস্যাটিকে "শেখার অভিজ্ঞতা" হিসাবে ব্যবহার করা উচিত এবং পরের বার আপনি যখন লুপিং করবেন তখন অপ্রয়োজনীয়ভাবে পুনরাবৃত্ত লুপ ব্যবহার করবেন না।

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


119
সম্পূর্ণরূপে "আপনি অবাক হবেন যে ব্যবহারকারীরা সীমানার বিরুদ্ধে লড়াই করতে এবং ত্রুটিগুলি উদঘাটন করতে গিয়ে কতটা অবাক হন" এর সাথে সম্পূর্ণ সম্মত হন "
স্পটড

74
অন্তিম ব্যবহারকারীদের কোন উপায় কি দ্বারা সীমিত হয় আপনি মনে করেন যে আপনার সফ্টওয়্যার একটি যুক্তিসঙ্গত ব্যবহার। এমন ব্যবহারকারীরা আছেন যারা চিরতরে ভিডিও লুপ করতে চান । এটি এমন একটি বৈশিষ্ট্য যা আপনার সফ্টওয়্যার সরবরাহ করে, তাই তারা এটি ব্যবহার করবে।
gnasher729

36
@ gnasher729 ইউটিউবে "10-ঘন্টা এক্সএক্সএক্সএক্স" ভিডিওগুলি একটি ভাল শনাক্তকারী যে সত্যই, কিছু লোক চিরতরে কিছু লুপ করতে চায়।
ক্রিস সাইরেফাইস

23
অন্য সমস্যা: যদি আপনার সফ্টওয়্যারটি জনপ্রিয় হয়, তবে কেউ একটি বাগের মুখোমুখি হয় যা সত্যিই কেবল বিরল পরিস্থিতিতে ঘটে থাকে, ইন্টারনেটে পোস্ট করে, এবং হঠাৎ সবাই এবং তাদের কুকুর বলে "এই সফ্টওয়্যারটি আবর্জনা, এটি ক্র্যাশ করে যদি আমি কোনও ভিডিও লুপ করি তবে এক দিন". বা কোনও প্রতিযোগী এটি প্রয়োগ করে যাতে আপনার অ্যাপ্লিকেশনটি ক্রাশ করা কতটা সহজ।
gnasher729

4
শেষ অনুচ্ছেদে জোর দেওয়া। আপনি কি জানেন যে ম্যাকোস ক্লাসিকটি ক্রমাগত ক্রস হবে যদি কোনও হস্তক্ষেপ না করা "মাউস রিলিজ" ইভেন্ট ছাড়াই টানা 32,768 টি "মাউস প্রেস" ইভেন্টগুলি পান?
চিহ্নিত করুন

79

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

আপনাকে যা করতে হবে তা হ'ল পুরো প্রোগ্রামটির জন্য ঝুঁকি মূল্যায়ন এবং পৃথক বাগগুলির জন্য প্রভাব নির্ধারণ

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

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


2
আমি কিছু ইন্টেল সিপিইউতে (হার্ডওয়্যার) বাগটিও স্মরণ করি যেখানে একটি নির্দিষ্ট ভাসমান পয়েন্টের মানটি ভুল হয়ে যায়।

5
@ উইলিয়ামক্যাপলার এন.উইকিপিডিয়া.আর / উইকি / পেন্টিয়াম_এফডিএল_ব্যাগ হ'ল আমি বিশ্বাস করি আপনি উল্লেখ করছেন। কেউ এক নজরে আসার আগে এক বছর ছিল।
Jeutnarg

10
@ gnasher729 - সত্যই নয়, তারা ইতিমধ্যে নীচে ছিল এবং এখনও খনন করা হয়েছে :) বেশিরভাগ লোককে 49.7 দিনের আইআইআরসি-র তুলনায় উইন 95 পুনরায় ইনস্টল করতে হয়েছিল।
ম্যাকটল

4
@ লুয়ান মন্তব্যটি লক্ষ্য ছিল এম light এ হালকা হৃদয়ের খনন হিসাবে, তাই প্রথম বাক্যটির পরে হাসিখুশি। তারা'৯৯ এর সাথে আটটি পেছনে পড়েছিল কারণ এটি 95 সালে খুব দেরিতে বেরিয়ে আসে (সম্ভবত 1996 সালে উইন 95 মুক্তি পেয়েছিল খারাপ চেহারা হতে পারে), অর্ধ বেকড (ইউএসবি বিএসওডকে মনে আছে?) এবং অস্থির হয়ে উঠার ঝুঁকিতে পড়ে এবং নিয়মিত পুনরায় ইনস্টলগুলির প্রয়োজন হয় অতএব আমার দ্বিতীয় বাক্য - যা উইন্ডোজ 95-এ কোনও সার্ভার চালানোর কথা কখনও উল্লেখ করেনি, আমি জানি না আপনি কোথা থেকে পেয়েছেন (ফ্ল্যাশব্যাকস?)। দ্বিতীয় প্রকাশের সিডি বিষয়গুলির উন্নতি করেছে তবে '95 এর প্রথম প্রকাশটি ছিল একটি ঘোলাটে।
এমকোটেল

5
টিবিএইচ আমি মনে করি এটি "ওয়ার্সশিপের জন্য উইন্ডোজ" ফিয়াস্কো যা আরও বেশি নামী ক্ষতি করেছিল ( আর্কাইভ.ওয়ায়ারড / সায়েন্স / ডিসকভারিজ / নিউজ / ১৯৯৮ / 07/13987 ) এবং এটি এনটি ব্যবহার করছিল। তৎকালীন ইউনিক্স মেশিনগুলি লিনাক্সের (খুব তাড়াতাড়ি) সংস্করণ ব্যবহার করে বহুবর্ষের আপটাইম পরিচালনা করতে পারে। সমস্ত হোম কম্পিউটারগুলি উচ্চ আপটাইম সক্ষম ছিল, যদিও এইভাবে খুব কমই ব্যবহৃত হত। আমি বিবিসি মাইক্রোগুলি অপ্রচলিত হওয়ার এক দশক পরে শিক্ষামূলক প্রদর্শনীতে এমবেডেড দেখেছি।
pjc50

33

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

আপনাকে আপনার অনুমানগুলি চিহ্নিত করতে হবে এবং তারপরে কোণার ক্ষেত্রে এই অনুমানগুলি পরীক্ষা করতে হবে।

আপনার উদাহরণের দিকে তাকালে আমি কয়েকটি অনুমান দেখি:

  • পুনরাবৃত্ত পদ্ধতির অবশেষে ত্রুটির কারণ ঘটবে।
  • কেউ এই ত্রুটিটি দেখতে পাবে না কারণ ভিডিওগুলি স্ট্যাকের সীমাতে পৌঁছাতে খুব বেশি সময় নেয়।

অন্যান্য লোকেরা প্রথম অনুমানটি নিয়ে আলোচনা করেছে, তবে দ্বিতীয় অনুমানটি দেখুন: আমার ভিডিওটি যদি দ্বিতীয় লম্বার একাংশ মাত্র হয়?

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

অজানা অনুমানগুলি বাগের বিশাল উত্স।

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

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

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

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

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


খুব ভাল পয়েন্ট কেভিন। ওপরের নির্বাচিত উত্তরের উপর আমার মন্তব্যটি নোট করুন যা বিশ্লেষণ প্রশ্নে দৃষ্টি নিবদ্ধ করেWhat's the worst thing that could happen?
ওএমওয়াই

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

১. ওপ কখনও বলেনি যে সমস্যাটি ক্রমবর্ধমান স্ট্যাকের কারণে হয়েছিল। এটি পাল্টা রুটিনে (ডিসে -> ডিভি / 0?) ত্রুটিযুক্তভাবে সহজেই হয়ে উঠতে পারে। 2. যদি সমস্যা হয় একটি স্ট্যাক ওভারফ্লো সমস্যা তাহলে এই প্রশ্ন Stackoverflow পোস্ট করা উচিত নয়? <rimshot!> ;-D
Omy

@ ওমি এই মন্তব্যটি কার দিকে পরিচালিত?
কেভিন ওয়ার্কম্যান

13

আমি আপনাকে নীচের কাগজটি পড়ার পরামর্শ দিচ্ছি:

নির্ভরযোগ্যতা এবং এর হুমকি: একটি শ্রমশক্তি

অন্যান্য জিনিসের মধ্যে এটি বিভিন্ন ধরণের ত্রুটিগুলি বর্ণনা করে যা আপনার প্রোগ্রামে ঘটতে পারে। আপনি যা বর্ণনা করেছেন তাকে একটি সুস্পষ্ট ত্রুটি বলা হয় এবং এই গবেষণাপত্রে এটি এভাবে বর্ণিত হয়েছে:

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

এটি বর্ণনা করার পরে, এটি সমস্ত ব্যয়-বেনিফিটের অনুপাতে ফোটে। ব্যয়টিতে তিনটি পরামিতি থাকবে:

  • কতবার ইস্যুটি নিজেকে উপস্থাপন করবে?
  • এর পরিণতি কী হবে?
  • এটি আপনাকে ব্যক্তিগতভাবে কতটা বিরক্ত করে?

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

এটা ব্যক্তিগত না। এটা ব্যবসা।

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


'এটা ব্যক্তিগত না। এটি ব্যবসা 'মাইকের দ্বারা অনুমান করা হয়েছে, ভিটো নয়। (অবাক হবেন যে ব্যবহারকারীরা কীভাবে সীমানাগুলির বিরুদ্ধে চাপ দিচ্ছেন এবং ত্রুটিগুলি
উদঘাটন করতে পারেন

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

11

এই বাগটি কেবল সেই দিন অবধি অনাবৃত থাকে যতক্ষণ না কেউ আপনার প্লেয়ারকে 24/7 কোম্পানির উপস্থাপনা চালিয়ে একটি লবি স্ক্রিনে রাখে। সুতরাং এটি এখনও একটি বাগ।

আপনি কি করবেন এর উত্তর ? প্রকৃতপক্ষে একটি ব্যবসায়ের সিদ্ধান্ত, কোনও ইঞ্জিনিয়ারিং নয়:

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

5

বিশেষত বড় সংস্থাগুলিতে (বা বড় প্রকল্পগুলি) কী করতে হবে তা প্রতিষ্ঠার জন্য খুব ব্যবহারিক উপায় রয়েছে।

ফিক্সিংয়ের ব্যয় যদি ফিক্সটি আনবে তার চেয়ে বেশি হয় তবে বাগটি রাখুন। ভাইরাস যদি ফিক্সটি তার ব্যয়ের চেয়ে বেশি ফিরে আসে তবে বাগটি ঠিক করুন।

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


6
বাগ ফিক্সিংয়ের জন্য ROI মূল্যায়ন করা খুব কমই সহজ - আপনাকে সাধারণত আপনার সিদ্ধান্তের উপর নির্ভর করতে হয়।
পিপীলিকা পি

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

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

5

tl; dr এ কারণেই RESOLVED/WONTFIXএকটি জিনিস। কেবল এটিকে অতিরিক্ত ব্যবহার করবেন না - আপনি যত্নবান না হলে কারিগরি debtণ গতিতে পারে। এটি কি আপনার ডিজাইনের ক্ষেত্রে মৌলিক সমস্যা, ভবিষ্যতে অন্যান্য সমস্যা হওয়ার সম্ভাবনা রয়েছে? তারপরে এটি ঠিক করুন। তা না হলে? এটি অগ্রাধিকার না হওয়া অবধি ছেড়ে দিন (যদি এটি কখনও হয়)।


5

আপনি যে পরিস্থিতিতে বর্ণনা করেছেন তাতে আসলে তিনটি ত্রুটি রয়েছে:

  1. সমস্ত লগ করা ত্রুটিগুলি মূল্যায়নের কোনও প্রক্রিয়ার অভাব (আপনি নিজের টিকিট / ব্যাকলগ / আপনার যে কোনও সিস্টেমে ঠিকঠাক জায়গায় ঠিক আছে?) এটি নির্ধারণ করতে হবে কিনা তা নির্ধারণ করার জন্য। এটি ম্যানেজমেন্টের সিদ্ধান্ত।

  2. আপনার দলে দক্ষতার অভাব যা এর মতো ত্রুটিযুক্ত সমাধানগুলি ব্যবহারের দিকে নিয়ে যায়। ভবিষ্যতের সমস্যা এড়াতে এটিকে সম্বোধন করা জরুরি। (আপনার ভুল থেকে শিখতে শুরু করুন।)

  3. ভিডিওটি দীর্ঘকাল পরে প্রদর্শন করা বন্ধ করতে পারে।

তিনটি ত্রুটির মধ্যে কেবল (3) সমাধানের প্রয়োজন হতে পারে না।


২ য়-অর্ডার সমস্যাগুলি নির্দেশ করার জন্য ধন্যবাদ। প্রচুর লোক কেবল লক্ষণটিই চিকিত্সা করে এবং কারণ আরও লক্ষণ তৈরি করতে চালিত করে।
jaxter

4

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


2

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

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


2

এখানে তিনটি জিনিস রয়েছে:

মূলনীতি

এটি মুদ্রার এক দিক। কতক করার জন্য, আমি মনে করি এটা হল (বা খারাপ বাস্তবায়নের এমনকি যদি তারা "কাজ") ফিক্সিং বাগ পীড়াপীড়ি, এমনকি যদি কেউ এটা ঠাহর হয় ভাল।

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

  • প্রোগ্রামার সবেমাত্র খেয়াল করেনি। ঠিক আছে ... একজন প্রোগ্রামারকে তার কোডটি কীভাবে চালিত হয় সে সম্পর্কে একটি অন্তর্দৃষ্টি বিকাশ করা উচিত। এটি পুনরাবৃত্তি একটি খুব কঠিন ধারণা মত নয়। বাগটি সংশোধন করে (এবং অতিরিক্ত সমস্ত কাজের মাধ্যমে ঘাম ঝরছে), ভবিষ্যতে অতিরিক্ত কাজ এড়াতে যদি তিনি সম্ভবত কিছু শিখেন এবং তা মনে রাখেন। যদি কারণ ছিল যে, তিনি শুধু যথেষ্ট সময় ছিল, ব্যবস্থাপনা শিখতে পারেন যাতে প্রোগ্রামারদের না উচ্চ মানের কোড তৈরি করার জন্য আরো সময় প্রয়োজন।

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

প্রয়োগবাদ

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

দ্রুত ব্যর্থ, হার্ড ব্যর্থ

সন্দেহ হলে দ্রুত ব্যর্থ হোন এবং কঠিন ব্যর্থ হোন।

এর অর্থ, অন্যদের মধ্যে, আপনার কোডটি পরিবেশকে নয়, ত্রুটির শর্তটি লক্ষ্য করে।

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

এইভাবে, আপনার আছে

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

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


2
আমি কতটা শীঘ্রই একটি উত্তর গ্রহণ করেছি সে সম্পর্কে যদি আপনি এভাবে অনুভব করেন তবে আমি দুঃখিত। আমার প্রতিরক্ষামুক্তিতে আমি জানতাম না যে প্রশ্নটির 10,000 টি ভিউ থাকবে এবং এটি গ্রহণের সময় অনেক উত্তর। যাইহোক আমি এখনও সেরা উত্তরের বিষয়ে আমার মন পরিবর্তন করি নি।
টিয়াগো মেরিনহো

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

আমি অদ্ভুত ডাউনভোটিং সম্পর্কে সম্পূর্ণরূপে একমত
টিয়াগো

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

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

1

আমার কর্মক্ষেত্রে সিনিয়র বিকাশকারী ডেস্কে এটি পোস্ট করার পরে বলে

এটি কি কাউকে সাহায্য করে?

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


0

তিনটি বিষয় মাথায় আসে:

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

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

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

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

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


2
আপনি ডাউন ডাউন যখন একটি মন্তব্য করুন। উত্তরটি উন্নত করার জন্য আমাদের সমালোচনা কী তা জানা উচিত।
Alfe

0

কম সম্ভাব্যতা / হালকা পরিণতি = কম প্রাইরিটি ফিক্স

  • যদি অ্যাকুয়ারেন্সের সম্ভাবনা খুব কম থাকে
  • অষ্টম পরিণতি যদি হালকা হয়
  • তার পরে বাগ কোনও হুমকি দেয় না, তবে এটি কোনও অগ্রাধিকারের সমাধান নয়।

তবে এটি অলস বিকাশকারীদের পক্ষে ক্রাচ হয়ে উঠতে পারে না ...

  • "খুব কম সংঘটন" বলতে কী বোঝায়?
  • "হালকা পরিণতি" বলতে কী বোঝায়?

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

বেশিরভাগ বিকাশকারী আশ্চর্য হয়ে যায় যে তারা মূলত যে জিনিসগুলি চেষ্টা করেছিল তা কখনই ঘটবে না, আসলে অনেক কিছু ঘটে

আমাদের শিক্ষাব্যবস্থা সম্ভাবনা এবং যুক্তি খুব ভালভাবে শেখায় না। বেশিরভাগ ব্যক্তি, বেশিরভাগ সফ্টওয়্যার ইঞ্জিনিয়ার সহ একটি ভাঙ্গা যুক্তি এবং ভাঙ্গা সম্ভাবনার স্বীকৃতি রয়েছে। বাস্তব বিশ্বের সমস্যাগুলির অভিজ্ঞতা এবং বিস্তৃত সিমুলেশনগুলির অভিজ্ঞতা হ'ল এটি সমাধান করার জন্য আমি জানি know

বাস্তব বিশ্বের ডেটা দিয়ে আপনার স্বজ্ঞানের মুখোমুখি

ব্যবহারের ধরণগুলি অনুসরণ করতে সক্ষম হতে বেশ কয়েকটি লগ তৈরি করা গুরুত্বপূর্ণ। আপনার মনে হয় যে ঘটবে না সেগুলি সম্পর্কে দৃ of়তার সাথে কোডটি পূরণ করুন। তারা অবাক হয়ে যাবে। এইভাবে আপনি হার্ড তথ্য সহ আপনার স্বজ্ঞাতাকে মোকাবেলা করতে এবং এটি পরিমার্জন করতে সক্ষম হবেন।

আমার হালকা সমস্যা এবং নিয়ন্ত্রণের একটি পরিমাপের উদাহরণ

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

উপসংহার

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


-1

আমি মনে করি এটি প্রথম থেকেই ভুল প্রশ্ন জিজ্ঞাসা করছে।

প্রশ্নটি হ'ল "আমি কি এই ত্রুটিটি ঠিক করব বা এই ত্রুটিটি ঠিক করব না"। যে কোনও বিকাশকারীদের সময় সীমিত থাকে। সুতরাং প্রশ্নটি হল "সবচেয়ে কার্যকর জিনিসটি কী যা আমি এক ঘন্টা, বা চার ঘন্টা বা এক সপ্তাহে করতে পারি"।

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


ইউটিরিটিভ মেট্রিক এখানে সর্বোত্তম কাজ করে তা নিশ্চিত নয়। স্পষ্টতই, ভিডিও প্লেয়ারের উদাহরণটি কম-প্রভাবের জন্য ডিজাইন করা হয়েছিল, তবে এটি নির্বোধ নয়। একজন উত্তরদাতারা ইতিমধ্যে একটি লবি ইউজ কেসে 24/7 প্রোমো লুপটি উদ্ধৃত করেছেন এবং অন্য একজন সপ্তাহে চলে এমন বিক্রয় / প্রযুক্তি সম্মেলনে কিউসক হতে পারে। উভয়ই খ্যাতি এবং / অথবা ব্যবসায়ের জন্য অর্থ ব্যয় করতে পারে তাই অ-তুচ্ছ।
jaxter

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

-2

বাগ ফিক্সিং সর্বদা একটি ওভারকিল

প্রথমে বাগ অংশটি শ্রেণিবদ্ধ করা যাক ।

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

তবে, যদি এটি আপনার নকশার মতো ডিজাইনের ত্রুটি হয় তবে আপনার নকশাটি পুনরায় মূল্যায়ন করা উচিত বা সবচেয়ে খারাপ ক্ষেত্রে এই বৈশিষ্ট্যটি অক্ষম করতে হবে

সুতরাং, দয়া করে এটি ঠিক করার চেষ্টা করবেন না ।

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

পদক্ষেপগুলি সুস্পষ্ট, এখন আপনাকে ভাঙা কোড এবং নতুন লুপ সীমা উভয় সমর্থন করতে হবে।

চরম দেখার জন্য পিএস ক্ষমা চেয়েছেন।

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


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

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

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

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

2
@ ওমি ব্যাখ্যার জন্য আপনাকে ধন্যবাদ। আমি মনে করি যেহেতু "ঠিক" এমন সংজ্ঞা প্রশ্নের ব্যবহৃত হচ্ছে না, তবে উত্তর শব্দ অর্থে সাড়া দেবে হয় ব্যবহার করা হচ্ছে।
doppelgreener
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.