একটি "কোড উন্নতি" এর অগ্রাধিকার এবং তীব্রতা কীভাবে নির্ধারণ করবেন?


15

আমাদের বাগ ট্র্যাকিং সিস্টেমে আমাদের "অগ্রাধিকার" এবং "তীব্রতা" ক্ষেত্র রয়েছে। আমরা তীব্রতাটিকে "এটি ব্যবহারকারীকে কীভাবে প্রভাবিত করে" এবং অগ্রাধিকারটিকে "এটি কীভাবে পণ্যকে প্রভাবিত করে" হিসাবে সংজ্ঞা দেয়।

আমার প্রশ্নটি কীভাবে তীব্রতা এবং অগ্রাধিকারে "কোড উন্নতি" টাস্ককে শ্রেণিবদ্ধ করা যায় সে সম্পর্কে। মনে করুন উন্নতি কোনও আচরণ পরিবর্তন করে না তবে এটি একটি "আরও ভাল কোড" হিসাবে পরিণত করে। আমরা সামগ্রিকভাবে দীর্ঘমেয়াদী রক্ষণাবেক্ষণের উন্নতি প্রত্যাশা করি তবে এর পরিমাণ নির্ধারণ করা শক্ত।

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

তবে আমি বিশ্বাস করি যে এই কোডটি ক্রমাগত উন্নত করা এবং পুনরায় সংশোধন করা খাঁটি কারণ, কারণ:

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

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

উত্তর:


16

সাধারণত আমি "কোড উন্নতি" ক্রিয়াকলাপগুলিকে পৃথক কার্যনির্বাহযোগ্য টাস্ক হিসাবে দেখতে পছন্দ করি না কারণ কোড উন্নতি নিজেই আপনাকে কখনই ব্যবহারকারীর গল্প বা প্রয়োজনীয়তা সমাপ্ত করার কাছাকাছি নিয়ে আসে না। এজন্য কোড উন্নয়নের কাজগুলি সর্বদা এমন নিম্ন অগ্রাধিকার হিসাবে থাকবে যে তারা কখনই বরাদ্দ পায় না।

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

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


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

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

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

1
+1 বিশেষত "যদি আমার কাজটি যদি আমার সাথে কোনও শ্রেণি বা এমন কোনও উত্স কোড স্পর্শ করতে জড়িত থাকে যা দীর্ঘ সময় দেখেনি"। আপনার কেবলমাত্র কোডটি উন্নত করা উচিত যা পরিবর্তন করা দরকার। যদি আসন্নভাবে এটি পরিবর্তন করার প্রয়োজন না হয় তবে এটি একা ছেড়ে যান।
মার্কজে

1
বিশেষত বড় প্রকল্প এবং দলগুলির জন্য, কোডের উন্নতিটিকে একটি পৃথক কাজ হিসাবে ধরে রাখা এখনও বোধগম্য - একটি নতুন বিকাশকারী কোনও নতুন বৈশিষ্ট্যটিতে কাজ করার সময় কেবলমাত্র একমাত্র বিকাশকারী যেতে পারে।
ব্লুবেরিফিল্ডস

2

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

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


2
যে যোগ করার জন্য, প্রযুক্তিগত ঋণ (refactoring অভাব থেকে) করে পণ্যের প্রভাব, কারণ এটি কঠিন হয়ে বজায় রাখা এবং বাগ প্রবর্তন আরো সম্ভাবনা রয়েছে। একবার পণ্যটির প্রভাব পড়লে, ব্যবহারকারী প্রভাবিত হয় ... আমাদের দলে, আমাদের "উন্নতি" কাজগুলি রয়েছে যা আমরা রিফ্যাক্টরিং, এবং প্রক্রিয়া / সরঞ্জাম উন্নতির জন্য ব্যবহার করি
আতিফ

2

যা অনুপস্থিত তা বিদ্যমান কোড সম্পর্কে আপনার অনুমানগুলি যাচাই করছে: আমরা কোডটি উন্নত করলে কম সময় এবং উল্লেখযোগ্য সঞ্চয়ী অর্জন করা যায়। এই প্রসাধনী বা গুরুতর সমস্যা আছে?

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

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


1

আকর্ষণীয় প্রশ্ন।

আমি মনে করি আপনি কোডটি কত লাইন এবং একটি পরিবর্তন প্রভাবিত করতে পারে যে কতগুলি মডিউল।

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

তারপরে এই মেলে স্তরের অগ্রাধিকার এবং তীব্রতার জন্য প্রান্তিকতা রয়েছে।

আপনার অ্যাকাউন্টেও নেওয়া উচিত অনেক পরীক্ষক পরীক্ষার জড়িত থাকতে হবে। যদি পরিবর্তনটি অ্যাপ্লিকেশনের বৃহত পৃষ্ঠের স্পর্শ করে তবে প্রচুর সিস্টেম পরীক্ষার পুনর্বিবেচনার প্রয়োজন হতে পারে।


1

এখানে দুটি অনুমান দিয়ে শুরু করা যাক।

  1. প্রতিটি নতুন গল্পের জন্য, আপনি নিজের কোডটি আপনার দক্ষতার সেরাটিতে লিখেছেন, সম্ভবত আপনার দলের পরিবেষ্টিত জ্ঞানের সাহায্যে ছড়িয়ে দিয়েছেন।
  2. যখনই আপনার কাছে এমন কোনও গল্প রয়েছে যা বিদ্যমান কোডের কার্যকারিতা পরিবর্তন করে, আপনি নতুন কাহিনী বাস্তবায়নের প্রক্রিয়াতে কোডটি উন্নত করার জন্য সিস্টেম সম্পর্কে আপনার নতুন জ্ঞান এবং আরও ভাল দক্ষতা ব্যবহার করেন।

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


1

আমি চপল আন্দোলন থেকে ভোট চুরি করব:

বাগটি প্রবেশ করান, তীব্রতা এবং অগ্রাধিকারের জন্য মোটামুটি অনুমান করুন,

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

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