প্রতিটি ত্রুটি নির্ণয় এবং সংশোধন করার আগে পুনরুত্পাদন করাতে জোর দেওয়া কি যুক্তিসঙ্গত?

Question

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

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

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

আমার কাছে, একটি বাস্তব, দৃশ্যমান প্রকাশ (রানটাইম প্রজনন) এর চেয়ে একটি বিমূর্ত ব্লুপ্রিন্ট (প্রোগ্রাম কোড) এর বাইরে কাজ করা কঠিন বলে মনে হচ্ছে, তাই আমি একটি সাধারণ প্রশ্ন জিজ্ঞাসা করতে চেয়েছিলাম:

প্রতিটি ত্রুটি পুনরুত্পাদন করা এবং এটি নির্ণয় এবং সংশোধন করার আগে এটি ডিবাগ করার উপর জোর দেওয়া কি যুক্তিসঙ্গত?

বা:

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

Sissies জন্য ডিবাগিং হয়?

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

সর্বশেষ তবে অন্তত না, যদি আপনি আমার সাথে একমত হন:

আমার দৃষ্টিভঙ্গি যুক্তিসঙ্গত, রক্ষণশীল এবং আরও বুলেটপ্রুফ তাদের বোঝাতে আমি কীভাবে আমার দলের সাথে কথা বলব?

Comments

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

— gnat

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

— KutuluMike

সম্পর্কিত: প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জার.কম

— সেশনস / ১৯10১০৫/২

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

— বেন লি

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

— ডায়েটবুদ্ধ

Answer 1

প্রতিটি ত্রুটি পুনরুত্পাদন করা এবং এটি নির্ণয় এবং সংশোধন করার আগে এটি ডিবাগ করার উপর জোর দেওয়া কি যুক্তিসঙ্গত?

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

আপনি যদি বাগটি পুনরুত্পাদন করেন না এবং নিজের জন্য দেখে থাকেন তবে আপনি কীভাবে 100% নিশ্চিত হতে পারবেন যে আপনি এটি ঠিক করে দিয়েছেন? হতে পারে আপনার প্রস্তাবিত ফিক্সটি এমন আরও কিছু সূক্ষ্ম বাগ প্রবর্তন করেছে যা প্রকৃতপক্ষে আপনি মূল ত্রুটিটি পুনরুত্পাদন করার চেষ্টা না করলে প্রকাশ পাবে না ।

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

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

আমার দৃষ্টিভঙ্গি যুক্তিসঙ্গত, রক্ষণশীল এবং আরও বুলেটপ্রুফ তাদের বোঝাতে আমি কীভাবে আমার দলের সাথে কথা বলব?

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

আপনি যদি সমস্যাটি যথাযথভাবে সমাধান করতে ব্যর্থ হন তবে আপনি গ্রাহকের সাথে বিশ্বাসকে কিছুটা ভেঙে ফেলেছেন (কিছুটা হলেও) এবং যদি আপনার বাজারে প্রতিযোগীরা থাকে তবে তারা আপনার গ্রাহক নাও থাকতে পারে।

Comments

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

— দ্বিপাক্ষিক

"কারণ তারা যদি ত্রুটিটি পুনরুত্পাদন না করে তবে এটি স্থির হয়েছে তা তারা নিশ্চিতভাবে জানতে পারবেন না।" আমেন ...

— মার্জন ভেনেমা

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

— অ্যান্ডি

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

— orip

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

— হতাশ

Answer 2

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

আমি ঠিক করি না যে ফিক্সিংয়ের আগে প্রতিটি বাগ পুনরুত্পাদন করার চেষ্টা করা অযৌক্তিক। তবে আপনি যদি এটি পুনরুত্পাদন করার চেষ্টা করেন এবং আপনি না করতে পারেন তবে অন্ধ প্যাচগুলি ভাল ধারণা কিনা তা নিয়ে এটি ব্যবসায়ের সিদ্ধান্তে পরিণত হয়।

Comments

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

— mattnz

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

— ড্যান নীলি

@ ড্যানিয়েলি: যদি একটি থ্রেড একটি অ্যারেতে একটি মান লিখে এবং তারপরে একটি ক্ষেত্রের মধ্যে একটি রেফারেন্স সঞ্চয় করে, এবং অন্য থ্রেডটি সেই ক্ষেত্রটি পড়ে এবং সংশ্লিষ্ট অ্যারে উপাদানটি অ্যাক্সেস করে, জেআইটি লেখার-রেফারেন্সটি সরিয়ে ফেললে কীভাবে বাগগুলি পুনরুত্পাদন করতে পারে? রাইটিং-এলিমেন্টের আগে অপারেশন?

— সুপারক্যাট

Answer 3

আদর্শভাবে, আপনি প্রতিটি বাগ পুনরুত্পাদন করতে সক্ষম হতে চান যাতে খুব কমপক্ষে আপনি পরীক্ষা করতে পারেন যে এটি ঠিক হয়ে গেছে।

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

সুতরাং, ডুপ্লিকেট করুন যখন আপনি পারেন তবে আপনি যদি না পারেন তবে সিস্টেম সম্পর্কে আপনার জ্ঞানটি ব্যবহার করুন, এবং কোডটিতে অপরাধীকে সনাক্ত করার চেষ্টা করুন।

Answer 4

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

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

আমার কাছে এটি কোনও ডিবাগিং ইস্যু কম এবং গ্রাহক পরিষেবাদির সমস্যা। আপনি কোনও গ্রাহকের কাছ থেকে বাগ রিপোর্ট পেয়েছেন; তাদের সমস্যাটি খুঁজে বের করার এবং এটি ঠিক করার জন্য যথাযথ যত্ন সহকারে আপনার দায়িত্ব রয়েছে have

Comments

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

— তুলাইনস কর্ডোভা

"আপনি যদি কোডটিতে কোনও সমস্যা পেয়ে থাকেন তবে আপনার পরিবেশ তৈরি করা, সমস্যাটি পুনরুত্পাদন করা এবং সমাধানটি পরীক্ষা করা আপনার আরও সহজ হওয়া উচিত" " আমি ওপি-র প্রশ্নটি পড়ি, "সমস্যাটি সনাক্ত করার আগে আমার কি সমস্ত বাগ রিপোর্টের রেপো কেস করা উচিত?" না, আপনার করা উচিত নয়।

— মাইকেল কে

আমি প্রত্যাশা করব যে পরীক্ষার বেশিরভাগটি বিদ্যমান বৈশিষ্ট্যগুলির রিগ্রেশন টেস্ট হবে।

— মাইকেল ডুরান্ট

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

— এলিসেডিল

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

— গ্যালাকটিক

Answer 5

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

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

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

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

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

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

Answer 6

প্রতিটি ত্রুটি পুনরুত্পাদন করা এবং এটি নির্ণয় এবং সংশোধন করার আগে এটি ডিবাগ করার উপর জোর দেওয়া কি যুক্তিসঙ্গত?

আমি হ্যাঁ বলি, কিছু সাবধানতা সহ।

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

আমি এই দৃশ্যে টেবিলের গ্রাহকের পাশে ছিলাম। আমি মার্কিন সরকারের অফিসে কর্মরত ছিলাম যা একটি অবিশ্বাস্যরূপে বড় ওরাকল ডাটাবেস ক্লাস্টার ব্যবহার করেছিল (একাধিক টেরাবাইট ডেটা এবং দিনে কয়েক মিলিয়ন রেকর্ড প্রক্রিয়াজাত করে)।

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

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

Answer 7

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

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

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

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

Answer 8

প্রতিটি ত্রুটি পুনরুত্পাদন করা এবং এটি নির্ণয় এবং সংশোধন করার আগে এটি ডিবাগ করার উপর জোর দেওয়া কি যুক্তিসঙ্গত?

না, এটা খুব অবশ্যই হয় না। এটি একটি নির্বোধ নীতি হবে।

আপনার প্রশ্ন এবং আপনার প্রস্তাবের সাথে আমি যে সমস্যাটি দেখছি তা হ'ল তারা পার্থক্য করতে ব্যর্থ

• বাগ রিপোর্ট
• ব্যর্থতা ( ত্রুটি )
• বাগ (কখনও কখনও ত্রুটিও বলা হয় )

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

একটি বাগ রিপোর্ট ব্যর্থতার প্রমাণ is

একটি ব্যর্থতা কিছু একটি ঘটনা ভুল চলছে। একটি সুনির্দিষ্ট ত্রুটি, তবে এটি কী কারণে ঘটেছে তা নিয়ে কোনও চিহ্নের প্রয়োজন নেই।

কোনও ত্রুটির কারণে ত্রুটি হতে পারে।

একটি বাগ ব্যর্থতার কারণ; ভবিষ্যতে ঘটে যাওয়া ব্যর্থতা রোধ করার জন্য এমন কিছু যা (নীতিগতভাবে) পরিবর্তিত হতে পারে।

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

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

তাই পুনরুত্পাদনযোগ্যতার উপর জোর দেওয়া যখন আরও শক্ত ক্ষেত্রে হয় তবে এটি কঠোর নীতি হিসাবে কার্যকর করা বুদ্ধিমানের কাজ নয়।

Comments

যদি বাগটি পুনরুত্পাদন করা যুক্তিসঙ্গত না হয় তবে আপনি কীভাবে জানবেন যে আপনি বাগটি ঠিক করেছেন? বাগ প্রজনন করার উপায় যতই জটিল।

— BЈовић

আপনি জানেন যে আপনি বাগটি ঠিক করে ফেলবেন যখন পুনরুত্পাদন করা এত সহজ যে আপনার প্রয়োজন নেই।

— পুনরায় পোস্টার

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

— gnasher729

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

— পুনরায় পোস্টার

Answer 9

সফ্টওয়্যার বিকাশের সমস্ত কিছুর মতো, সঠিক উত্তরটি একটি আপস।

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

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

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

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

Answer 10

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

এছাড়াও, আপনি কীভাবে তাদের কাছে প্রমাণ করবেন যে আপনি যদি ধাপগুলি প্রতিলিপি করতে না পারেন তবে বাগটি ঠিক হয়ে গেছে?

আপনার ক্ষেত্রে সমস্যাটি হ'ল ব্যবহারকারী জানেন না যে ত্রুটিটি কীভাবে ক্ষতিগ্রস্থ হয়েছিল, এটি কী অপারেশনটি করার স্ক্রিনে। তারা কেবল লগ আছে।

আমি আপনার বক্তব্য যুক্তিসঙ্গত মনে করি। যদি আপনার মনস্তাত্ত্বিক ক্ষমতা থাকে তবে আপনি সম্ভবত বেতনের জন্য কাজ করছেন না।

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

সমস্যাটি তখন ঘটবে যখন আপনার কিছু সহকর্মী খাঁটি ভাগ্য থেকে বাগটি খুঁজে পেয়ে এটি ঠিক করে দেয়।

Answer 11

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

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

এটি কি ত্রুটিটি সংশোধন করে যা বাগ রিপোর্টের কারণ করেছিল? আপনি ১০০% নিশ্চিত হতে পারবেন না ( এই একই কারণে দুটি ব্যাগ থাকতে পারে ), তবে সম্ভবত তা ঘটেছে।

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

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

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

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

Comments

আপনি কি ধরে নিচ্ছেন কোডটি আমার সাথে শুরু হয়েছিল?

— উভচর

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

— রিমকো গ্রিলিচ

Answer 12

প্রশ্নটি পড়ে, আমি আপনার অবস্থান এবং আপনার দলের মধ্যে কোনও মৌলিক বিরোধিতা দেখছি না।

• হ্যাঁ, ক্লায়েন্ট সেটিংসে সমস্যাটি পুনরুত্পাদন করার জন্য আপনার যথাসাধ্য চেষ্টা করা উচিত। তবে সর্বোত্তম প্রয়াসের অর্থ হ'ল এর জন্য আপনার কিছু সময় বাক্স সংজ্ঞায়িত করা উচিত, এবং সমস্যাটি প্রকৃতপক্ষে পুনরুত্পাদন করার জন্য লগের পর্যাপ্ত ডেটা নাও থাকতে পারে।

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

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

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

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

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

Answer 13

আমার কাছে মনে হচ্ছে আপনার আরও বিস্তারিত লগিং দরকার।

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

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

Answer 14

প্রতিটি ত্রুটি পুনরুত্পাদন করা এবং এটি নির্ণয় এবং সংশোধন করার আগে এটি ডিবাগ করার উপর জোর দেওয়া কি যুক্তিসঙ্গত?

যেহেতু কেউ এটিকে এখনও স্পষ্ট ভাষায় বলেনি: অবশ্যই না!

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

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

এবং অবশ্যই বাগ রয়েছে যেখানে আপনি যদি সেগুলি ভুল করেন তবে কোনও ক্লায়েন্ট $ 100'000 + হারাবে। এবং বাগগুলি স্থগিত না করে প্রতি ঘন্টার জন্য ক্লায়েন্ট $ 100'000 + হারাবে। আপনার বাগটি দেখে সিদ্ধান্ত নেওয়া দরকার। সমস্ত বাগের সাথে একই আচরণ করার জন্য কম্বল স্টেটমেন্টগুলি কাজ করে না।

Answer 15

খুব ভাল প্রশ্ন! আমার অভিমত হ'ল যদি আপনি সমস্যাটি পুনরুত্পাদন করতে না পারেন তবে আপনি 100% নিশ্চিতভাবে বলতে পারবেন না যে আপনি যে ফিক্সটি করেছেন তা তা করবে না:

ক) আসলে সমস্যাটি সমাধান করুন। খ) অন্য একটি বাগ তৈরি করুন

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

আপনি যদি বাগটি পুনরুত্পাদন করতে না পারেন এবং তারপরে নতুন সংস্করণটি ইনস্টল করতে পারেন এবং এটি ঠিক করা হয়েছে তা নিশ্চিত করতে পারেন তবে আপনি 100% নিশ্চিততার সাথে বলতে পারবেন না যে বাগটি চলে গেছে।

আপনাকে অন্যদের বোঝাতে সাহায্য করার জন্য আমি কয়েক মিনিটের জন্য সাদৃশ্যটি চিন্তা করার চেষ্টা করেছি তবে কিছুই মনে আসে নি। একটি দমবন্ধ একটি মজার উদাহরণ তবে এটি একই পরিস্থিতি নয় :-)

Comments

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

— সুপারক্যাট

যেমন একটি ক্ষেত্রে, ব্যর্থতা পুনরুত্পাদন করা প্রয়োজন হবে, বা যে অনুরূপ ব্যর্থতা মোড পারে যেখানে অন্য কোনও জায়গার জন্য কোডটি পরীক্ষা করে যদি প্রশ্নে কোডটি সুস্পষ্টভাবে ব্যর্থতার কারণ হিসাবে চিহ্নিত করতে পারে তবে যথেষ্ট হবে? ঘটে?

— সুপারক্যাট

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

— জয়ডেল গ্লুকি

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

— সুপারক্যাট

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

— সুপারক্যাট

Answer 16

[বাগ সম্পর্কিত] সমবর্তী ডাটাবেস অ্যাক্সেস, ক্লাস্টারড বাস্তবায়ন, মাল্টিথ্রেড

প্রতিটি ত্রুটি পুনরুত্পাদন করা এবং এটি নির্ণয় এবং সংশোধন করার আগে এটি ডিবাগ করার উপর জোর দেওয়া কি যুক্তিসঙ্গত?

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

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

Answer 17

উভয় ক্রিয়াকলাপ (কোড পর্যালোচনা এবং পরীক্ষা) প্রয়োজনীয়, উভয়ই যথেষ্ট নয়।

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

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

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