অন্য কোনও কিছুর উপর কাজ করার সময় আপনার কী পূর্ববর্তী ত্রুটি সমাধান করা উচিত?


15

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

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

ধন্যবাদ, কোরি


উত্তর:


10

আমি খুব ছোট একটি টিমের সাথে কাজ করি, সুতরাং এটি পরিবর্তনটি কী তার উপর নির্ভর করে:

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

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

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

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

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


বয় স্কাউট নিয়মের উল্লেখ করার জন্য +1 "ক্যাম্পগ্রাউন্ডটিকে আপনি যতটা খুঁজে পেয়েছেন তার থেকে পরিষ্কার রাখুন" "
মার্টিন উইকম্যান

8

সর্বদা হিসাবে, এটি নির্ভর করে।

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

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


5

প্রাগমেটিক প্রোগ্রামার এগুলিকে 'ব্রোকন উইন্ডোজ' বলে।

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

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

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


0

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


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

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

0

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

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


0

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


কখনও কখনও একটি ছোট বাগ ফিক্স করা এটিকে উপেক্ষা করার চেয়ে বেশি সময় নেয় না এবং পরে এটি ঠিক করার চেয়ে আরও কার্যকর।
ডেভিড থর্নলি

আমি কেন এটি তুচ্ছ না বলেছি তা বললাম। তবে 15 মিনিটেরও বেশি সময় লাগতে পারে এমন আমার মনে হয় লগ করা উচিত।
ক্রেগ ২

0

আমি এমন দলে রয়েছি যেখানে অ-সমালোচনামূলক ত্রুটি বা মান-লঙ্ঘন একটি "দুর্বল কোড" ত্রুটি হিসাবে জমা দেওয়া হয়েছে। আমি বলব যে যে ব্যক্তি একটি সমালোচনামূলক ত্রুটি খুঁজে পায় তার একধরনের পতাকা নিক্ষেপের দায়িত্ব রয়েছে


0

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

একটি বিষয় লক্ষণীয়, আমরা 4 টি দেব এবং একটি ইন্টার্নের একটি ছোট দোকান এবং আমি যে বাগটি ঠিক করেছি তা সম্ভবত আমি তৈরি করা বাগ।


0

যদি কোডটি স্পষ্টতই ভুল হয় তবে সমাধানটি মোটামুটি সহজবোধ্য এবং আপনি বিশ্বাস করেন যে ব্যবহারকারীদের প্রভাবিত করার ঝুঁকি কম, তবে এটির জন্য যান। এটি পেশাদার রায় নেমে আসে।

আপনার মনে রাখতে হবে যদিও এটি যদি আপনি খুঁজে পেয়ে থাকেন তবে সম্ভবত ব্যবহারকারীরা তা করেননি বা অন্যথায় তারা এটি রিপোর্ট করেছেন। কোনও সমস্যা সমাধানের জন্য সময় ব্যয় করার পরিবর্তে যা কোনও ব্যবহারকারীর মুখোমুখি হতে পারে না, আপনি এখন আপনার ব্যবহারকারীদের সমস্যা তৈরি করছে এমন সমস্যা সমাধানের জন্য সময় ব্যয় করা ভাল।


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

0

প্রথমে পর্যবেক্ষণগুলি নথিভুক্ত করুন এবং পরে এটি ঠিক করবেন কিনা তা স্থির করুন।

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

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


0

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

  • দলটি এটি মূল্যায়ন করে। এটি কি সত্যিকারের বাগ, এটি সংশোধন করার ঝুঁকিগুলি কী।
  • পরিচালনা এই রিলিজটিতে এটি অন্তর্ভুক্ত করার সময়সূচী প্রভাব গ্রহণের পক্ষে যথেষ্ট গুরুত্বপূর্ণ কিনা তা সিদ্ধান্ত নিতে পারে
  • এটি সনাক্তকরণের জন্য একটি পদ্ধতি টেস্ট স্যুটে যুক্ত করা যেতে পারে, আশা করা যায় একই ধরণের ত্রুটিগুলি খুঁজে পাওয়ার জন্য যথেষ্ট সাধারণ উপায়।
  • এটি পূর্ববর্তী পর্যায়ে কতটি বাগ পিছলে যাচ্ছে সে সম্পর্কে মূল্যবান মেট্রিক সরবরাহ করে
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.