বাগগুলি ঠিক করুন, বা গ্রাহক তাদের সন্ধানের জন্য অপেক্ষা করবেন?


35

অন্যান্য ব্যক্তিরা কি বাগগুলি দেখলে তারা ঠিক করে দেয় বা ক্রাশ / ডেটা ক্ষতি / লোকেরা এটি ঠিক করার আগেই মারা যাওয়ার আগ পর্যন্ত অপেক্ষা করে থাকে?

উদাহরণ 1

 Customer customer = null;
 ...
 customer.Save();

কোডটি স্পষ্টতই ভুল, এবং এর আশেপাশে কোনও উপায় নেই - এটি নাল রেফারেন্সে কোনও পদ্ধতি কল করে। এটি ক্রাশ না হওয়ার কারণে ঘটেSave হওয়ার ঘটে কোনও উদাহরণের ডেটা অ্যাক্সেস না করার ঘটে; সুতরাং এটি ঠিক একটি স্থির ফাংশন কল করার মত। তবে যে কোনও ছোট পরিবর্তন হঠাৎ করে ভাঙা কোডের কারণ হতে পারে যা ক্রাশ হয় না: ক্রাশ শুরু করতে।

তবে , কোডটি সংশোধন করাটাও অকল্পনীয় নয় :

Customer customer = null;
...
customer = new Customer();
try
   ...
   customer.Save();
   ...
finally
   customer.Free();
end;

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

উদাহরণ 2

float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);

পদার্থবিজ্ঞান জানে এমন লোকেরা চিনবে যে এটি आर হওয়ার কথা 2

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

তবে এটিও সম্ভবত এটির অতিরিক্ত অনুমানের গতিটি অন্য একটি বিষয়কে মাস্ক করে দিচ্ছে: শাটলটি খুব দ্রুত গতিতে চলার সময় এয়ার-ব্যাগ স্থাপন করতে পারে না। যদি আমরা হঠাৎ করে কোডটি ঠিক করি:

float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);

এখন গতিটি সঠিক, এবং হঠাৎ এয়ারব্যাগগুলি যখন ব্যবহার করা উচিত নয় তখন মোতায়েন করা হচ্ছে।

উদাহরণ 3

এখানে একটি উদাহরণ রয়েছে যা আমি সম্প্রতি পেয়েছি, কোনও স্ট্রিংয়ে অবৈধ অক্ষর রয়েছে কিনা তা পরীক্ষা করে দেখছি:

if (StrPos(Address, "PO BOX") >= 0)
{
   //Do something
}

যদি দেখা যাচ্ছে যে Do somethingশাখায় একটি বাগ আছে ? স্পষ্টতই ভুল কোড ঠিক করা:

if (StrPos("PO BOX", Address) >= 0)
{
   //Do something
}

কোডটি ঠিক করে তবে একটি বাগ প্রবর্তন করে।


আমি এটি যেভাবে দেখছি সেখানে দুটি সম্ভাবনা রয়েছে:

  • কোডটি ঠিক করুন, এবং এটি ভঙ্গ করার জন্য দোষী হন get
  • কোডটি ক্রাশ হওয়ার জন্য অপেক্ষা করুন এবং বাগ থাকার জন্য দোষ চাপুন

আমাদের কি করতে আপনি রাজনৈতিকভাবে না?


উদাহরণ 4 - আজকের আসল ওয়ার্ল্ড বাগ

আমি একটি অবজেক্ট তৈরি করছি, তবে ভুল কনস্ট্রাক্টরকে ফোন করছি:

Customer customer = new Customer();

দেখা যাচ্ছে যে "প্যারামিটারলেস" কনস্ট্রাক্টর আসলে উত্তরাধিকার শৃঙ্খলে আরও পিছনে থেকে প্যারামিটারাইজড কনস্ট্রাক্টর:

public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)

এটিকে কল করা একটি ভুল, যেহেতু এটি পরবর্তী সমস্ত নির্মাণকারীকে বাইপাস করে।

আমি এই জাতীয় বিপজ্জনক নির্মাণকারীকে প্রকাশ না করার জন্য অবজেক্টের বংশটি পরিবর্তন করতে পারি, তবে এখন আমাকে কোডটি এতে পরিবর্তন করতে হবে:

Customer customer = new Customer(depends);

তবে আমি এই গ্যারান্টি দিতে পারি না যে এই পরিবর্তনটি কোনও কিছুই ভঙ্গ করবে না। আমার উপরের উদাহরণের মতো 1 , সম্ভবত কেউ, কোথাও, কোনও না কোনওভাবে কিছু রহস্যজনক অবস্থার অধীনে Customerঅবৈধ এবং জঞ্জাল পূর্ণরূপে নির্মাণের উপর নির্ভর করে ।

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

আমি এটিতে আপনার স্ত্রীর জীবন বাজি রাখতে পারি না।

এবং আমি এখান থেকে মঙ্গলবার পর্যন্ত এটি পরীক্ষা করতে পারি, আমি আপনার মেয়ের জীবনের শপথ করতে পারি না যে আমি কোনও প্রতিরোধের পরিচয় দেয়নি।

আমি কি:

  • কোডটি ঠিক করুন এবং এটি ভঙ্গ করার জন্য দোষী হবেন? অথবা
  • বাগ ছেড়ে দিন, এবং গ্রাহক এটি পেলে দোষী হন?

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

3
অবশ্যই একটি ভাল গবেষণা প্রশ্ন
মুহাম্মদ আলকারৌরী

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

2
'[আপনি] ঠিক করার আগে মানুষ মারা না যাওয়া পর্যন্ত অপেক্ষা করুন'! পবিত্র গাভী, আমি গুরুত্ব সহকারে আশা করি এর একটাই উত্তর আছে ...
ক্রিস নাইট

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

উত্তর:


34

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

আমি যদি করণীয় তা নির্ধারণের জন্য যদি একটি সাধারণ নির্দেশিকা দিই, তবে আমার মনে হয় এটি এমন কিছু হবে:

  1. পছন্দের ট্র্যাকিং সিস্টেমে ত্রুটিটি লগইন করুন। প্রয়োজনে পরিচালনা / সহকর্মীদের সাথে আলোচনা করুন।
  2. যদি এটির সম্ভাব্য মারাত্মক পরিণতিগুলির সাথে একটি ত্রুটি থাকে (যেমন আপনার উদাহরণ # 2), চালান, চিৎকার করুন, কর্তৃপক্ষের নোটিশযুক্ত কেউ অবধি উপরে লাফিয়ে লাফিয়ে লাফিয়ে উঠে যথাযথ পদক্ষেপ নির্ধারণ করে যা বাগ ফিক্সের সাথে সম্পর্কিত ঝুঁকিগুলি হ্রাস করবে। এটি আপনার মুক্তির তারিখটিকে পিছনে ঠেলে দিতে পারে, জীবন বাঁচাতে পারে, আপনার উইন্ডো ধুয়ে ফেলতে পারে ইত্যাদি
  3. যদি এটি একটি অ-ব্রেকিং ত্রুটি, বা কোনও কার্যকারিতা বিদ্যমান থাকে তবে এটি নির্ধারণের ঝুঁকিটি ফিক্সের সুবিধার চেয়ে বেশি কিনা তা মূল্যায়ন করুন। কিছু পরিস্থিতিতে গ্রাহকরা এটি আনার জন্য অপেক্ষা করা ভাল হবে, যেহেতু আপনি জানেন যে 100% প্রয়োজনীয় নয় তখন আপনি জিনিস নির্ধারণ / পরীক্ষা করার জন্য সময় ব্যয় করছেন না।

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


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

6
ত্রুটি লগ করার জন্য +1। অন্যান্য ত্রুটিগুলি অগ্রাধিকার নিতে পারে ...
শীঘ্রই

35

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

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


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

4
@ হেল্পার পদ্ধতি: আপনি যদি বুদ্ধিমানদের মতো এটি পরীক্ষা করে থাকেন তবে আরও ভাল হত।
ভিঙ্কো ভার্সালোভিক

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

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

এর, আরও খারাপ? (ফিলার)
হ্যালো 71

24

বাগ ঠিক করুন

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

এটিকে রিফ্যাক্টরিং বা পারফরম্যান্স বাগের সাথে সম্পর্কিত নয় এমন পারফরম্যান্স উন্নতি করে গুলিয়ে ফেলবেন না।

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


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

21

গ্রাহক কি বলতেন?

আমি এখানে এটি খেলতে কল্পনা কিভাবে:

গ্রাহক: আমি এক্স করলে ক্রাশ হয়।

প্রোগ্রামার: ওহ হ্যাঁ! আমার মনে আছে আমি কিছুক্ষণ আগে দেখেছি। আমি বুঝতে পেরেছিলাম যে এটি এখনও কোনও বড় বিষয় নয়, তাই আমি এটি সেখানে রেখেছি।

গ্রাহক: [ভোঁতা বস্তুর কাছে পৌঁছে]

হ্যাঁ। বাগ ঠিক করুন। আপনি গ্রাহককে একটি উত্তেজনাপূর্ণ অভিজ্ঞতা থেকে বাঁচাবেন এবং জরুরি অবস্থার আগে এটি ঠিক করে ফেলতে হবে।

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


8

আপনি যে উদাহরণ দিয়েছেন তার সবকটির কাছে একটি সাধারণ থ্রেড রয়েছে বলে মনে হচ্ছে। আপনি যে বাগটি পুরোপুরি বুঝতে পারেন না তা ঠিক করতে চান বলে মনে হচ্ছে understand আমি বললাম যে আপনি প্রতিটির অনিচ্ছাকৃত পরিণতির সম্ভাবনাটি নোট করেছেন।

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

আপনি যদি বিশ্বাস করেন যে কোডটি দেখে ত্রুটি রয়েছে তবে নিশ্চিত হয়ে নিন যে আপনি সেই ত্রুটিটি সেই উপায়ে পুনরায় উত্পাদন করতে পারবেন যা গ্রাহক দেখতে পাবে। আপনি যদি না করতে পারেন তবে কেন অন্য কিছু ঠিক করার জন্য আপনার সংস্থান ব্যয় করবেন না।


7

যত তাড়াতাড়ি সম্ভব আপনার প্রযুক্তিগত debtণ থেকে সরে যেতে শুরু করুন

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

উদাহরণ 1-এ, যদি Save()কোনও উদাহরণ ডেটা অ্যাক্সেস না করে তবে গ্রাহক ডেটাটি ঠিক কী সংরক্ষণ করে? ফিক্সিং এবং পরীক্ষা শুরু করুন।

উদাহরণ 2-তে, পরীক্ষাগুলির সাথে গতি ক্যালকুলেটরটি আচ্ছাদন করা এবং এটি নিশ্চিত করে যে এটি সমস্ত মূল উদাহরণগুলিতে ফলাফলের সঠিক গণনা করে।

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

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


5

আপনার ইতিমধ্যে ভাল উত্তর আছে। আমি কিছু ভয়াবহ হওয়ার ভয়ে সমস্যার বিষয়ে কিছু যুক্ত করব।

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

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

এর সমাধানটি দ্বিগুণ:

  1. কোডটি যথাসম্ভব কাঠামোগত করুন।
  2. কোডটি যথেষ্ট পরিমাণে বিচ্ছিন্ন হয়ে গেলে আপনি জানেন যে অন্য কোনও কিছুই ভাঙবে না, এটি ঠিক করুন।

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

দ্বিতীয় পদক্ষেপটি হ'ল আপনি বাগটি ঠিক করুন।

কয়েকটি পয়েন্ট প্রাসঙ্গিক:

  1. এই প্রক্রিয়াটির জন্য সংস্করণ নিয়ন্ত্রণ একেবারে প্রয়োজন।
  2. রিফ্যাক্টরিং স্টেপ এবং বাগ ফিক্সিং স্টেপ পৃথক কমিট হিসাবে সংস্করণ নিয়ন্ত্রণে আরও ভাল প্রতিশ্রুতিবদ্ধ, তাই প্রত্যেকটির একটি সুসংজ্ঞায়িত historicalতিহাসিক কার্যকারিতা রয়েছে।
  3. অন্য কোনও বাগ তৈরির সম্ভাবনাটি স্থির করবেন না, আপনি কিছু করতে পারবেন না। বরং আপনার কোডটি আরও ভাল করার কথা ভাবেন। অন্য কথায়, আপনি যদি না জানেন যে আপনি বাগগুলি হ্রাস করার চেয়ে বাড়িয়ে তুলছেন তবে আপনার এটি করা উচিত।
  4. শেষ পয়েন্ট সম্পর্কিত: ভবিষ্যত ভবিষ্যদ্বাণী করার চেষ্টা করবেন না। মানুষ ভবিষ্যদ্বাণীতে খুব ভাল বলে মনে করে পক্ষপাতদুষ্ট। বাস্তবে আমাদের পূর্বাভাস ক্ষমতা স্বল্প মেয়াদী। সুতরাং একটি অস্পষ্ট অনির্দিষ্ট ভবিষ্যতের বাগ সম্পর্কে চিন্তা করবেন না। এটি ইয়াজিএনআইয়ের পিছনে নীতিও
  5. বাগ বিশ্বের সংস্করণ নিয়ন্ত্রণের সাথে সম্পর্কিত সরঞ্জামটি হ'ল বাগ ট্র্যাকার । আপনারও এটির প্রয়োজন হবে।
  6. আপনার দুটি কারণের জন্য বাগগুলি ঠিক করতে হবে: গ্রাহককে সন্তুষ্ট করার জন্য; এবং যাতে আপনার বিকাশে অগ্রগতি করতে সক্ষম হন। উদাহরণ 3 ব্যবহার করার জন্য (পদার্থবিজ্ঞানের একটি): প্রোগ্রামটি যদি গ্রাহককে এইরকম ভাঙা সমীকরণের সাথে সন্তুষ্ট করে, তবে এই বাগটি প্রশমিত করার জন্য সফ্টওয়্যারটির আরও অনেকগুলি অংশ রয়েছে যা ভুলভাবে তৈরি করা হয়েছে (উদাহরণস্বরূপ এয়ারব্যাগ স্থাপনা)। যদি এই সফ্টওয়্যারটির জন্য একটি সংস্করণ 2 (বা 1.1) প্রয়োজন হয়, তবে আপনি এই ত্রুটিযুক্তটির উপর ভিত্তি করে সঠিক কোড বিকাশ করতে আরও বেশি অসুবিধা পাবেন। তারপরে আপনি হয় বড় পুনর্লিখনের দিকে যাচ্ছেন, বা দুর্দান্ত ব্যর্থতার দিকে। উভয় আপনার এড়ানো উচিত।

এগুলি ইতিমধ্যে কয়েকটি পয়েন্টের বেশি, সুতরাং আমার ধারণা আমি এখানেই থামব।


3

আপনার প্রথমে একটি বাগের সংজ্ঞা বিবেচনা করা উচিত:

  1. পড়ার মতো কোডটি আপনার সঠিক হওয়ার পক্ষে মেলেনি
  2. সফ্টওয়্যারটি তার কাজগুলি সঠিকভাবে সম্পাদন করে না

আপনি # 1 তে মনোনিবেশ করছেন বলে মনে হচ্ছে, যেখানে # 2 বসার সেরা জায়গা। অবশ্যই, আমরা প্রোগ্রামাররা আমাদের কোডটি সঠিক হতে চাই (# 1), কিন্তু লোকেরা এটি কাজ করার জন্য আমাদের প্রদান করে (# 2)।

আপনি যে কোড বেডটি দুর্ঘটনাক্রমে নতুন বাগগুলি প্রবর্তন করতে পারেন তাতে কী করতে বা না করতে পারে তা বর্তমান সফ্টওয়্যারটির # 2 এর দৃষ্টিতে অপ্রাসঙ্গিক। তবে, # 1 নিজের বা রক্ষণাবেক্ষণের প্রোগ্রামার অনুসরণ করে। এটি কখনও কখনও সিদ্ধান্ত নেওয়া কঠিন, তবে যখন # 2 এবং # 1 দ্বন্দ্ব হয় তখন আপনাকে জানতে হবে যে # 2 স্পষ্টতই আরও গুরুত্বপূর্ণ।


2

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

আপনার উল্লিখিত ক্ষেত্রেগুলিতে বৈধ বাগ ব্যতীত আরও সম্ভাব্য পরিস্থিতি রয়েছে:

  1. আপনি যে কোডটি দেখছেন তা হ'ল কিছু ডেড কোড। এটি সম্ভবত কারণ ysolik বলেছেন: গ্রাহকরা সবসময় বাগ খুঁজে পান। যদি তারা না করে, সম্ভবত কোডটি কখনও কার্যকর হয় না।
  2. একটি WTF পরিস্থিতি ছিল যেখানে সুস্পষ্ট ত্রুটিরটির উদ্দেশ্য ছিল। (আমরা প্রোডাকশন কোডের কথা বলছি, কিছু ঘটতে পারত, তাই না?)
  3. ব্যবসায় / গ্রাহকরা ইস্যুটি সম্পর্কে ইতিমধ্যে জানতেন তবে সমাধানের প্রয়োজনীয়তা বোধ করবেন না।
  4. হয়তো আরো...

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


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

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

2

আমি কি:

  • কোডটি ঠিক করুন এবং এটি ভঙ্গ করার জন্য দোষী হবেন? অথবা
  • বাগ ছেড়ে দিন, এবং গ্রাহক এটি পেলে দোষী হন?

আপনি বাগ ঠিক করুন, শুরু করুন ইউনিট পরীক্ষাএবং সেগুলি সফল হলে আপনি নিজের ঠিকঠাকটি পরীক্ষা করে দেখুন।

(অথবা, যদি আপনার ইউনিট পরীক্ষাগুলি যদি সত্যিই দীর্ঘ সময় নেয় তবে আপনি প্রথমে আপনার ফিক্সটি পরীক্ষা করে দেখুন এবং তারপরে অপেক্ষা করুন যে আপনার সিআই সরঞ্জামটি আপনাকে কোনও মেল প্রেরণ করে কারণ আপনার প্রতিশ্রুতি কিছু ভেঙেছে))


1
বা যদি আপনি কোনও গেটেড চেক-ইন ব্যবহার করেন, সেট আপ করুন, যাতে আপনি আসলে ভাঙা কোডটি চেক ইন করেন না।
অ্যাডাম শিখুন

3
দীর্ঘ সময় গ্রহণ করা নোংরা কোড করার কোনও অজুহাত নয়।
টবি

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

1

সেগুলি ক্র্যাশ / ডেটা হ্রাসের বাগ থাকলে তা ঠিক করুন। কোনও পরিচিত ডেটা-লস বাগ সহ একটি প্রোগ্রাম শিপিং সম্পূর্ণরূপে দূষিত এবং অনর্থ্য।

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

প্রতিটি বৃহত সফ্টওয়্যার প্রকল্পের কীভাবে রিডমিতে 'জ্ঞাত সমস্যাগুলি' বিভাগ রয়েছে তা লক্ষ্য করুন যা সাধারণত ঠিক সেইভাবে তালিকাবদ্ধ করে: বাগগুলি যা জানা থাকে।

বাগগুলি জানা এবং সেগুলিতে যোগাযোগ না করা কেবলমাত্র ছোটখাটো / প্রসাধনী বাগের জন্যই আইএমএইচও গ্রহণযোগ্য।


1

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

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


0

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

মনে রাখবেন, "আমরা সেই সমস্যাটি সম্পর্কে জানি এবং এটি ভবিষ্যতে প্রকাশের ক্ষেত্রে সমাধান করব" এর সমার্থক "" আমরা এই সমস্যাটি সম্পর্কে জানি তবে এটির মোকাবেলা এড়াতে আপনার যথেষ্ট যত্ন নেই "।


0

ক্রিয়াকলাপের সঠিক পথটি ত্রুটিটিকে উপেক্ষা করা বা ঘটনাস্থলে এটি "সমাধান" করা নয়; আপনি আপনার প্রশ্নে চিহ্নিত করেছেন যে খুব কারণগুলির জন্য।

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

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

  • ব্যবহার : কোন কোড ত্রুটিযুক্ত কোড ব্যবহার করে? এবং কিভাবে? কোডটি কি মারা গেছে? অন্য কোন কোড আছে যা ত্রুটিপূর্ণ আচরণের উপর নির্ভর করে?

  • লেখক : আপনি যদি উপরের তথ্যটি ব্যবহার করে দ্রুত কোনও সিদ্ধান্তে পৌঁছতে না পারেন তবে কোডটির লেখককে জিজ্ঞাসা করুন (কমপক্ষে এটি সম্ভব হলে) কেন কোডটি এটির মতো দেখাচ্ছে। সাধারণত আপনি একটি "ওপস পাবেন, এটি ঠিক করা উচিত!" বা "" না! এটি পরিবর্তন করবেন না !!! এটি সেইভাবে প্রয়োজন! " এখনই

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