Code smell আর refactoring — ছোট নিরাপদ ধাপে কোড উন্নত করা

১ · Refactoring কী — আচরণ একই, ভেতরটা পরিষ্কার

পর্ব ৪১-এ দেখেছেন পরিষ্কার কোড দেখতে কেমন — ভালো নাম, ছোট function, অর্থপূর্ণ comment. কিন্তু কোড ছয় মাস পরে আর পরিষ্কার থাকে না: তাড়াহুড়োয় একটি if যোগ হয়, কেউ একটি function কপি করে সামান্য বদলান। চলমান কোডকে কিছু না ভেঙে আবার পরিষ্কার করার পদ্ধতিই refactoring.

Martin Fowler তাঁর Refactoring: Improving the Design of Existing Code বইয়ে (প্রথম সংস্করণ ১৯৯৯, উদাহরণ Java-তে; দ্বিতীয় সংস্করণ ২০১৮, উদাহরণ JavaScript-এ) শব্দটির দুটি রূপ দেন। বিশেষ্য হিসেবে refactoring হলো “software-এর ভেতরের কাঠামোয় এমন একটি বদল, যা একে বোঝা সহজ আর বদলানো সস্তা করে, কিন্তু এর observable behaviour বদলায় না।” ক্রিয়া হিসেবে refactor করা মানে এমন অনেকগুলো ছোট refactoring পরপর প্রয়োগ করে কাঠামো নতুন করে সাজানো। দুটি শব্দ খেয়াল করার মতো: ভেতরের কাঠামো (বাইরের চুক্তি নয়) আর observable — যা বাইরে থেকে দেখা যায়: ফেরত মান, screen-এর লেখা, file বা database-এ লেখা, ছোড়া error.

শব্দটি ফাউলারের আবিষ্কার নয়। “Refactoring” কথাটি ১৯৮০-র দশকের শেষে Smalltalk সম্প্রদায়ে চালু ছিল বলে ধরা হয়, আর এর প্রথম পূর্ণাঙ্গ গবেষণা হিসেবে সাধারণত উল্লেখ করা হয় William Opdyke-এর ১৯৯২ সালের PhD থিসিস (University of Illinois at Urbana-Champaign, তত্ত্বাবধায়ক Ralph Johnson — Gang of Four-এর চারজনের একজন)। Opdyke দেখান, কোন কোন শর্ত মানলে একটি কাঠামোগত বদল প্রমাণযোগ্যভাবে আচরণ রক্ষা করে। একই বিশ্ববিদ্যালয়ে John Brant আর Don Roberts Smalltalk-এর জন্য Refactoring Browser বানান — automated refactoring-এর প্রথম দিকের প্রভাবশালী tool. Fowler-এর অবদান ছিল এই জ্ঞানকে একটি catalog-এ সাজানো: প্রতিটি refactoring-এর নাম, কখন দরকার, আর ধাপে ধাপে কীভাবে (mechanics). পর্ব ৫-এর Extreme Programming (XP) refactoring-কে প্রতিদিনের অভ্যাস বানায়।

কোনটি refactoring, কোনটি নয়

“আচরণ” কী, তা প্রসঙ্গ ঠিক করে। গতি সাধারণত observable behaviour ধরা হয় না, কিন্তু real-time system-এ গতিও চুক্তির অংশ। একটি public library-র function-এর নাম নিজেই চুক্তি (বদলালে ব্যবহারকারীর কোড ভাঙে), অথচ private helper-এর নাম কারও চুক্তি নয়।

২ · নিরাপত্তার জাল — আগে test, তারপর ছোট ধাপ, প্রতিটির পর commit

Refactoring-এর সংজ্ঞায় একটি প্রতিশ্রুতি আছে — আচরণ বদলাবে না। সেই প্রতিশ্রুতি রক্ষা হলো কি না, চোখে দেখে বলা যায় না; যাচাই করতে হয়। তাই Fowler-এর নিয়ম সরল: refactoring শুরুর আগে নিশ্চিত হোন যে কোডটির জন্য এমন test আছে, যা নিজে নিজে চলে আর নিজেই বলে পাস না ফেল (self-checking). Test আপনার নিরাপত্তার জাল — সার্কাসের দড়ির নিচের জালের মতো, যা থাকলে শিল্পী সাহস করে নতুন কৌশল চেষ্টা করেন।

পুরোনো কোডে test না থাকলে প্রথম কাজ হলো বর্তমান আচরণ ধরে রাখা — ঠিক হোক বা ভুল। এমন test-কে বলে characterization test; আর পুরো আউটপুট একবার সংরক্ষণ করে প্রতিবার হুবহু মেলালে তাকে অনেকে golden master test বলেন। পুরোনো, test-হীন কোডে কীভাবে প্রথম test বসাবেন, কোথায় “seam” খুঁজবেন — সেই কৌশল পর্ব ৪৩-এ। Test-এর গঠন (Arrange-Act-Assert) পর্ব ৪৬-এ, আর red-green-refactor চক্রে refactoring কোথায় বসে, তা পর্ব ৪৮-এ।

ছোট ধাপের ছন্দ

1. সবুজ থেকে শুরু: সব test পাস করছে, working tree পরিষ্কার (git status-এ কিছু নেই — পর্ব ৮)।
2. একটি ছোট refactoring: একটি rename, একটি extract — এমন বদল যা এক মিনিটে বুঝিয়ে বলা যায়।
3. Test চালানো: সবুজ হলে commit; লাল হলে বদলটি ফেলে দিয়ে শেষ সবুজ commit-এ ফেরা (git restore, পর্ব ১১)। ভুল খোঁজার চেয়ে ফেলে দিয়ে আরও ছোট ধাপে আবার করা প্রায়ই দ্রুত।
4. আবার: পরের ছোট ধাপ। ছোট commit পরে চাইলে interactive rebase দিয়ে মেলানো যায় (পর্ব ১৫) — ভাঙার চেয়ে মেলানো সহজ।

নিচের stepper-এ একটি “নিরীহ” বদল দেখুন: একটি কাল্পনিক অনলাইন বাজারের invoice-এ দুটি লাইনের ক্রম বদল (Slide Statements — লাইন ওপরে-নিচে সরানো)। পুরোনো test সবুজ থাকে, অথচ আচরণ বদলে গেছে — ধরা পড়ে কেবল সীমানার কাছের একটি test-এ।

1// আগে: আসল ক্রম2let t = sum(lines);3if (coupon && t > 1000) t -= 100;4t += deliveryFee(zone);5// পরে: "শুধু সাজানো"6let t = sum(lines);7t += deliveryFee(zone);8if (coupon && t > 1000) t -= 100;

৩ · Code smell — কোডের “গন্ধ” আর পাঁচটি দল

কোন কোড refactor করবেন? Fowler-এর বইয়ের তৃতীয় অধ্যায়, Kent Beck আর Fowler-এর যৌথ লেখা “Bad Smells in Code”, এর উত্তর দেয় একটি রূপক দিয়ে: code smell. শব্দটি Kent Beck-এর দেওয়া বলে Fowler নিজে উল্লেখ করেছেন। রান্নাঘর থেকে পোড়া গন্ধ এলে আপনি জানেন না ঠিক কী পুড়ছে — ভাত, না তরকারি — কিন্তু জানেন যে গিয়ে দেখতে হবে। Smell তেমনই: একটি উপরিতলের লক্ষণ, যা প্রায়ই গভীর সমস্যার ইঙ্গিত দেয়। লক্ষণ মানেই ভুল নয়; একটি ২০ লাইনের function একটি জটিল algorithm-এর জন্য একদম ঠিক হতে পারে। Smell শুধু বলে “এখানে একবার তাকান।”

বইয়ে smell-গুলো একটি লম্বা তালিকা (প্রথম সংস্করণে ২২টি, দ্বিতীয় সংস্করণে ২৪টি, আমাদের জানামতে)। এগুলোকে পাঁচটি দলে ভাগ করার জনপ্রিয় রীতিটি Fowler-এর নয় — Mika Mäntylä ও সহকর্মীদের ২০০৩ সালের একটি গবেষণাপত্র থেকে আসে বলে সাধারণত উল্লেখ করা হয়, আর পরে অনলাইন শিক্ষার সাইটগুলো এটি ছড়ায়। দলগুলো মনে রাখার জন্য সুবিধাজনক; পরীক্ষায় কেউ ভিন্ন ভাগ লিখলে সেটিও ভুল নয়। নাম নিয়েও একটি সতর্কতা: দ্বিতীয় সংস্করণে কয়েকটি নাম বদলেছে — Long Method হয়েছে Long Function, Switch Statements হয়েছে Repeated Switches, Lazy Class হয়েছে Lazy Element, আর Inappropriate Intimacy-র জায়গায় এসেছে Insider Trading; নতুন যোগ হয়েছে Mysterious Name, Global Data, Mutable Data আর Loops.

কয়েকটি জোড়া বিশেষ করে খেয়াল করুন, কারণ পরীক্ষায় এগুলো গুলিয়ে যায়। Divergent change আর shotgun surgery একই মুদ্রার দুই পিঠ: প্রথমটিতে এক module অনেক কারণে বদলায় (কম cohesion, পর্ব ২৭-এর SRP-র লঙ্ঘন); দ্বিতীয়টিতে এক কারণে অনেক module বদলায় (একটি নিয়ম ছড়িয়ে আছে)। Message chains আর middle man উল্টো দিকের বাড়াবাড়ি: শিকল কমাতে Hide Delegate করতে করতে class শুধু “পাঠানোর লোক” হলে সেটি middle man. Message chain পর্ব ২৬-এর Law of Demeter-এর লঙ্ঘনের চেনা রূপ। আর duplicated code সবসময় DRY-র লঙ্ঘন নয় — পর্ব ২৬-এই দেখেছেন, আজ দেখতে এক কিন্তু আলাদা কারণে বদলাবে এমন কোড (incidental duplication) জোর করে মেলালে উল্টো ক্ষতি।

৪ · মূল refactoring আর তাদের mechanics

Fowler-এর catalog-এ প্রতিটি refactoring-এর একটি নাম, উদ্দেশ্য আর mechanics — ধাপের তালিকা, যার প্রতিটি ধাপের পর কোড চলে আর test চালানো যায়। নাম জানলে দলে সংক্ষেপে কথা বলা যায় (পর্ব ৩২-এর pattern-এর শব্দভাণ্ডারের মতো), আর IDE-র menu-তে প্রায় এই নামগুলোই থাকে। নিচে দশটি বহুল ব্যবহৃত refactoring; নাম দ্বিতীয় সংস্করণের, বন্ধনীতে প্রথম সংস্করণের নাম যেখানে আলাদা।

শেষ সারির magic number-এর সতর্কতাটি গুরুত্বপূর্ণ: একটি file-এ 1000 তিনবার থাকলে তিনটি হয়তো তিন জিনিস — coupon-এর সীমা, ১০০০ গ্রাম = ১ কেজি, আর একটি page-এ সর্বোচ্চ সারি। সবগুলো COUPON_MIN করলে কোড “পরিষ্কার” দেখাবে, কিন্তু পরের বছর coupon-এর সীমা বদলালে ওজনের হিসাবও বদলে যাবে।

এবার সবচেয়ে বেশি ব্যবহৃত refactoring — Extract Function — একটি একটি ধাপে। কোডটি একটি কাল্পনিক অনলাইন বাজারের invoice: phone-এ ৫% gadget কর, বইয়ে ১০% ছাড়।

1function inv(it, nm, zone, coupon) {2  let t = 0;3  for (const x of it) {4    let a = x.qty * x.price;5    if (x.kind === "phone") a += a * 0.05;6    else if (x.kind === "book") a -= a * 0.1;7    t += a;8  }9  …coupon, delivery, return…10function lineAmount(x) { …লাইন ৪–৬…; return a; }

এবার পুরো যাত্রা চালিয়ে দেখুন। নিচের কোডে মূল inv চারটি ধাপে বদলায়: (১) Extract Function, (২) Rename আর magic number-এর নাম, (৩) Introduce Parameter Object, (৪) দামের নিয়মে polymorphism-এর একটি হালকা রূপ — পণ্যের ধরন অনুযায়ী function-এর table. প্রতিটি ধাপের পর একটি ছোট test harness মূল function-এর আউটপুটের (golden) সাথে মেলায়।

function inv(it, nm, zone, coupon) {                    // step 0: the original
  let t = 0;
  for (const x of it) {
    let a = x.qty * x.price;
    if (x.kind === "phone") a += a * 0.05; else if (x.kind === "book") a -= a * 0.1;
    t += a;
  }
  if (coupon && t > 1000) t -= 100;
  return nm + ": " + (t + (zone === "dhaka" ? 60 : 120)).toFixed(2);
}
const amt = x => { let a = x.qty * x.price;              // step 1: Extract Function
  if (x.kind === "phone") a += a * 0.05; else if (x.kind === "book") a -= a * 0.1; return a; };
const inv1 = (it, nm, zone, coupon) => { let t = it.reduce((s, x) => s + amt(x), 0);
  if (coupon && t > 1000) t -= 100;
  return nm + ": " + (t + (zone === "dhaka" ? 60 : 120)).toFixed(2); };
const COUPON_MIN = 1000, COUPON_OFF = 100, deliveryFee = z => z === "dhaka" ? 60 : 120; // step 2
function invoiceText(lines, customer, zone, hasCoupon) {
  let total = lines.reduce((sum, line) => sum + amt(line), 0);
  if (hasCoupon && total > COUPON_MIN) total -= COUPON_OFF;
  return customer + ": " + (total + deliveryFee(zone)).toFixed(2);
}
const invoiceText3 = (lines, o) => invoiceText(lines, o.customer, o.zone, o.hasCoupon); // step 3
const rule = { phone: a => a * 1.05, book: a => a * 0.9 };   // step 4: polymorphism
const lineAmount = l => (rule[l.kind] ?? (a => a))(l.qty * l.price);
function invoiceText4(lines, { customer, zone, hasCoupon }) {
  let total = lines.reduce((sum, l) => sum + lineAmount(l), 0);
  if (hasCoupon && total > COUPON_MIN) total -= COUPON_OFF;
  return customer + ": " + (total + deliveryFee(zone)).toFixed(2);
}
const cart = [{ kind: "rice", qty: 10, price: 68 }, { kind: "phone", qty: 1, price: 15000 }, { kind: "book", qty: 3, price: 250 }];
const cases = [[cart, "Karim", "dhaka", true], [cart.slice(2), "Rina", "sylhet", true], [[], "Mitu", "dhaka", false]];
const want = cases.map(c => inv(...c)); console.log("golden:", want.join(" | "));
const asObj = f => (l, c, z, h) => f(l, { customer: c, zone: z, hasCoupon: h });
[["step1", inv1], ["step2", invoiceText], ["step3", asObj(invoiceText3)], ["step4", asObj(invoiceText4)]]
  .forEach(([n, f]) => console.log(n, cases.every((c, i) => f(...c) === want[i]) ? "PASS" : "FAIL"));

golden: Karim: 17065.00 | Rina: 795.00 | Mitu: 60.00
step1 PASS
step2 PASS
step3 PASS
step4 PASS

৫ · Replace Conditional with Polymorphism — switch থেকে class-এ

একটি switch নিজে দোষী নয়। সমস্যা হয় যখন একই ধরনের ওপর একই switch বারবার আসে: delivery-র খরচে, পৌঁছানোর সময়ে, ট্র্যাকিং-এর লেখায়। নতুন একটি ধরন (রাতের delivery) এলে প্রতিটি switch খুঁজে বদলাতে হয় — একটি বাদ পড়লে bug. এটিই repeated switch smell, আর প্রতিকার polymorphism: প্রতিটি ধরন নিজের class, আর প্রতিটি class জানে নিজের খরচ আর সময়। Caller শুধু shipping.cost(order) ডাকে। নকশার দিক থেকে এটি পর্ব ২৭-এর open-closed principle-এর বাস্তব রূপ, আর গঠনটি পর্ব ৩৫-এর strategy pattern-এর মতো (ধরন যদি object-এর জীবনে বদলায়, তবে পর্ব ৩৬-এর state pattern).

// BEFORE: the same switch on order.ship appears in two functions
function cost(o) {
  switch (o.ship) {
    case "standard": return o.kg <= 1 ? 60 : 60 + Math.ceil(o.kg - 1) * 20;
    case "express":  return 150 + Math.ceil(o.kg) * 30;
    case "pickup":   return 0;
    default: throw new Error("unknown ship: " + o.ship);
  }
}
function eta(o) {
  switch (o.ship) { case "standard": return 3; case "express": return 1; case "pickup": return 0; }
}
// AFTER: one class per shipping type; one factory keeps the only switch
class Standard { cost(o) { return o.kg <= 1 ? 60 : 60 + Math.ceil(o.kg - 1) * 20; } eta() { return 3; } }
class Express  { cost(o) { return 150 + Math.ceil(o.kg) * 30; } eta() { return 1; } }
class Pickup   { cost() { return 0; } eta() { return 0; } }
const TYPES = { standard: Standard, express: Express, pickup: Pickup };
function shippingFor(o) {
  const C = TYPES[o.ship]; if (!C) throw new Error("unknown ship: " + o.ship); return new C();
}
const old = { cost, eta };                  // the same tests run against both versions
const neu = { cost: o => shippingFor(o).cost(o), eta: o => shippingFor(o).eta(o) };
const tests = [[{ ship: "standard", kg: 0.5 }, 60, 3], [{ ship: "standard", kg: 2.5 }, 100, 3],
               [{ ship: "express", kg: 1.2 }, 210, 1], [{ ship: "pickup", kg: 9 }, 0, 0]];
for (const [name, v] of [["before", old], ["after ", neu]]) {
  const ok = tests.filter(([o, c, d]) => v.cost(o) === c && v.eta(o) === d).length;
  let err; try { v.cost({ ship: "drone", kg: 1 }); } catch (e) { err = e.message; }
  console.log(name, ok + "/" + tests.length, "green |", err);
}
class Night { cost(o) { return 200 + Math.ceil(o.kg) * 25; } eta() { return 0.5; } }
TYPES.night = Night;                        // new type: one class + one line, no switch edited
const n = { ship: "night", kg: 2 }; console.log("night:", neu.cost(n), "taka, eta", neu.eta(n), "day");

before 4/4 green | unknown ship: drone
after  4/4 green | unknown ship: drone
night: 250 taka, eta 0.5 day

৬ · Smell মেপে খোঁজা — AST দিয়ে একটি খেলনা detector আর feature envy

কিছু smell মাপা যায়: function-এর লাইন, parameter-এর সংখ্যা, nesting-এর গভীরতা, একই literal কতবার। Linter আর static analysis tool (পর্ব ৪৪-এ, code review-এর সাথে) ঠিক এভাবে কাজ করে — কোডকে চালায় না, পড়ে। পড়ার জন্য তারা source code থেকে বানায় একটি abstract syntax tree (AST) — কোডের গঠনের গাছ, যেখানে প্রতিটি function, if, loop একটি node. Python-এর standard library-র ast module দিয়ে নিজেই একটি ছোট detector লেখা যায়।

import ast
from collections import Counter
SAMPLE = '''
def fee(order, zone, coupon, member, festival, weight):
    if order:
        for item in order:
            if item["kind"] == "phone":
                if festival:
                    if member:
                        return "phone"
    return "dhaka" if zone == "dhaka" else "outside"

def label(zone):
    return "dhaka" if zone == "dhaka" else "outside"

def report(rows):
    print("dhaka", sum(r["amount"] for r in rows))
'''
LIMITS = {"lines": 6, "params": 4, "depth": 3, "repeats": 3}
BLOCKS = (ast.If, ast.For, ast.While, ast.With, ast.Try)
def depth(node, d=0):                     # deepest nesting of blocks
    kids = [depth(c, d + isinstance(c, BLOCKS)) for c in ast.iter_child_nodes(node)]
    return max(kids, default=d)
tree = ast.parse(SAMPLE)
for fn in [n for n in ast.walk(tree) if isinstance(n, ast.FunctionDef)]:
    size, params, deep = fn.end_lineno - fn.lineno + 1, len(fn.args.args), depth(fn)
    found = [f"long function ({size} lines)" * (size > LIMITS["lines"]),
             f"long parameter list ({params})" * (params > LIMITS["params"]),
             f"deep nesting ({deep})" * (deep > LIMITS["depth"])]
    print(f"{fn.name:6} line {fn.lineno:2}:", "; ".join(s for s in found if s) or "ok")
strings = Counter(n.value for n in ast.walk(tree)
                  if isinstance(n, ast.Constant) and isinstance(n.value, str))
for text, k in strings.most_common():
    if k >= LIMITS["repeats"]:
        print(f"duplicate literal {text!r} x{k} -> replace with a named constant")

fee    line  2: long function (8 lines); long parameter list (6); deep nesting (5)
label  line 11: ok
report line 14: ok
duplicate literal 'dhaka' x5 -> replace with a named constant

Feature envy আর Move Function — গুনে দেখা

Feature envy-র লক্ষণ: একটি method নিজের object-এর চেয়ে অন্য একটি object-এর তথ্যে বেশি আগ্রহী। Fowler-এর নিয়মটি সহজ — যে তথ্য একসাথে বদলায়, সেই তথ্য আর তার আচরণ একসাথে রাখুন। নিচে Invoice.delivery_fee customer-এর তিনটি field পড়ে (zone, কত বছরের সদস্য, কতগুলো অর্ডার), আর নিজের মাত্র একটি (base). হিসাবটি customer-এর কাছে সরালে (Move Function) customer-এর নিয়ম বদলালে শুধু Customer খুলতে হয়। কোড দুই সংস্করণ চালিয়ে ফল মেলায়, আর AST দিয়ে প্রতিটি delivery_fee-এ কোন নামের object-এর attribute কতবার পড়া হলো তা গোনে।

import ast
BEFORE = '''class Customer:
    def __init__(self, zone, years, orders):
        self.zone, self.years, self.orders = zone, years, orders
class Invoice:
    def __init__(self, base): self.base = base
    def delivery_fee(self, c):            # envies Customer
        fee = 60 if c.zone == "dhaka" else 120
        if c.years >= 3 or c.orders > 20: fee = fee // 2
        return self.base + fee
'''
AFTER = '''class Customer:
    def __init__(self, zone, years, orders):
        self.zone, self.years, self.orders = zone, years, orders
    def delivery_fee(self):               # moved next to its data
        fee = 60 if self.zone == "dhaka" else 120
        return fee // 2 if self.years >= 3 or self.orders > 20 else fee
class Invoice:
    def __init__(self, base): self.base = base
    def delivery_fee(self, c): return self.base + c.delivery_fee()
'''
def accesses(src, method):                # attribute reads, grouped by owner name
    out = {}
    for cls in ast.parse(src).body:
        for fn in cls.body:
            if fn.name == method:
                names = [n.value.id for n in ast.walk(fn)
                         if isinstance(n, ast.Attribute) and isinstance(n.value, ast.Name)]
                out[cls.name] = {k: names.count(k) for k in sorted(set(names))}
    return out
for label, src in (("before", BEFORE), ("after ", AFTER)):
    env = {}; exec(src, env)
    fees = [env["Invoice"](500).delivery_fee(env["Customer"](*a)) for a in (("dhaka", 4, 2), ("rajshahi", 1, 5))]
    print(label, "fees", fees, "| reads in delivery_fee:", accesses(src, "delivery_fee"))

before fees [530, 620] | reads in delivery_fee: {'Invoice': {'c': 3, 'self': 1}}
after  fees [530, 620] | reads in delivery_fee: {'Customer': {'self': 3}, 'Invoice': {'c': 1, 'self': 1}}

৭ · IDE-র automated refactoring, rewrite আর কখন refactor নয়

IDE যখন refactor করে

আধুনিক IDE আর editor-এ (Java বা .NET-এর IDE, language server-সহ VS Code ইত্যাদি) Rename, Extract, Inline, Move, Change Signature একটি menu বা shortcut-এ পাওয়া যায় — automated refactoring. Tool কোডকে লেখা হিসেবে নয়, AST আর type দিয়ে বোঝে: total নামের দুটি আলাদা variable গুলিয়ে ফেলে না, যা find-and-replace প্রায়ই ফেলে। Extract Function-এ সে নিজেই parameter আর return বের করে।

অর্থাৎ IDE-র refactoring হাতে করার চেয়ে অনেক নিরাপদ, কিন্তু test-এর বিকল্প নয়। Automated rename-এর পরেও test চালান, আর git diff দেখে নিন বদল শুধু যেখানে প্রত্যাশিত সেখানেই হয়েছে কি না (পর্ব ৯)।

Refactor না rewrite

পুরোনো জটিল কোড দেখে মনে হয়, “সব ফেলে নতুন করে লিখি।” একবারে শূন্য থেকে লিখে একদিনে বদলে ফেলাকে বলে big-bang rewrite. ঝুঁকি বড়: পুরোনো কোডের অদ্ভুত if-গুলো হয়তো অলিখিত bug fix; নতুনটি সমান হওয়ার আগে মাসের পর মাস কিছু চালু হয় না; আর সেই সময়ে দুই জায়গায় কাজ। Joel Spolsky-র ২০০০ সালের বহুল-উদ্ধৃত প্রবন্ধ “Things You Should Never Do” Netscape browser-এর নতুন করে লেখাকে এই ঝুঁকির উদাহরণ হিসেবে দেখায় (তাঁর বিশ্লেষণ, বিতর্কও আছে)।

মাঝামাঝি একটি পথ হলো ধীরে ধীরে প্রতিস্থাপন: পুরোনো system-এর পাশে নতুন অংশ বানিয়ে একটি একটি কাজ নতুনটিতে সরানো, যতক্ষণ না পুরোনোটি খালি হয়ে যায়। Fowler এর নাম দেন strangler fig (বট-অশ্বত্থের আত্মীয় এক ধরনের ডুমুর-জাতীয় গাছ, যা আশ্রয়-গাছকে ঘিরে বড় হয়ে একসময় তার জায়গা নেয়)। এই কৌশল বড় architecture-এর স্তরে System Design কোর্সের microservices পর্বে আর পুরোনো কোড সামলানোর প্রসঙ্গে পর্ব ৪৩-এ আছে।

কখন refactor করবেন না

• Test নেই, বসানোর উপায়ও এখনই নেই: শুধু IDE-র সবচেয়ে নিরাপদ automated refactoring, নয়তো আগে characterization test (পর্ব ৪৩)।
• কোডটি আর কেউ ছোঁবে না: কুৎসিত কিন্তু স্থির কোডের “সুদ” প্রায় শূন্য (technical debt-এর হিসাব পর্ব ৪৩-এ)।
• Release-এর ঠিক আগে বা আগুন নেভানোর সময়: আগে ছোট fix, পরে শান্ত মাথায় refactor.
• Feature-এর মাঝপথে: অর্ধেক feature আর অর্ধেক refactoring একসাথে মানে দুটিই অসমাপ্ত। আগে feature-এর অংশ সবুজে আনুন বা stash করুন, তারপর টুপি বদলান।
• শুধু রুচির জন্য: অন্যের সাম্প্রতিক কোড নিজের ধাঁচে বদলানো review-তে ঘর্ষণ বাড়ায়; দলের style guide আগে।

Preparatory refactoring — আগে বদল সহজ করুন

Refactoring-এর সবচেয়ে লাভজনক সময় সাধারণত একটি নতুন feature-এর ঠিক আগে। Kent Beck-এর নামে প্রচলিত একটি উক্তি (২০১২ সালের একটি tweet বলে উল্লেখ করা হয়): “make the change easy (warning: this may be hard), then make the easy change” — আগে বদলটিকে সহজ করুন (সাবধান, এটি কঠিন হতে পারে), তারপর সহজ বদলটি করুন। একে বলে preparatory refactoring. অংশ ৪-এর invoice-এ চট্টগ্রামের নতুন delivery চার্জ যোগ করতে হলে প্রথমে delivery-র হিসাব deliveryFee(zone) function-এ বের করুন (refactor, test সবুজ, commit), তারপর সেখানে একটি সারি যোগ করুন (feat). Fowler একটি উপমা দেন: সোজা পূর্ব দিকে যেতে হলে কখনো কখনো আগে উত্তরে গিয়ে বড় রাস্তায় ওঠা দ্রুত। এর সাথেই যায় Don Roberts-এর নামে প্রচলিত rule of three: প্রথমবার লিখুন, দ্বিতীয়বার কপি করতে অস্বস্তি হলেও করুন, তৃতীয়বার refactor করুন।

৮ · Git-এ refactoring — “refactor:” আর “feat:” আলাদা commit-এ

দুই টুপির নিয়ম Git-এ এসে দাঁড়ায় একটি সরল অভ্যাসে: একটি commit-এ হয় শুধু আচরণ-রক্ষাকারী কাঠামোর বদল, নয়তো শুধু আচরণের বদল। পর্ব ১৮-এ দেখা Conventional Commits-এর ভাষায় প্রথমটি refactor:, দ্বিতীয়টি feat: বা fix:. (মূল Conventional Commits 1.0.0 নির্দিষ্টভাবে শুধু feat আর fix-এর অর্থ বেঁধে দেয়; refactor, test, docs-এর মতো type এসেছে Angular-এর রীতি আর commitlint-এর প্রচলিত config থেকে — দলভেদে তালিকা আলাদা।) প্রতিটি commit একটি atomic commit: একটি যুক্তিসংগত বদল, যার পরে test সবুজ।

কেন এত যত্ন? চারটি কারণ:

• Review: refactor: commit-এর reviewer জানেন, এখানে আচরণ বদলানোর কথা নয় — test-এর file বদলায়নি, শুধু কাঠামো। ৩০০ লাইনের মিশ্র diff-এ একটি আচরণ-বদল লুকিয়ে থাকলে চোখে পড়া কঠিন (পর্ব ১৬, আর পর্ব ৪৪-এর code review).
• Revert: নতুন feature-এ সমস্যা হলে শুধু feat: commit-টি git revert করা যায়, আগের refactoring অক্ষত থাকে।
• Bisect: প্রতিটি commit ছোট আর সবুজ হলে git bisect ঠিক কোন বদলে bug ঢুকল তা দ্রুত দেখায় (পর্ব ৫৫)।
• Blame: বড় rename বা format-এর commit git blame-কে “শেষ কে এই লাইন ছুঁয়েছেন” প্রশ্নে বিভ্রান্ত করে। Git ২.২৩ থেকে git blame --ignore-rev আর blame.ignoreRevsFile দিয়ে এমন commit বাদ দেওয়া যায় — কিন্তু শুধু তখনই, যদি সেই commit-এ কেবল কাঠামোর বদল থাকে।

নিচের transcript একটি আসল scratch repository থেকে (Git ২.৫৩-এ, লেখক Rahim, তারিখ নির্দিষ্ট করে দেওয়া, তাই hash পুনরুৎপাদনযোগ্য)। অংশ ৪-এর invoice-এর গল্প: প্রথমে feature, তারপর বর্তমান আচরণ ধরে রাখার test, তিনটি refactoring, শেষে একটি নতুন feature.

$ git log --oneline
1093bab feat: charge 90 taka delivery in chattogram
66f585c refactor: introduce order parameter object
0c13e91 refactor: rename inv to invoiceText and its variables
e55f503 refactor: extract lineAmount from inv
8ca8b97 test: pin current invoice output
958ddeb feat: add invoice text for orders

$ git diff --stat HEAD~4 HEAD~1
 src/invoice.js | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

$ git show --stat --format="%h %s" HEAD
1093bab feat: charge 90 taka delivery in chattogram

 src/invoice.js       | 3 ++-
 test/invoice.test.js | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

$ git log --oneline --grep="^refactor"
66f585c refactor: introduce order parameter object
0c13e91 refactor: rename inv to invoiceText and its variables
e55f503 refactor: extract lineAmount from inv

প্রতিটি refactor commit-এ সত্যিই test সবুজ ছিল কি না, পরে যাচাই করতে git rebase -x (বা --exec) কাজের: প্রতিটি commit বসানোর পর command-টি চালায়, আর কোথাও ব্যর্থ হলে সেখানে থামে (পর্ব ১৫)।

$ git rebase -x "node test/invoice.test.js" HEAD~4
Executing: node test/invoice.test.js
ok
Executing: node test/invoice.test.js
ok
Executing: node test/invoice.test.js
ok
Executing: node test/invoice.test.js
ok
Successfully rebased and updated refs/heads/main.

৯ · AI-এর যুগে refactoring

AI দ্রুত পরিষ্কার দেখতে কোড দেয়, কিন্তু refactoring-এর মূল প্রতিশ্রুতি — আচরণ একই — নিজে যাচাই করে না। সাধারণ ভুল আর ধরার উপায়:

AI-এর refactoring হাতে পেলে — যাচাইয়ের চেকলিস্ট

• বদলের আগেই test সবুজ ছিল, আর প্রতিটি ধাপের পর আবার চালিয়েছি
• সীমানার মানে (যেমন ৯৯৯, ১০০০, ১০০১) পুরোনো আর নতুন সংস্করণের আউটপুট মিলিয়েছি
• Refactoring-এর commit-এ test-এর file বদলায়নি — git diff --stat দেখেছি
• প্রতিটি commit-এ হয় শুধু refactor, নয়তো শুধু feat/fix — মেশানো নয়
• প্রস্তাবিত pattern বা নতুন class কোন smell সারায়, তা এক বাক্যে বলতে পারি
• String-এ লেখা নাম, config আর বাইরের caller নিজে খুঁজেছি (rename-এর পর)
• AI-এর দেওয়া Git command আগে একটি throwaway clone-এ চালিয়েছি; prompt-এ কোনো secret দিইনি