আমি যে বাগটি আবিষ্কার করেছি এবং প্যাচ করেছি তা কি রেকর্ড করা উচিত?


68

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

একটি ভাল অনুশীলন হিসাবে বিবেচনা করা হয়?


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

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

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

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

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

উত্তর:


71

এটি কোনও বাগ রিপোর্টের শ্রোতা কে নির্ভর করে।

এটি যদি কেবলমাত্র বিকাশকারীরা অভ্যন্তরীণভাবে দেখে থাকে তবে কী ঠিক করা দরকার তা জানতে, তবে বিরক্ত করবেন না। এটা ঠিক এই মুহূর্তে শব্দ।

যাইহোক যাইহোক লগ করার কারণগুলির অ-সম্পূর্ণ তালিকা:

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

56
ত্রুটি হওয়ার সম্ভাব্য স্পটটি হ'ল একটি বাগ যা আগে ঘটেছিল। আমি কার্যত প্রতিটি দৃশ্যে এটি রেকর্ড করার পরামর্শ দেব।
কর্সিকা

18
# 4: পরীক্ষকরা তাদের পরীক্ষার জন্য গাইড করতে বাগ ট্র্যাকার ব্যবহার করেন। তারা পরীক্ষা করবে যে ফিক্সটি কাজ করে এবং এর ফলে নতুন বাগ বা রিগ্রেশন হয়নি।
jpmc26

2
@ করসিকা ওষুধ কখন রোগের চেয়ে খারাপ? ;-)
hBy2Py

1
@ hBy2Py একটি নতুন ডাক্তার খুঁজুন, তারপরে এটি রেকর্ড করুন।
কর্সিকা

2
আপনি যা উদ্ধৃত করেছেন তা ব্র্যাডথোমাস পুনরায় প্রকাশ করতে: "বাগট্র্যাকারটি একটি টোডো তালিকা হিসাবে ব্যবহৃত হয়, এবং আরও কিছু না" + "স্থির বাগ" -> "টুডো নেই"। আমি প্রায় অন্যান্য সমস্ত পরিস্থিতিতে একমত, আপনি একটি রেকর্ড চান
ক্যালাথ

52

আমি বলব, এটি আপনার পণ্যটি বাগের সাথে প্রকাশিত হয়েছিল কিনা তা নির্ভর করে।

আপনি যে বাগটি খুঁজে পেয়েছেন তা যদি এটি প্রকাশ করা হয় তবে হ্যাঁ, একটি বাগ-প্রতিবেদন তৈরি করুন। রিলিজ চক্রগুলি প্রায়শই দীর্ঘ হতে পারে এবং আপনি ইতিমধ্যে এটি ঠিক করার সময় আপনার বাগটিকে নতুন সমস্যা হিসাবে প্রতিবেদন করতে চান না।

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


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

24

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

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


9

এটি বিভিন্ন কারণের উপর নির্ভর করে।

পিটার বি এবং কালেথ উভয়েই তাদের উত্তরের কয়েকটি তালিকা রয়েছে:

  • বাগটি কি কোনও অফিসিয়াল মুক্তির অংশ হয়েছে?
  • এগুলিতে ব্যাগ / সময় ব্যয় করার সংখ্যাটি কি বিশেষভাবে অনুসরণ করা যায়?

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

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


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

3

এই প্রকল্পটির উত্তর কেবলমাত্র আপনার প্রকল্পের নেতৃত্ব দ্বারা দেওয়া যেতে পারে, বা যে কেউ "টিকিট প্রক্রিয়া" এর দায়িত্বে রয়েছে।

তবে আমাকে অন্য উপায়ে জিজ্ঞাসা করতে দিন: আপনি যে প্যাগটি ফেলেছেন তা আপনি রেকর্ড করবেন না কেন ?

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

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

আমি আপনার সম্পর্কে জানি না, তবে প্রতিটি বাগফিক্সকে এভাবে রেকর্ড করার জন্য এমনকি ছোট ছোট প্রকল্পগুলিতেও এটি একটি নীতি তৈরি করার পক্ষে যথেষ্ট ।

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


2

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

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

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


1

হ্যাঁ


ইতিমধ্যে কিছু উত্তর রয়েছে যা পরিস্থিতি প্রকাশ করে যাতে একটি বাগ রিপোর্ট তৈরি করা উপযুক্ত। কিছু উত্তর। এবং তারা পৃথক।

একমাত্র উত্তরটি কেউ জানে না। বিভিন্ন সময়ে বিভিন্ন ব্যক্তির বিভিন্ন বিষয়ে মতামত থাকবে will

সুতরাং এখন, ত্রুটির মুখোমুখি হওয়ার সময় আপনার দুটি সমাধান রয়েছে:

  • এটি একটি বাগ রিপোর্ট খোলার উপযুক্ত কিনা তা চিন্তা করুন, নাও হতে পারে কোনও সহকর্মীর মতামত জিজ্ঞাসা করুন ... এবং পরে কিছু ক্ষেত্রে, আফসোস করুন যে কেউ আপনাকে এ সম্পর্কে জিজ্ঞাসা করছে না বলে এবং আপনার কাছে ইতিমধ্যে রিপোর্টটি থাকলে আপনি করতে পারেন শুধু তাদের দিকে ইঙ্গিত করুন
  • শুধু রিপোর্ট তৈরি করুন

প্রতিবেদন তৈরি করা দ্রুততর, এবং যদি তা না হয় ... এটি স্বয়ংক্রিয় করুন।


কীভাবে এটি স্বয়ংক্রিয় করবেন? অনুমান করে যে আপনার ট্র্যাকার স্ক্রিপ্টিং সমর্থন করে, একটি স্ক্রিপ্ট তৈরি করুন যা আপনি কল করতে পারেন এবং এটি একটি বাগ রিপোর্ট জমা দেওয়ার জন্য কমিট বার্তা (শিরোনাম এবং মূল অংশ) ব্যবহার করবে এবং ট্র্যাকিংয়ের সাথে সম্পর্কিত কমিট রিভিশনটি সাথে সাথে এটি "বাস্তবায়িত" হিসাবে বন্ধ করবে।


0

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

শুধু আপনার পরিচালককে জিজ্ঞাসা করুন । আপনার গ্রুপটি কীভাবে কাঠামোগত হয় তার উপর নির্ভর করে আপনার পরিচালক বা বিকল্পভাবে প্রকল্পের সীসা বা স্ক্রাম মাস্টার ইত্যাদি।

এ সম্পর্কে ভাল এবং দুর্বল অনুশীলনের অনেকগুলি সিস্টেম রয়েছে তবে আপনি নিজের দলের পক্ষে সঠিক জিনিসটি করছেন তা জানার একমাত্র উপায় হল জিজ্ঞাসা করা।

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.