টেক ডেট ক্যালকুলেশন: বেগ-ভিত্তিক বনাম। ইস্যু-ভিত্তিক বনাম গুণমান-ভিত্তিক পরিমাপ ব্যাখ্যা করা হয়েছে

সুদের হার বেড়েছে ১৫৭%!

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

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

একটি নতুন রিলিজের অংশ হিসাবে যে নতুন প্রযুক্তি ঋণটি চালু করা হয়েছে তা সুদের হার বৃদ্ধি এবং ভবিষ্যতে দলটির মুখোমুখি হওয়া মন্দা বাড়ানো হিসাবে ভাবা যেতে পারে।

(আমি অনুমান করতে যাচ্ছি আপনি এখানে প্রযুক্তিগত ঋণের ধারণার সাথে মোটামুটি পরিচিত, কিন্তু যদি আপনার গতি বাড়াতে একটি রিফ্রেশার প্রয়োজন হয় তবে এখানে একটি দ্রুত প্রাইমার )

ঠিক আছে, আপনি সম্ভবত একজন ইঞ্জিনিয়ারিং ম্যানেজারকে তাদের প্রযুক্তিগত ঋণ সম্পর্কে এইরকম কথা বলতে শুনবেন না।

কিন্তু কেন না?

আপনার চলমান প্রভাব পরিমাপ এবং পরিমাপ করতে সক্ষম হচ্ছে প্রযুক্তি ঋণ সমালোচনামূলক আপনি যদি এটি মোকাবেলা করার জন্য একটি কর্মযোগ্য পরিকল্পনা একত্রিত করতে চান।

যখন আমরা প্রযুক্তিগত ঋণের কথা চিন্তা করি, তখন সুদ হল আপনার বর্তমান এবং ভবিষ্যত উন্নয়নে আপনার বিদ্যমান প্রযুক্তিগত ঋণের স্তরে হারিয়ে যাওয়া সময়ের পরিমাণ।

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

প্রযুক্তিগত ঋণের একটি স্বাস্থ্যকর স্তর কি?

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

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

এর মানে হল যে আমাদের প্রযুক্তি ঋণের স্তরটি সম্বোধন করার মতো নয় যদি:

উদাহরণস্বরূপ: যদি আমাদের কাছে একটি ছোট প্রকল্প থাকে যা আমরা জানতাম যে প্রযুক্তির ঋণ আছে যা আমাদের 2 ঘন্টা/সপ্তাহের গতি কমিয়ে দেয়, তাহলে সেই ঋণটি রিফ্যাক্টর করতে আমাদের 4 দিন সময় লাগবে এবং 3 মাসের প্রভাবের ব্যবধানের বিষয়ে আমরা চিন্তা করব না এখনও সেই ঋণ পরিশোধ করতে সময় ব্যয় করুন।

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

আমরা কিভাবে প্রযুক্তিগত ঋণ পরিমাপ করব?

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

বেগ ভিত্তিক পরিমাপ

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

উদাহরণস্বরূপ: যদি আমাদের কাছে 4টি ভিন্ন ক্ষেত্র সহ একটি অপেক্ষাকৃত সহজ প্রকল্প থাকে যেটিতে আমরা কাজ করব তবে আমরা দেখতে পারি যে সময়ের সাথে সাথে বেগ কীভাবে পরিবর্তিত হয় (এখানে আমরা গল্পের পয়েন্ট/ডেভেলপার মাসে বেগ ট্র্যাক করছি)।

প্রযুক্তিগত ঋণের প্রভাবের বেগ ভিত্তিক পরিমাপ

এখান থেকে আমরা দেখতে পাচ্ছি যে একই রকম জটিল কাজের জন্য অন্যান্য ক্ষেত্রের মতো কাজ করতে D সবসময় ~3x সময় নিয়েছে। এটি বোঝায় যে কোডবেসের অন্যান্য বিভাগগুলির মতো এটির 3 গুণ আগ্রহ রয়েছে৷ B তুলনামূলকভাবে A & C এর সাথে সমান ছিল, কিন্তু 4 মাস থেকে শুরু করে হঠাৎ করে 2x সময় লাগতে পারে। এটি পরামর্শ দেয় যে আমরা এখানে কিছু ঋণ প্রবর্তন করেছি যা আমাদের সুদের হারকে দ্বিগুণ করেছে বনাম এটি B এর আগে যা ছিল।

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

বেগ ভিত্তিক পরিমাপের ক্ষেত্রে চিন্তা করার জন্য কিছু গুরুত্বপূর্ণ সতর্কতা রয়েছে।

• বেগ অস্থির হতে পারে এবং নতুন (বা বিদ্যমান) বাগ, ভুল-সংযুক্ত অনুমান, প্রযুক্তিগত প্রতিবন্ধকতা, বা বহিরাগত প্রকল্প বিলম্বের মতো প্রযুক্তিগত ঋণ থেকে স্বাধীন কারণগুলির উপর নির্ভর করতে পারে।

• অনুমানগুলির অন্তর্নিহিত অনিশ্চয়তার একটি স্তর রয়েছে এবং এটি শুরু করার জন্য একটি ভুল পরিমাপ হতে পারে।

• এই ডেটা সংগ্রহ করা এবং বিশ্লেষণ করা কঠিন এবং সময়সাপেক্ষ হতে পারে।

  
  

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

ইস্যু ভিত্তিক পরিমাপ

একটি ভিন্ন পদ্ধতি হ'ল আপনার প্রকল্পের মধ্যে প্রযুক্তিগত ঋণের নির্দিষ্ট উদাহরণগুলি সনাক্ত করা এবং অনুমান করা যে সেগুলি আপনাকে কতটা ধীর করে দিচ্ছে। এটির একটি অংশ স্বয়ংক্রিয় সরঞ্জামগুলি ব্যবহার করে করা যেতে পারে, যেমন স্ট্যাটিক অ্যানালাইসিস টুলস, কোড মানের আশেপাশে সাধারণ সমস্যাগুলি খুঁজে বের করার জন্য যা একটি প্রকল্পের পাঠযোগ্যতা, প্রসারিতযোগ্যতা বা রক্ষণাবেক্ষণের উপর প্রভাব ফেলতে পারে। এই ধরনের সমস্যা মোকাবেলায় আপনার দলের অভিজ্ঞতার উপর ভিত্তি করে প্রতিটি ধরনের সমস্যার জন্য আপনি সুদের খরচ (যেমন 5 মিনিট/সপ্তাহ বা 1%) নির্ধারণ করতে পারেন।

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

এই পদ্ধতির কিছু অসুবিধা হল:

• নির্দিষ্ট সমস্যার সাথে আবদ্ধ সময়ের অনুমান ভুল হতে পারে
• কিছু সমস্যা দীর্ঘ সময়ের জন্য সহজেই সনাক্ত করা যায় না

গুণমান ভিত্তিক পরিমাপ

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

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

একটি উদাহরণের দিকে তাকিয়ে - আসুন আমরা বেগ ভিত্তিক পরিমাপের বিভাগে যে সহজ 4 অংশের কোডবেসটি দেখেছি তা আবার দেখুন।

আমরা টেবিলে এই প্রকল্পের সমস্যা বিভাগগুলি সহজেই দেখতে পারি (লাল রঙে হাইলাইট করা হয়েছে) এবং সুদের অনুমান গণনা করা তুলনামূলকভাবে সহজ - সহজভাবে বিভিন্ন উপাদানের সুদের প্রভাবগুলি যোগ করুন৷

এই পদ্ধতির কিছু অসুবিধা হল:

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

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

কোডবেস ইন্টারঅ্যাকশন ফ্রিকোয়েন্সি দেখছি

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

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

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

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

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

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

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

সুদ ও ঋণ ব্যবস্থাপনা

চলমান ভিত্তিতে আমাদের প্রযুক্তিগত ঋণ আমাদেরকে কতটা প্রভাবিত করছে তার হিসাব করার জন্য আমরা কয়েকটি ভিন্ন উপায় দেখেছি, কিন্তু প্রযুক্তিগত ঋণের একটি স্বাস্থ্যকর স্তর কী সে সম্পর্কে আমরা সম্পূর্ণভাবে উত্তর দিতে পারিনি।

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

যেমনটি আমরা আগে আলোচনা করেছি আমরা সাধারণত কোডবেসের ক্ষেত্রগুলিকে সম্বোধন করতে সময় ব্যয় করতে চাই না যেখানে:

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

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