বাগটি যদি 5+ বছর পুরানো হয় তবে এটি কী বৈশিষ্ট্যযুক্ত? [বন্ধ]


18

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

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

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

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

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

আমি আপনার মতামত / অভিজ্ঞতা আগ্রহী। দয়া করে ঝুঁকি, ব্যয়-বেনিফিট এবং অন্যান্য অ-প্রযুক্তিগত বিষয়গুলি বিবেচনা করার চেষ্টা করুন।


2
আমি মনে করি আপনার মানে "... এটি এমনভাবে কাজ করেছিল প্রাকদের জন্য" "
পেঁয়াজ-নাইট

পুনরায় লিখুন না। এটি নিজেই ভেঙে না পড়লে (আপনি ব্রেকিং জিনিসগুলিতে আরও যুক্ত করতে পারবেন না) আপনি পুনরায় লেখার সিদ্ধান্ত নেওয়ার সময় (পাশাপাশি সময়) ঠিক করার পরে আরও বাগ প্রবর্তন করবেন

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

উত্তর:


14

আমি তোমার কষ্টটা অনুভব করতে পারছি.

তবে এটি বাগ হিসাবে কেবল কোনও কারণ ঠিক করা যথেষ্ট উপযুক্ত কারণ নয়।

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

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

রিগ্রেশন টেস্টগুলি মূলত আপনার গ্রাহকরা যা ঘটবে তা প্রত্যাশা করে। কোনও রিগ্রেশন পরীক্ষা অপসারণের আগে নিশ্চিত হয়ে নিন যে এটি কারও ক্ষতি করবে না (এটি প্রায় অসম্পূর্ণ)। আপনি যদি একটি বাগ ফিক্স করতে পারেন এবং এই রিগ্রেশন পরীক্ষার ভাঙে না তারপর, এটা একটি বাস্তব ফিক্স হয়।


রিগ্রেশন পরীক্ষার অংশটি ধরে নেওয়া সত্য যে আপনি আসলে পরীক্ষার কভারেজের উপযুক্ত স্তরটি জানেন।
পেমদাস

অন্যদিকে, আপনি যদি একটি জিইউআই কোড করেন তবে কম নির্ভরতা রয়েছে; ব্যবহারকারীরা আরও সহজে বিকশিত হন।
ম্যাথিউ এম।

@ ম্যাথিউ এম: পুরোপুরি। অভ্যাস পরিবর্তন করা সহজ (যতক্ষণ আপনি অভ্যাস ফিক্সিংয়ে বিনিয়োগ করেন) তার চেয়ে বেশি স্বয়ংক্রিয় সিস্টেমগুলি (প্রচুর লোকেরা পিছনের ঘরে ভুলে যাবেন) ঠিক করার চেয়ে।
মার্টিন ইয়র্ক

3

বাগ সংশোধন করার সিদ্ধান্ত নেওয়ার সময় কিছু বিষয় বিবেচনা করা উচিত ... কোনওভাবেই সমস্ত অন্তর্ভুক্ত নয়।

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

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

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

3

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

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

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

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


2

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

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

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