যখন জানা বাগটি সমাধান করা হয় তখন নতুন বাগগুলি অন্য কোথাও প্রদর্শিত হওয়ার কারণ কী হতে পারে?

Question

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

এটি কীভাবে ঘটতে পারে তা নিয়ে ভাবতে শুরু করেছিলাম, তবে এটি বের করতে পারি না।

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

তাহলে কোনও একক বিকাশকারী তার কাজের প্রতি দৃষ্টি নিবদ্ধ রেখে লিখিত একটি তাজা, ছোট আকারের কোডবেসে এ জাতীয় সমস্যার কারণ কী হতে পারে ?

কি সাহায্য করতে পারে?

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

Comments

আহ, ভাল ওল "" ব্যর্থতার তীব্র তরঙ্গ "ডিজাইনের ধরণ। :-)

— ব্রায়ান নোব্লাচ

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

— ততই

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

— রাইজিং ডার্কনেস

... এবং এটি ডিবাগ করার জন্য দুঃস্বপ্ন ছিল।

— রাইজিং ডার্কনেস

Answer 1

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

Comments

এটি দুর্বল বা কোনও প্রতিরোধের পরীক্ষার সাথে মিলিত হয়নি

— রায়াতাল

সত্য, @ রাইঠাল, যদিও রিগ্রেশন টেস্টিং এই ধরণের বাগগুলিকে আটকাবে না, কেবল আপনাকে এগুলি শিগগির আপনাকে জানিয়ে দিন।

— কার্ল বিলেফেল্ট

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

— বিডিএসএল

Answer 2

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

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

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

Answer 3

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

Answer 4

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

উদাহরণস্বরূপ, ধরুন A এবং B ফাংশনগুলি কিছু পরিমাণের জন্য শূন্য-ভিত্তিক কনভেনশন ব্যবহার করে, সুতরাং তারা একসাথে সঠিকভাবে কাজ করে, তবে সি একটি ব্যবহার করে, আপনি সি এর সাথে কাজ করার জন্য এটিকে "ফিক্স" করতে পারেন এবং তারপরে বি নিয়ে কোনও সমস্যা আবিষ্কার করেন

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

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

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

আশাকরি এটা সাহায্য করবে.

Answer 5

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

Answer 6

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

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

Answer 7

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

Answer 8

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

বেমানান স্পেসিফিকেশনগুলিও ঘটে। তারপরে এটি প্রায় গ্যারান্টিযুক্ত যে একটি বাগ সংশোধন করার ফলে অন্যটি তৈরি হবে (প্রকল্পের পরে নির্দিষ্ট অংশটি ব্যবহার না করা উত্তেজনাপূর্ণ) exciting

Answer 9

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

সুতরাং মূলত আপনি নিজেরাই নিজেকে উত্তর দিয়েছেন:

• আলগা সংযোজন
• পরীক্ষার অভাব

শুধু টিডিডি নীতিটি মানিয়ে নিতে শিখুন (কমপক্ষে নতুন বৈশিষ্ট্যগুলির জন্য) এবং ঘটতে পারে এমন প্রতিটি সম্ভাব্য অবস্থার পরীক্ষা করার চেষ্টা করুন।

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

Answer 10

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

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

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