Technical debt, legacy code আর maintenance — Lehman-এর সূত্র আর পুরোনো কোড সামলানো

১ · ধার করা সময় — technical debt রূপকটি আসলে কী বলে

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

Software-এও ঠিক এমন হয়। ধরুন একটি কাল্পনিক কুরিয়ার কোম্পানির billing system (এই পর্বে নাম ধরে নিই “পার্সেলবাড়ি”)। ঈদের আগের সপ্তাহে নতুন COD চার্জ চালু করতে হবে। দলের হাতে দুই দিন। তাঁরা চার্জের হিসাব একটি if-এর ভেতরে hard-code করে দিলেন, test লিখলেন না, ভাবলেন পরে গুছাবেন। ঈদের ভিড় সামলানো গেল। এই শর্টকাটটিই technical debt.

খেয়াল করার বিষয়, Cunningham যা বোঝাতে চেয়েছিলেন, আর আজ অনেকে যা বোঝান, তার মধ্যে ফারাক আছে। পরে (প্রায় ২০০৯ সালে একটি ভিডিও আলোচনায়) তিনি ব্যাখ্যা করেন বলে সাধারণত উল্লেখ করা হয়: তিনি জেনেশুনে খারাপ কোড লেখার পক্ষে বলেননি। তাঁর কথা ছিল, শুরুর কোড লেখা হয় সমস্যার তখনকার বোঝাপড়া দিয়ে; ব্যবহার করতে করতে দল সমস্যাটি আরও ভালো বোঝে, আর তখন কোডকে সেই নতুন বোঝাপড়ার সাথে মিলিয়ে নিতে হয় — সেটাই শোধ। শর্ত একটাই: কোড এমন পরিষ্কার রাখতে হবে, যাতে পরে refactor করা যায়।

তাহলে debt কি খারাপ? না, ব্যবসার ঋণের মতো এটি একটি হাতিয়ার — ঈদের বাজার ধরা হয়তো দুই সপ্তাহের বাড়তি কাজের চেয়ে বেশি মূল্যবান। সমস্যা হয় যখন debt অদৃশ্য, তার সুদ অজানা, আর শোধের পরিকল্পনা নেই। পর্ব ১-এ (Software engineering কী) দেখেছেন, software-এর জীবনকালের খরচের বড় অংশ যায় maintenance-এ; জমে থাকা debt সেই খরচের একটি বড় চালক।

২ · Fowler-এর চতুর্ভুজ আর debt-এর রকমফের

Martin Fowler ২০০৯ সালে তাঁর website-এর একটি লেখায় debt-কে দুটি প্রশ্নে ভাগ করেন, যা technical debt quadrant নামে পরিচিত। প্রথম প্রশ্ন: debt কি জেনেশুনে (deliberate) নেওয়া, নাকি অজান্তে (inadvertent)? দ্বিতীয় প্রশ্ন: সিদ্ধান্তটি কি বিবেচক (prudent) — খরচ আর লাভ মেপে — নাকি বেপরোয়া (reckless)? নিচের ছবির উদাহরণ-বাক্যগুলো Fowler-এর লেখার ভাবানুবাদ।

এবার পার্সেলবাড়ির চারটি বাস্তব-ধাঁচের debt নিয়ে ঘর চিনে দেখি। প্রতিটি ধাপে দুটি প্রশ্নের উত্তর দেখুন, তারপর ঘর আর করণীয়।

Debt কোথায় কোথায় জমে

Debt শুধু অগোছালো কোডে নয়, software-এর প্রায় প্রতিটি স্তরে জমে। নিচের ভাগ প্রচলিত একটি রূপ; বইভেদে নাম ও ভাগ কিছুটা আলাদা।

৩ · Debt মাপা আর দেখা — hotspot, debt register আর remediation-এর অনুমান

সব debt একসাথে শোধ করা যায় না, করার দরকারও নেই। প্রশ্ন হলো, কোনটি আগে? সুদের সংজ্ঞাটি মনে করুন: সুদ দিতে হয় শুধু কোড ছুঁলে। তাই অগ্রাধিকারের দুটি প্রশ্ন: কোডটি কতটা জটিল, আর কতবার ছুঁতে হয়? যে file জটিল এবং ঘনঘন বদলায়, সেটি hotspot. এই ধারণা জনপ্রিয় করেছেন Adam Tornhill তাঁর Your Code as a Crime Scene (২০১৫; পরে নতুন সংস্করণ) বইয়ে — অপরাধ-বিশ্লেষণের মানচিত্রের মতো, কোড কোথায় “বারবার ঘটনা ঘটছে” তা খোঁজা।

বদলের হার (churn) জানার সবচেয়ে সৎ উৎস Git history নিজেই। নিচের transcript একটি ছোট scratch repository থেকে — পার্সেলবাড়ির ৮টি কাল্পনিক commit:

$ git log --oneline
a1f8340 fix: invoice total off by one taka
aba24d9 chore: zone names in Bangla
5e1be2f fix: express surcharge on Fridays
6e242b7 feat: monthly report
16f89f3 fix: COD fee for Dhaka
d5a618b feat: add new upazila zones
0bd7dd9 fix: hill zone weight rounding
9cdf2f2 feat: first version of courier billing

$ git log --format= --name-only | sort | uniq -c | sort -rn
      5 billing/tariff.py
      3 zones/zone_map.py
      3 billing/invoice.py
      1 reports/monthly.py
      1 notify/sms.py

$ git log --format= --name-only --since=2026-01-15T10:04 | sort | uniq -c | sort -rn
      2 billing/tariff.py
      1 zones/zone_map.py
      1 reports/monthly.py
      1 billing/invoice.py

$ git log --oneline -- billing/tariff.py
a1f8340 fix: invoice total off by one taka
5e1be2f fix: express surcharge on Fridays
16f89f3 fix: COD fee for Dhaka
0bd7dd9 fix: hill zone weight rounding
9cdf2f2 feat: first version of courier billing

শুধু churn যথেষ্ট নয় — একটি ছোট config file দিনে দশবার বদলালেও তাতে debt কম। তাই churn-কে জটিলতার সাথে মেলাতে হয়। জটিলতার মাপ হতে পারে লাইনের সংখ্যা, cyclomatic complexity-র যোগফল (বিস্তারিত পর্ব ৫০-এ), বা indentation-এর গভীরতা। নিচের খেলনা-বিশ্লেষণে ২০০টি কাল্পনিক commit একটি seeded PRNG দিয়ে বানানো, যাতে প্রতিবার একই ফল আসে:

// Hotspot = how often a file changes (churn) x how complex it is.
function mulberry32(a) {                       // small seeded PRNG
  return function () {
    a = (a + 0x6D2B79F5) | 0;
    let t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const rand = mulberry32(43);
const files = {   // file: [complexity (sum of cyclomatic complexity), change tendency]
  "billing/tariff.py": [96, 9], "billing/invoice.py": [41, 6], "zones/zone_map.py": [12, 7],
  "notify/sms.py": [18, 2], "reports/monthly.py": [88, 1], "core/utils.py": [25, 3],
  "auth/login.py": [30, 1] };
const names = Object.keys(files);
const totalW = names.reduce((s, f) => s + files[f][1], 0);
function pickFile() {                          // weighted random choice
  let r = rand() * totalW;
  for (const f of names) { r -= files[f][1]; if (r < 0) return f; }
  return names[names.length - 1];
}
const churn = Object.fromEntries(names.map(f => [f, 0]));
for (let c = 0; c < 200; c++) {                // 200 fake commits
  const touched = new Set();
  const k = 1 + Math.floor(rand() * 3);        // each touches 1 to 3 files
  for (let i = 0; i < k; i++) touched.add(pickFile());
  for (const f of touched) churn[f]++;
}
const maxC = Math.max(...names.map(f => churn[f])), maxX = Math.max(...names.map(f => files[f][0]));
const rows = names.map(f => ({ f, ch: churn[f], cx: files[f][0],
  score: (churn[f] / maxC) * (files[f][0] / maxX) }))   // both scaled to 0..1
  .sort((a, b) => b.score - a.score);
console.log("rank file                churn  cx score");
rows.forEach((r, i) => console.log(String(i + 1).padStart(4) + " " + r.f.padEnd(19) +
  String(r.ch).padStart(6) + String(r.cx).padStart(4) + "  " + r.score.toFixed(2)));

rank file                churn  cx score
   1 billing/tariff.py      95  96  1.00
   2 billing/invoice.py     63  41  0.28
   3 reports/monthly.py     16  88  0.15
   4 core/utils.py          46  25  0.13
   5 zones/zone_map.py      82  12  0.11
   6 auth/login.py          23  30  0.08
   7 notify/sms.py          26  18  0.05

Debt register — অদৃশ্য ঋণকে দৃশ্যমান করা

জেনেশুনে নেওয়া বা review-তে চোখে পড়া debt-এর হিসাব রাখতে হয় বাকির খাতার মতো একটি debt register — সাধারণত issue tracker-এ একটি label, বা repository-তে একটি file. পর্ব ৬২-এর risk register-এর সাথে এর মিল আছে: দুটোই অনিশ্চিত ভবিষ্যৎ খরচের তালিকা।

Tool-এর হিসাব — SQALE-ধাঁচের remediation অনুমান

Static analysis tool (পর্ব ৪৪-এ code review আর linter) প্রায়ই debt-কে সময়ে প্রকাশ করে। চিন্তাটি আসে SQALE পদ্ধতি থেকে (Jean-Louis Letouzey, ২০১০-এর দিকে): প্রতিটি নিয়ম-ভঙ্গের একটি remediation cost ধরে (যেমন “এই function ভাঙতে ২০ মিনিট”) সব যোগ করা। কিছু tool debt ratio-ও দেখায় = remediation cost ÷ কোডটি নতুন করে লেখার আনুমানিক খরচ।

একটি হিসাব দেখি (সব সংখ্যা ধরা যাক)। tariff.py-তে ১,২০০ লাইন। Tool বলছে remediation ৩ কর্মদিবস = ২৪ ঘণ্টা = ১,৪৪০ মিনিট। লেখার খরচ ধরা হলো প্রতি লাইনে ৩০ মিনিট (কিছু জনপ্রিয় tool-এ লেখার সময়ে এটিই ডিফল্ট মান বলে উল্লেখ আছে; tool-ভেদে আলাদা)। তাহলে লেখার খরচ = ১,২০০ × ৩০ = ৩৬,০০০ মিনিট, আর debt ratio = ১,৪৪০ ÷ ৩৬,০০০ = ০.০৪, অর্থাৎ ৪%. অনেক tool এমন ratio-কে ভালো rating দেয় — অথচ ওপরের hotspot বিশ্লেষণে এটিই সবচেয়ে বিপজ্জনক file!

৪ · সুদের হিসাব — কখন শোধ করা লাভজনক

Product owner জিজ্ঞেস করবেন, “৬০ ঘণ্টা refactoring-এ দিলে নতুন feature কবে আসবে?” প্রশ্নটি ন্যায্য। উত্তর দিতে হয় তাঁর ভাষায় — সময় আর টাকায়। সবচেয়ে সহজ মডেল: শোধ না করলে প্রতি বদলে বাড়তি h ঘণ্টা (সুদ); শোধ করলে একবার P ঘণ্টা (principal), তারপর প্রতি বদলে বাড়তি থাকে h′ ঘণ্টা (কিছু ঘর্ষণ থেকেই যায়)। মাসে r বার বদল হলে প্রতি মাসের সাশ্রয় r × (h − h′), আর

এই সূত্রে সুদ বাড়ে না ধরা হয়েছে। কিন্তু Lehman-এর দ্বিতীয় সূত্র (অংশ ৬) মনে করিয়ে দেয়, যত্ন না নিলে জটিলতা বাড়ে — তাই নিচের মডেলে সুদ প্রতি মাসে ৩% বাড়ে ধরা হয়েছে। প্রতিটি সংখ্যা ধরে নেওয়া; নিজের দলের সংখ্যা বসিয়ে চালিয়ে দেখুন।

// Technical-debt interest model. EVERY number here is an assumption.
const A = {
  changesPerMonth: 6,      // how often the team touches this module
  extraHoursPerChange: 4,  // interest: extra hours per change because of the debt
  hoursAfterPayback: 1,    // some friction remains even after the clean-up
  principal: 60,           // hours to refactor and add tests (paid in month 0)
  growth: 0.03 };          // interest grows 3% a month if the debt is left alone
function simulate(a, months) {
  let keep = 0, pay = a.principal, extra = a.extraHoursPerChange, even = null;
  const rows = [];
  for (let m = 1; m <= months; m++) {
    keep += a.changesPerMonth * extra;               // option 1: live with it
    pay += a.changesPerMonth * a.hoursAfterPayback;  // option 2: pay it down now
    extra *= 1 + a.growth;
    if (even === null && pay <= keep) even = m;
    rows.push([m, keep, pay]);
  }
  return { rows, even };
}
const r = simulate(A, 12);
for (const [m, k, p] of r.rows) if (m % 3 === 0 || m === r.even)
    console.log("month " + String(m).padStart(2) + ": keep debt " +
      k.toFixed(0).padStart(3) + " h | pay now " + p.toFixed(0).padStart(3) + " h");
console.log("break-even month:", r.even);
const saving = A.extraHoursPerChange - A.hoursAfterPayback;
console.log("no-growth formula:", (A.principal / (A.changesPerMonth * saving)).toFixed(2), "months");
for (const rate of [2, 0.5]) {
  const e = simulate({ ...A, changesPerMonth: rate }, 36).even;
  console.log("changes/month " + rate + " -> " + (e ? "break-even month " + e : "no break-even in 36 months"));
}

month  3: keep debt  74 h | pay now  78 h
month  4: keep debt 100 h | pay now  84 h
month  6: keep debt 155 h | pay now  96 h
month  9: keep debt 244 h | pay now 114 h
month 12: keep debt 341 h | pay now 132 h
break-even month: 4
no-growth formula: 3.33 months
changes/month 2 -> break-even month 9
changes/month 0.5 -> break-even month 25

৫ · Debt শোধের কৌশল — boy scout rule থেকে strangler fig

শোধের পদ্ধতি বাছাই হয় debt-এর আকার দেখে — ছোট debt প্রতিদিনের কাজে, বড় architecture debt মাসব্যাপী পরিকল্পনায়।

Strangler fig গাছ অন্য গাছের গায়ে জন্মায়, শিকড় নামিয়ে ধীরে ধীরে নিজেই দাঁড়িয়ে যায়, আর ভেতরের পুরোনো গাছটি একসময় মিলিয়ে যায় — পুরো সময় জুড়ে বনে একটি গাছ দাঁড়িয়েই থাকে। Software-এও তাই: মাঝপথের প্রতিটি দিনে system চালু থাকে। নিচের stepper-এ পার্সেলবাড়ির পুরোনো billing থেকে নতুন billing service-এ সরে যাওয়া দেখুন। Strangler fig-এর পাশাপাশি দুটি সহযোগী কৌশল কাজে লাগে: কোডের ভেতরে interface বসিয়ে বাস্তবায়ন বদলানো (branch by abstraction, পর্ব ১৭), আর পুরোনো মডেল যাতে নতুন কোডে চুইয়ে না ঢোকে সেজন্য anti-corruption layer (পর্ব ৪০, Clean আর hexagonal architecture).

পুরোটা নতুন করে লিখব? — rewrite বনাম refactor

পুরোনো কোড দেখে প্রায় সব developer-এর মনে হয়, “ফেলে দিয়ে শুরু থেকে লিখলে অনেক ভালো হবে।” Joel Spolsky ২০০০ সালে তাঁর বহুল পঠিত লেখা “Things You Should Never Do, Part I”-এ এই প্রলোভনকে software কোম্পানির সবচেয়ে বড় কৌশলগত ভুলগুলোর একটি বলেন; তাঁর উদাহরণ Netscape-এর browser নতুন করে লেখা, যার সময়ে বছর কয়েক নতুন বড় release আসেনি (ঘটনার ব্যাখ্যা নিয়ে ভিন্নমতও আছে)। মূল যুক্তি: পুরোনো কোডের অগোছালো লাইনগুলোর অনেকগুলো আসলে বছরের পর বছরের bug fix — নতুন করে লিখলে সেই জ্ঞান হারায়।

আরেকটি ফাঁদ পর্ব ২-এর (Software crisis আর software engineering-এর ইতিহাস) Brooks-এর second-system effect: rewrite প্রায়ই দ্বিতীয় system, তাই আগেরবার বাদ রাখা সব ইচ্ছা ঢুকে পড়ে। এদিকে পুরোনো system-এ চাহিদা আসতেই থাকে, নতুনটি চলমান লক্ষ্যের পেছনে দৌড়ায়।

তবু rewrite কখনো যুক্তিসংগত: platform মৃত (নিরাপত্তা-সমর্থন নেই), system ছোট আর আচরণ পুরো জানা, বা ব্যবসার মডেলই এত বদলেছে যে পুরোনো ধারণা আর খাটে না। তখনও নিরাপদ পথ সাধারণত অংশে অংশে প্রতিস্থাপন — পুরোটা একবারে (big-bang rewrite) নয়।

৬ · Maintenance-এর চার রকম আর Lehman-এর সূত্র

Technical debt যে প্রক্রিয়ায় জমে আর শোধ হয়, তার নাম maintenance. পর্ব ১-এ এর চারটি ভাগের নাম দেখেছেন; আন্তর্জাতিক মান ISO/IEC 14764 (প্রথম ১৯৯৯; পরে ২০০৬ আর ২০২২ সালে ISO/IEC/IEEE 14764 হিসেবে হালনাগাদ) এগুলোকে আনুষ্ঠানিক রূপ দেয়। ২০০৬-এর সংস্করণে চারটিকে দুটি দলে রাখা হয়: correction (corrective আর preventive) আর enhancement (adaptive আর perfective).

খেয়াল করুন, technical debt শোধ মূলত preventive maintenance. আর বহু জরিপে maintenance-এর বড় অংশ adaptive আর perfective — অর্থাৎ software-কে বাড়ানো, শুধু bug fix নয়। Adaptive-এর বিখ্যাত উদাহরণ Y2K (দুই অঙ্কের বছর), আর ১ জানুয়ারি ২০২০-এ Python 2-এর সমর্থন শেষ হওয়ায় অসংখ্য project-এর Python 3-এ সরে যাওয়া।

Lehman-এর software বিবর্তনের সূত্র

Meir M. (Manny) Lehman ১৯৬০-এর দশকের শেষ থেকে IBM-এর OS/360-এর release-গুলোর তথ্য বিশ্লেষণ করে লক্ষ করেন, বড় software একটি নিয়মিত ধাঁচে বদলায়। এই কাজে তাঁর প্রধান সহযোগী ছিলেন Laszlo Belady. এই সূত্রগুলো Lehman’s laws নামে পরিচিত। ১৯৭৪ সালে প্রথম তিনটি প্রকাশিত হয়, পরে আরও যোগ হয়; ১৯৯৬ নাগাদ সংখ্যাটি দাঁড়ায় আটে। সূত্রগুলো প্রযোজ্য E-type software-এ — যা বাস্তব জগতে ব্যবহৃত হয় আর বাস্তব জগতের অংশ হয়ে যায় (একটি billing system), গাণিতিকভাবে পুরো সংজ্ঞায়িত S-type প্রোগ্রামে (যেমন একটি sort function) নয়। নম্বর আর নামের ক্রম বিভিন্ন উৎসে সামান্য আলাদা; সাধারণত উদ্ধৃত রূপে প্রথম কয়েকটি:

1. Continuing change (ক্রমাগত পরিবর্তন): একটি E-type system-কে ক্রমাগত মানিয়ে নিতে হয়, নইলে সেটি ধীরে ধীরে কম সন্তোষজনক হয়ে পড়ে। পার্সেলবাড়ির কোড না বদলালেও জগৎ বদলায় — নতুন উপজেলা, নতুন আইন, নতুন ফোন।
2. Increasing complexity (ক্রমবর্ধমান জটিলতা): বিবর্তনের সাথে system-এর জটিলতা বাড়ে, যদি না তা ধরে রাখা বা কমানোর জন্য আলাদা কাজ করা হয়। এটিই technical debt-এর “প্রাকৃতিক নিয়ম” — refactoring budget সেই আলাদা কাজ।
3. Self-regulation (স্ব-নিয়ন্ত্রণ): বড় system-এর বিবর্তন প্রক্রিয়া নিজেই নিজেকে নিয়ন্ত্রণ করে; release-এর আকারের মতো মাপগুলো একটি গড়ের আশপাশে থাকে।
4. পরের সূত্রগুলো ১৯৮০ আর ১৯৯০-এর দশকে যোগ হয়, যেমন continuing growth (সন্তুষ্টি ধরে রাখতে কার্যক্ষমতা বাড়াতে হয়) আর declining quality (কঠোর যত্ন ছাড়া মান কমছে বলে মনে হবে)।

৭ · Legacy code — Feathers-এর সংজ্ঞা, seam আর characterization test

“Legacy” শুনলে মনে হয় বহু পুরোনো কোড, COBOL বা mainframe. কিন্তু Michael Feathers তাঁর ২০০৪ সালের বই Working Effectively with Legacy Code-এ একটি ধারালো সংজ্ঞা দেন: legacy code হলো test ছাড়া কোড। তাঁর যুক্তি: test না থাকলে আপনি জানতে পারবেন না বদলের পরে কোড আরও ভালো হলো না খারাপ; কোড যত সুন্দরই হোক, বদলানো ঝুঁকিপূর্ণ। এই সংজ্ঞায় গত মাসে লেখা test-হীন কোডও legacy code, আর দশ বছর পুরোনো কিন্তু ভালো test-সহ কোড নয়।

Feathers-এর দুটি মূল ধারণা। প্রথমটি seam: এমন জায়গা, যেখানে সেই জায়গার কোড না বদলেই আচরণ বদলানো যায় (যেমন test-এ আসল database-এর বদলে fake). Object-oriented কোডে সবচেয়ে সাধারণ seam হলো constructor বা parameter দিয়ে dependency পাঠানো — পর্ব ৩৭-এর (Dependency injection) কৌশল। যে function সরাসরি ঘড়ি (datetime.now()), database বা global পড়ে, তাকে test করতে আগে সেই নির্ভরতাকে parameter বানাতে হয়।

দ্বিতীয়টি characterization test: এমন test, যা কোডের উচিত আচরণ নয়, বর্তমান আচরণ লিখে রাখে। উদ্দেশ্য ভুল ধরা নয়, বদলের সময় আচরণ যাতে অজান্তে না বদলায় তা নিশ্চিত করা। নিচের stepper-এ পার্সেলবাড়ির পুরোনো চার্জ-হিসাবের function-এ একটি characterization test কীভাবে লেখা হয় দেখুন।

def charge_legacy(weight_g, zone, cod):
    c = 60
    if zone == "dhaka":
        ...   # ১৫ লাইনের জট
    if zone == "hill" and weight_g >= 5000:
        c = c - 5     # nobody remembers why
    return c

# database? না · ঘড়ি? না · global? না
charge_legacy(5000, "hill", True)   # সরাসরি ডাকা যায়

# যদি ভেতরে datetime.now() থাকত:
def charge(weight_g, zone, cod, today=None): ...

def test_hill_heavy_cod(self):
    self.assertEqual(charge_legacy(5000, "hill", True), 0)

FAIL: test_hill_heavy_cod
AssertionError: 295 != 0

def test_hill_heavy_cod(self):
    # characterizes current behaviour; the -5 hill
    # rule has unknown origin, see DEBT-7
    self.assertEqual(charge_legacy(5000, "hill", True), 295)

recorded 150 cases
charge_v1 -> 10 differences   # hill নিয়ম বাদ পড়েছে
charge_v2 -> 0 differences    # আচরণ অক্ষত

অনেক input-এর ফল একসাথে রেকর্ড করে রাখার কৌশলকে বলা হয় golden master (কাছাকাছি নাম: snapshot বা approval testing; নামের ব্যবহার সম্প্রদায়ভেদে আলাদা)। নিচের কোডে পুরো প্রক্রিয়াটি:

def charge_legacy(weight_g, zone, cod):        # 12 years old, no tests
    c = 60
    if zone == "dhaka":
        if weight_g > 1000:
            c = c + ((weight_g - 1) // 1000) * 15
    else:
        c = 110
        if weight_g > 500:
            c += ((weight_g - 501) // 500 + 1) * 20
    if cod:
        c = c + int(c * 0.01 + 0.5) if zone == "dhaka" else c + 10
    if zone == "hill" and weight_g >= 5000:
        c = c - 5                               # nobody remembers why
    return c
# 1) Characterize: record what the code DOES today (a golden master)
cases = [(w, z, cod) for w in range(0, 6001, 250)
         for z in ("dhaka", "outside", "hill") for cod in (False, True)]
golden = {case: charge_legacy(*case) for case in cases}
print("recorded", len(golden), "cases, e.g.", golden[(1250, "dhaka", True)],
      golden[(750, "outside", False)], golden[(5000, "hill", True)])

# 2) Refactor, then compare every case with the golden master
def charge_v1(weight_g, zone, cod):
    if zone == "dhaka":
        base = 60 + max(0, (weight_g - 1) // 1000) * 15
        return base + (int(base * 0.01 + 0.5) if cod else 0)
    base = 110 + max(0, -(-(weight_g - 500) // 500)) * 20   # ceiling
    return base + (10 if cod else 0)

def charge_v2(weight_g, zone, cod):
    hill_rebate = 5 if zone == "hill" and weight_g >= 5000 else 0
    return charge_v1(weight_g, zone, cod) - hill_rebate
for fn in (charge_v1, charge_v2):
    diffs = [(c, golden[c], fn(*c)) for c in cases if fn(*c) != golden[c]]
    print(fn.__name__, "->", len(diffs), "differences", diffs[:2])

recorded 150 cases, e.g. 76 130 295
charge_v1 -> 10 differences [((5000, 'hill', False), 285, 290), ((5000, 'hill', True), 295, 300)]
charge_v2 -> 0 differences []

৮ · পুরোনো কোডে নতুন কাজ — sprout, wrap আর অচেনা কোড পড়া

ধরুন DEBT-7 শোধের সময় এখনো আসেনি, কিন্তু কালই একটি নতুন চাহিদা: “২০ থেকে ৩১ মার্চ ঈদ-অভিযানে কাপড়ের পণ্যে ১০% ছাড়, সর্বোচ্চ ২০০ টাকা।” Invoice তৈরির পুরোনো function জটিল, test নেই, আর পুরোটার characterization করতে কয়েক দিন লাগবে। Feathers-এর পরামর্শ: পুরোনো জটের ভেতরে নতুন লজিক মেশাবেন না। নতুন কাজটি আলাদা, ছোট, test-সহ একটি function-এ লিখুন, আর পুরোনো function থেকে শুধু এক লাইনে ডাকুন। একে বলে sprout method — পুরোনো গাছ থেকে নতুন অঙ্কুর।

import unittest

def build_invoice(order):                       # legacy: tangled, no tests
    total = 0
    for name, cat, qty, price in order["lines"]:
        if cat == "food" and qty > 10:
            price = price - 2                   # old bulk rule
        total += qty * price
    if order.get("member"):
        total = total - total // 20             # 5% member discount
    total -= campaign_discount(order["lines"], order["day"])  # the ONLY new line
    total += 0 if total >= 1000 else 60         # delivery charge
    return total

def campaign_discount(lines, day):              # sprouted: new, small, tested
    if not ("2026-03-20" <= day <= "2026-03-31"):    # ISO dates compare as text
        return 0
    clothing = sum(q * p for _, cat, q, p in lines if cat == "clothing")
    return min(clothing // 10, 200)             # 10%, at most 200 taka

class CampaignDiscountTest(unittest.TestCase):
    L = [("panjabi", "clothing", 1, 1500), ("dates", "food", 2, 300)]
    def test_ten_percent_of_clothing(self):
        self.assertEqual(campaign_discount(self.L, "2026-03-25"), 150)
    def test_capped_at_200(self):
        self.assertEqual(campaign_discount([("saree", "clothing", 1, 5000)], "2026-03-25"), 200)
    def test_outside_campaign(self):
        self.assertEqual(campaign_discount(self.L, "2026-04-02"), 0)

result = unittest.TestResult()
unittest.defaultTestLoader.loadTestsFromTestCase(CampaignDiscountTest).run(result)
print("tests run:", result.testsRun, "| failures:", len(result.failures), "| errors:", len(result.errors))
order = {"lines": CampaignDiscountTest.L, "member": True, "day": "2026-03-25"}
print("invoice in campaign:", build_invoice(order))
print("invoice after campaign:", build_invoice({**order, "day": "2026-04-02"}))

tests run: 3 | failures: 0 | errors: 0
invoice in campaign: 1845
invoice after campaign: 1995

একই পরিবারের আরও তিনটি কৌশল:

• Sprout class: নতুন কাজের জন্য পুরো একটি নতুন class, যখন পুরোনো class-টি test-এর মধ্যে আনাই কঠিন (যেমন constructor database-এ যুক্ত হয়)। নতুন class-কে পুরোনোটি শুধু তৈরি করে ডাকে।
• Wrap method: নতুন আচরণ যখন পুরোনো কাজের আগে বা পরে ঘটবে (যেমন প্রতিটি invoice তৈরির পরে SMS). পুরোনো method-এর নাম বদলে (build_invoice_core), একই নামে নতুন method বানানো হয়, যা পুরোনোটিকে ডেকে তারপর নতুন কাজ করে। ডাকা কোড কিছুই টের পায় না।
• Wrap class: একই চিন্তা class-এর স্তরে — বাইরে থেকে একটি wrapper, যা আসলে decorator pattern (পর্ব ৩৪)।

Feathers-এর বড় প্রক্রিয়াটি মোটামুটি এমন: বদলের জায়গা চিহ্নিত → test-এর জায়গা খোঁজা → dependency ভেঙে seam খোলা → test লেখা → বদল আর refactor. Sprout আর wrap সেই অবস্থার জন্য, যখন পুরো test-জাল বোনার সময় নেই — অন্তত নতুন কোডটুকু শুরু থেকেই test-সহ থাকুক।

অচেনা কোড পড়ার একটি পদ্ধতি

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

1. Build আর চালানো: README, build script আর CI configuration — না চললে সবাই সাথে সাথে টের পান, তাই এগুলোই সবচেয়ে হালনাগাদ “documentation”.
2. Entry point: main, web-এর route তালিকা, cron job, message-এর consumer — বাইরের জগৎ কোথা দিয়ে কোডে ঢোকে, সেই দরজাগুলোর তালিকা করুন।
3. Test: থাকলে test-ই সবচেয়ে ভালো উদাহরণ — কোন input-এ কী output আশা করা হয়। না থাকলে সেটিই প্রথম তথ্য (legacy!)।
4. Git history: git log --oneline -- <file>, ওপরের churn command, git shortlog -sn (কে বেশি কাজ করেছেন — কাকে জিজ্ঞেস করবেন)। একটি লাইন কেন এমন, তা খুঁজতে git blame আর git log -S — বিস্তারিত পর্ব ৫৫-এ।
5. Scratch refactoring: বোঝার জন্য একটি আলাদা branch-এ নির্ভয়ে নাম বদলান, function ভাঙুন — তারপর পুরোটা ফেলে দিন। Feathers এই কৌশলের কথা বলেন: উদ্দেশ্য কোড বদলানো নয়, বোঝা।

৯ · Dependency upgrade আর deprecation — বাইরের কোডের debt

আধুনিক project-এর কোডের বড় অংশ আপনার লেখা নয় — package manager দিয়ে আনা library. এক version পিছিয়ে থাকা সহজে সামলানো যায়; পাঁচ major version পিছিয়ে থাকলে upgrade নিজেই একটি project. এটিই dependency debt, আর এর সুদ শুধু সময়ে নয় — নিরাপত্তায়ও।

দুটি বহুল আলোচিত ঘটনা (বিস্তারিত ভাবনার প্রশ্ন ৪-এ): ২০১৭ সালে Equifax-এর data ফাঁসে সরকারি তদন্তে Apache Struts-এর এমন একটি ত্রুটির কথা বলা হয়, যার patch কয়েক মাস আগেই প্রকাশিত হয়েছিল; আর ২০২১ সালের ডিসেম্বরে Log4j-এর “Log4Shell” প্রকাশের পর বহু প্রতিষ্ঠানের প্রথম প্রশ্নই ছিল — “আমাদের কোথায়, কোন version-এ Log4j আছে?” যাঁদের dependency-র তালিকা (SBOM — software bill of materials) ছিল, তাঁরা দ্রুত উত্তর পেয়েছিলেন।

নিরাপদ upgrade-এর অভ্যাস

• ছোট আর ঘনঘন: প্রতি মাসে অল্প upgrade, বছরে একবার বিশাল লাফ নয়। Dependabot বা Renovate-এর মতো tool (লেখার সময়ে; platform-ভেদে আলাদা) নিজে upgrade-এর pull request খোলে, CI পাস করলে review করে merge.
• এক major করে: ২.x থেকে সরাসরি ৫.x নয়; ৩, ৪, ৫ — প্রতিটির changelog আর migration guide পড়ে। SemVer-এ MAJOR মানে breaking change (পর্ব ১৮), তবে সব library SemVer কঠোরভাবে মানে না।
• Deprecation warning-কে debt হিসেবে ধরা: এখনই সারালে সস্তা। Python-এ -W error::DeprecationWarning দিয়ে test চালালে এমন warning error হয়ে ধরা পড়ে।
• Lockfile commit করা: যাতে সবার যন্ত্রে আর CI-তে ঠিক একই version থাকে, আর upgrade হয় সচেতন একটি commit-এ — যা দরকার হলে revert করা যায়।
• Support-এর মেয়াদ জানা: ভাষা, framework আর OS-এর end-of-life তারিখ debt register-এ রাখুন। শেষ মাসের জন্য রেখে দিলে সেটিই বেপরোয়া debt.

আপনি নিজে যখন library বা API-র মালিক, তখন দায়িত্ব উল্টো দিকের: পুরোনো রূপ হঠাৎ সরিয়ে দেবেন না। নতুন রূপ পাশাপাশি দিন, পুরোনোটিকে deprecated ঘোষণা করুন, তারপর পরের major version-এ সরান — পর্ব ৩১-এর (Interface আর contract) parallel change-এর ধারা।

১০ · AI-এর যুগে — পুরোনো কোডে AI-কে সাথে নেওয়া

Legacy code-এ AI কাজের সঙ্গী হতে পারে: অচেনা function ব্যাখ্যা, characterization test-এর input-এর তালিকা, পুরোনো framework থেকে অনুবাদের খসড়া। কিন্তু পুরোনো কোডের আসল সম্পদ তার লুকানো আচরণ — আর AI সেটাই সবচেয়ে সহজে মুছে দেয়, কারণ তার চোখে “অদ্ভুত” লাইন মানেই ভুল।

AI-এর সাহায্যে legacy code বদলানোর আগে — চেকলিস্ট

• বদলের আগে characterization test বা golden master আছে, আর সেটি আসল কোডে চালিয়ে বানানো
• AI-এর refactor-এর পরে সব রেকর্ড করা ক্ষেত্র মিলেছে; অমিল থাকলে প্রতিটির কারণ জানি
• AI যে “অদ্ভুত” নিয়ম বদলাতে চেয়েছে, সেগুলো debt register-এ তুলেছি; বদল হবে জেনেশুনে, আলাদা commit-এ
• Git বা package manager-এর যেকোনো command আগে একটি throwaway clone-এ চালিয়েছি, আর git help বা অফিসিয়াল doc-এ flag মিলিয়েছি
• Diff নিজে লাইন ধরে পড়েছি; বড় diff হলে ছোট ধাপে ভাগ করতে বলেছি
• Prompt-এ কোনো secret, গ্রাহকের data বা অনুমতিহীন কোড পাঠাইনি; AI-এর দেওয়া কোডের লাইসেন্স-প্রশ্ন ভেবেছি