SOLID ২ — Liskov substitution, interface segregation আর dependency inversion

১ · SOLID-এর বাকি তিন অক্ষর — কোথা থেকে শুরু

পর্ব ২৭-এ SOLID-এর পরিচয় আর প্রথম দুই অক্ষর দেখেছেন: S — single responsibility (একটি module বদলানোর একটিই কারণ), আর O — open-closed (নতুন আচরণ যোগ হবে নতুন কোড লিখে, পুরোনো কোড না ভেঙে)। Open-closed-এর একটি গোপন শর্ত ছিল: আমরা ধরে নিয়েছিলাম, নতুন subclass বা নতুন বাস্তবায়ন বসালে পুরোনো কোড ঠিকঠাক চলবে। এই পর্বের তিন নীতি সেই শর্তকে পাকা করে।

তিনটিই আসলে পর্ব ২৫-এর coupling-এর গল্প: কোন অংশ কোন অংশের কতটুকু জানে, আর একটি বদলালে কতগুলো ভাঙে। LSP ভুল inheritance-এর coupling ধরে, ISP অপ্রয়োজনীয় interface-coupling ছাঁটে, আর DIP coupling-এর দিক ঠিক করে। নিচে প্রতিটিকে প্রথমে সহজ উপমায়, তারপর সুনির্দিষ্ট নিয়মে, তারপর চালানো যায় এমন Python কোডে দেখব। Python-এর abc আর typing.Protocol নতুন মনে হলে Python কোর্সের ABC আর Protocol-এর পর্বটি পাশে খুলে রাখতে পারেন।

২ · Liskov substitution — বদলি যেন আসলের প্রতিশ্রুতি রাখে

Liskov তাঁর ১৯৮৭ সালের বক্তৃতায় একটি “substitution property”-র কথা বলেন, যার সারকথা: যদি type T-এর জন্য লেখা প্রতিটি প্রোগ্রাম P-তে T-এর object-এর বদলে S-এর object বসালে P-এর আচরণ না বদলায়, তবে S হলো T-এর subtype. Liskov ও Wing ১৯৯৪ সালে একে আরও নির্দিষ্ট করেন: T-এর object সম্পর্কে যে বৈশিষ্ট্য প্রমাণ করা যায়, S-এর object-এর ক্ষেত্রেও তা সত্য হতে হবে। আজ প্রচলিত ভাষায় — Liskov substitution principle: S যদি T-এর subtype হয়, তবে প্রোগ্রামের কাঙ্ক্ষিত বৈশিষ্ট্য (ঠিক ফল, কাজ সম্পূর্ণ হওয়া ইত্যাদি) না বদলে T-এর object-এর জায়গায় S-এর object বসানো যাবে।

লক্ষ করুন, কথাটি inheritance নিয়ে নয়, আচরণ নিয়ে। Compiler বা type checker দেখে method-এর নাম আর parameter মেলে কি না; কিন্তু “width বদলালে height বদলাবে না” — এমন প্রতিশ্রুতি কোনো type checker দেখে না। এজন্যই এর নাম behavioural subtyping. প্রতিশ্রুতিগুলো লেখার ভাষা আসে Bertrand Meyer-এর design by contract থেকে (তাঁর Object-Oriented Software Construction, ১৯৮৮): প্রতিটি method-এর precondition (ডাকার আগে caller-কে যা নিশ্চিত করতে হবে), postcondition (শেষে method যা নিশ্চিত করবে), আর class-এর invariant (সবসময় সত্য শর্ত)। চুক্তি লেখার পূর্ণ পদ্ধতি আর error handling-এর সাথে তার সম্পর্ক পর্ব ৩১-এ আসবে; এখানে শুধু LSP-র জন্য যে নিয়মগুলো লাগে সেগুলো দেখি।

একটি সহজ মুখস্থ-সূত্র Meyer-এর subcontracting থেকে: “বেশি চাইবেন না, কম দেবেন না।” Subclass হলো ঠিকাদারের অধীনে সাব-ঠিকাদার; মালিক মূল চুক্তি দেখে টাকা দিয়েছেন, তাই সাব-ঠিকাদার নতুন শর্ত চাপাতে পারেন না, আর কাজও কম করতে পারেন না। Liskov ও Wing-এর গবেষণাপত্রে signature-এর দুটি নিয়মও আছে — parameter-এর type subtype-এ সমান বা আরও সাধারণ হতে পারে (contravariance), আর return type সমান বা আরও নির্দিষ্ট (covariance) — কিন্তু এগুলো type checker অনেকটা নিজেই ধরে। আসল বিপদ আচরণের নিয়মে, যা কেউ ধরে না।

৩ · Rectangle, Square আর উড়তে না-পারা পাখি

সবচেয়ে বিখ্যাত উদাহরণ Martin-এর ১৯৯৬ সালের লেখা থেকে জনপ্রিয়। গণিতে প্রতিটি বর্গ একটি আয়ত — তাহলে class Square(Rectangle) লেখা তো স্বাভাবিক! সমস্যা হলো, কোডের Rectangle গণিতের আয়ত নয়; তার set_width আর set_height method আছে, আর তাদের একটি অলিখিত প্রতিশ্রুতি: width বদলালে height যেমন ছিল তেমন থাকবে। Square বর্গ থাকতে চাইলে এই প্রতিশ্রুতি রাখতে পারে না। নিচের stepper-এ একটি test একই কাজ দুই object-এ করছে — “পরে” চাপুন আর মানগুলো দেখুন।

1def test_resize(shape):2    shape.set_width(4)3    shape.set_height(5)4    assert shape.area() == 2056test_resize(Rectangle(2, 3))7test_resize(Square(3))

এবার আসল কোডে একই জিনিস, আর তার একটি সমাধান। সমাধানের মূল চিন্তা: সমস্যাটি “বর্গ” নয়, “setter-এর প্রতিশ্রুতি”। দুটিকেই একটি সাধারণ abstraction Shape-এর নিচে রাখি, যা শুধু সেই প্রতিশ্রুতি দেয় যা দুজনেই রাখতে পারে — area()। আর আকার বদলানোর বদলে নতুন object ফেরত দিই (immutable).

class Rectangle:
    def __init__(self, w, h): self.w, self.h = w, h
    def set_width(self, w): self.w = w      # promise: height unchanged
    def set_height(self, h): self.h = h     # promise: width unchanged
    def area(self): return self.w * self.h

class Square(Rectangle):
    def __init__(self, side): super().__init__(side, side)
    def set_width(self, w): self.w = self.h = w   # keeps it square
    def set_height(self, h): self.w = self.h = h

def test_resize(shape):              # written against Rectangle's contract
    shape.set_width(4)
    shape.set_height(5)
    got = shape.area()
    print(f"{type(shape).__name__:9} area={got}", "PASS" if got == 20 else "FAIL (expected 20)")
test_resize(Rectangle(2, 3))
test_resize(Square(3))
# Part 2: the fix. A common abstraction that promises only what both keep.
from abc import ABC, abstractmethod
from dataclasses import dataclass
class Shape(ABC):
    @abstractmethod
    def area(self): ...
@dataclass(frozen=True)
class Rect(Shape):
    w: int; h: int
    def area(self): return self.w * self.h
    def with_width(self, w): return Rect(w, self.h)    # a NEW Rect
@dataclass(frozen=True)
class Sq(Shape):
    side: int
    def area(self): return self.side ** 2
shapes = [Rect(2, 3).with_width(4), Sq(3)]
print([f"{s} -> {s.area()}" for s in shapes], "total", sum(s.area() for s in shapes))

Rectangle area=20 PASS
Square    area=25 FAIL (expected 20)
['Rect(w=4, h=3) -> 12', 'Sq(side=3) -> 9'] total 21

পাখি সবাই ওড়ে?

দ্বিতীয় ক্লাসিক উদাহরণ: Bird class-এ fly() আছে, কারণ প্রথম যে পাখিগুলো মডেল করা হয়েছিল — কাক, শালিক, চড়ুই — সবাই ওড়ে। তারপর এল পেঙ্গুইন বা উটপাখি:

class Bird:
    def fly(self): return "flying"

class Penguin(Bird):
    def fly(self): raise NotImplementedError("penguins can't fly")

def migrate(flock):                       # written for Bird
    return [b.fly() for b in flock]       # crashes if a Penguin sneaks in

Penguin.fly()-এ NotImplementedError ছোড়া মানে precondition কড়া করা (“আমাকে ওড়াতে ডাকবেন না”) বা নতুন exception আনা — দুইভাবেই LSP লঙ্ঘন। ভুলটি পেঙ্গুইনের নয়, Bird-এর: সে এমন প্রতিশ্রুতি দিয়েছিল (“সব পাখি ওড়ে”) যা বাস্তবে সব পাখির নয়। Fowler-এর Refactoring বইয়ে এই গন্ধের নাম refused bequest — উত্তরাধিকারে পাওয়া জিনিস subclass ফিরিয়ে দিচ্ছে। সমাধান পরের অংশে।

৪ · LSP লঙ্ঘন চেনা, ধরা আর সারানো

বাস্তব কোডে লঙ্ঘন খুব কম সময় “Square” নামে আসে। কয়েকটি লক্ষণ মনে রাখলে code review-তে (পর্ব ৪৪) চোখে পড়বে:

• Client-এ type পরীক্ষা: if isinstance(p, CashOnDelivery): ... বা if type(shape) == Square. Caller-কে যদি জানতে হয় ভেতরে কোন subclass, তবে substitution কাজ করছে না — আর প্রতিটি নতুন subclass-এ এই if বাড়বে (open-closed-ও ভাঙল)।
• Override যা কাজ ফিরিয়ে দেয়: raise NotImplementedError, খালি pass, বা অর্থহীন মান (return 0, return None) — যেখানে base অর্থপূর্ণ কাজের প্রতিশ্রুতি দিয়েছিল। (খেয়াল রাখুন: abstract base-এ NotImplementedError স্বাভাবিক — সেখানে base নিজেই কোনো প্রতিশ্রুতি দেয় না; সমস্যা হলো concrete subclass-এ কাজ “ফিরিয়ে দেওয়া”।)
• Subclass-এর জন্য test বাদ: “এই test FeeWallet-এর জন্য skip করুন” — অর্থাৎ base-এর চুক্তির কিছু অংশ সে মানে না।
• Documentation-এ সতর্কবার্তা: “এই subclass-এ refund() ডাকবেন না।” চুক্তি যদি সতর্কবার্তায় বাঁচে, তবে সেটি চুক্তি নয়।

লক্ষণ দেখে সন্দেহ করা যায়, কিন্তু প্রমাণ আসে test থেকে। সবচেয়ে কার্যকর কৌশল: base type-এর চুক্তির জন্য একটি test suite লিখুন, আর সেটি প্রতিটি subtype-এ চালান। কেউ একে “contract test” বা “abstract test case” বলেন। শর্ত একটাই — input নিতে হবে base-এর precondition মেনে, আর যাচাই করতে হবে base-এর postcondition দিয়ে, subclass-এর নিজের নিয়ম দিয়ে নয়।

# Run the SAME contract suite against a base class and its subclasses.
class Discount:                       # contract of discount(amount):
    def discount(self, amount):       #  pre : amount >= 0 (any amount, even 0)
        return amount * 0.10          #  post: 0 <= result <= amount

class FestivalDiscount(Discount):     # same pre, stronger post: allowed
    def discount(self, amount):
        return min(amount * 0.20, 500)

class MinOrderDiscount(Discount):     # demands more from the caller
    def discount(self, amount):
        if amount < 100: raise ValueError("min order 100")
        return amount * 0.15

class CashbackDiscount(Discount):     # promises less to the caller
    def discount(self, amount):
        return amount * 0.10 + 50      # can exceed the amount itself

INPUTS = [0, 40, 99, 100, 2500, 10000]  # all satisfy the BASE precondition

def check(cls):
    obj, problems = cls(), []
    for a in INPUTS:
        try:
            r = obj.discount(a)
        except Exception as e:
            problems.append(f"pre strengthened at {a}: {type(e).__name__}")
            continue
        if not 0 <= r <= a:
            problems.append(f"post weakened at {a}: got {r:g}")
    print(f"{cls.__name__:17}", "OK" if not problems else f"{len(problems)} broken: {problems[:2]}")

for cls in (Discount, FestivalDiscount, MinOrderDiscount, CashbackDiscount):
    check(cls)

Discount          OK
FestivalDiscount  OK
MinOrderDiscount  3 broken: ['pre strengthened at 0: ValueError', 'pre strengthened at 40: ValueError']
CashbackDiscount  2 broken: ['post weakened at 0: got 50', 'post weakened at 40: got 54']

সারানোর তিন পথ

৫ · Interface segregation — যা লাগে না, তার সাথে বাঁধা নয়

Martin-এর ভাষায় interface segregation principle: client-কে এমন method-এর ওপর নির্ভর করতে বাধ্য করা উচিত নয়, যা সে ব্যবহার করে না। একটি interface-এ অনেক ভিন্ন ধরনের client-এর method জমে গেলে তাকে বলে fat interface. সমাধান — client-এর প্রয়োজন অনুযায়ী ছোট role interface: “যে ছাপায়”, “যে স্ক্যান করে” — প্রতিটি একটি ভূমিকা।

Fat interface-এর তিনটি বাস্তব খরচ:

1. Recompile আর redeploy: C++ বা Java-র মতো compiled ভাষায় interface-এর একটি method বদলালে যত module সেই interface ব্যবহার করে, সবাইকে আবার compile, test আর হয়তো deploy করতে হয় — যারা ওই method কখনো ডাকে না তাদেরও। পর্ব ১৯-এর affected build-এর ভাষায়, fat interface “প্রভাবিত” তালিকা অকারণে লম্বা করে। Python বা JavaScript-এ compile-এর খরচ কম, কিন্তু review, test আর পর্ব ১৮-এর breaking change-এর ঝুঁকি একই।
2. Stub-এর বোঝা: যে class শুধু একটি কাজ পারে, তাকেও বাকি সব method লিখতে হয় — প্রায়ই NotImplementedError দিয়ে। মানে fat interface সরাসরি LSP লঙ্ঘন তৈরি করে!
3. Test double-এর বোঝা: Test-এ নকল বানাতে (test double) সব method-এর stub লিখতে হয়, যদিও test শুধু একটি ছোঁয়। কোন double কখন — পর্ব ৪৯-এ।

নিচের প্রোগ্রাম একই হিসাব চালিয়ে দেখায়। Machine.__abstractmethods__ হলো Python-এর রাখা abstract method-এর set; তা থেকে প্রতিটি client কতগুলোর ওপর নির্ভর করে আর printer-কে কতগুলো stub লিখতে হয়, গোনা হয়েছে। শেষে typing.Protocol দিয়ে একটি role interface — structural typing: TinyPrinter কোনো কিছু inherit করে না, শুধু print_doc আছে বলেই Printer-এর চুক্তি মানে।

from abc import ABC, abstractmethod
from typing import Protocol

class Machine(ABC):                     # the fat interface
    @abstractmethod
    def print_doc(self, doc): ...
    @abstractmethod
    def scan(self): ...
    @abstractmethod
    def fax(self, doc, number): ...
    @abstractmethod
    def staple(self, doc): ...

class BasicPrinter(Machine):            # can only print, must "implement" 4
    def print_doc(self, doc): return f"printed {doc}"
    def scan(self): raise NotImplementedError
    def fax(self, doc, number): raise NotImplementedError
    def staple(self, doc): raise NotImplementedError

uses = {"InvoiceClerk": {"print_doc"}, "ArchiveBot": {"scan"},
        "FrontDesk": {"print_doc", "scan"}}
fat = Machine.__abstractmethods__
print("fat interface:", len(fat), "methods")
for client, used in uses.items():
    print(f"  {client:12} uses {len(used)}, depends on {len(fat)}")
stubs = [m for m in fat if m != "print_doc"]
print("BasicPrinter stubs:", len(stubs))
class Printer(Protocol):                # role interfaces: one job each
    def print_doc(self, doc) -> str: ...

class TinyPrinter:                      # no Machine, no stubs
    def print_doc(self, doc): return f"printed {doc}"

def clerk(p: Printer): return p.print_doc("invoice-17")
print(clerk(TinyPrinter()), "| stubs needed now: 0")

fat interface: 4 methods
  InvoiceClerk uses 1, depends on 4
  ArchiveBot   uses 1, depends on 4
  FrontDesk    uses 2, depends on 4
BasicPrinter stubs: 3
printed invoice-17 | stubs needed now: 0

৬ · Dependency inversion — তীরের দিক উল্টানো

Software-এ “ফ্যান” হলো high-level module বা policy — অর্ডার নেওয়ার নিয়ম, ছাড়ের হিসাব, ফলাফল প্রকাশের নিয়ম; software-এর আসল উদ্দেশ্য। “বিদ্যুৎকেন্দ্র” হলো low-level module বা detail — MySQL, SMS gateway, file system. স্বাভাবিকভাবে কোড লিখলে policy সরাসরি detail-কে ডাকে, তাই policy-র কোড detail-কে import করে: অর্ডারের নিয়ম MySQL-এর ওপর নির্ভরশীল। Martin-এর dependency inversion principle-এর দুটি অংশ:

“Inversion” শব্দটির মানে: প্রচলিত, ওপর-থেকে-নিচে নকশায় source code-এর নির্ভরতার তীর যেদিকে যায়, DIP সেটি উল্টে দেয়। কিন্তু উল্টায় শুধু source code-এর তীর (কে কাকে import করে); চালানোর সময় call তখনও policy থেকে detail-এ যায়। আর এখানেই সবচেয়ে বেশি ভুল হয় — abstraction-এর মালিক কে? Repository interface যদি mysql package-এ থাকে, আর MySQL-এর ভাষায় লেখা হয় (execute_sql(query)), তবে policy এখনো detail-এর package-কে import করছে; তীর আসলে উল্টায়নি। DIP-এ abstraction থাকে policy-র package-এ, policy-র ভাষায় (save(order)) — সকেটের নিয়ম যন্ত্রের প্রয়োজনে লেখা।

এবার stepper-এর গল্পটি চালানো যায় এমন কোডে। MySQLRepository এখানে ইচ্ছা করে ConnectionError ছোড়ে — যেন test চালানোর যন্ত্রে database নেই। Test-গুলো চালাতে একটি ছোট runner লেখা হয়েছে, যা ব্যর্থতা ধরে ছাপে কিন্তু প্রোগ্রাম থামায় না।

from typing import Protocol
class MySQLRepository:                     # low-level detail
    def save(self, order):
        raise ConnectionError("no MySQL server on this machine")

class OrderServiceV1:                      # policy creates its own detail
    def place(self, item, qty):
        MySQLRepository().save({"item": item, "qty": qty}); return "placed"

class Repository(Protocol):                # owned by the policy side
    def save(self, order: dict) -> None: ...

class OrderService:                        # depends only on Repository
    def __init__(self, repo: Repository): self.repo = repo
    def place(self, item, qty):
        if qty <= 0: raise ValueError("qty must be positive")
        self.repo.save({"item": item, "qty": qty}); return "placed"

class InMemoryRepository:                  # a fake, for tests
    def __init__(self): self.rows = []
    def save(self, order): self.rows.append(order)
def run(name, fn):
    try: fn(); print("PASS", name)
    except Exception as e: print("FAIL", name, "->", type(e).__name__, e)

def test_v1(): OrderServiceV1().place("tea", 2)
def test_saves_order():
    repo = InMemoryRepository()
    assert OrderService(repo).place("tea", 2) == "placed"
    assert repo.rows == [{"item": "tea", "qty": 2}]
def test_rejects_zero():
    repo = InMemoryRepository()
    try: OrderService(repo).place("tea", 0); assert False
    except ValueError: assert repo.rows == []
for t in (test_v1, test_saves_order, test_rejects_zero): run(t.__name__, t)

FAIL test_v1 -> ConnectionError no MySQL server on this machine
PASS test_saves_order
PASS test_rejects_zero

৭ · Inversion, injection আর IoC — তিনটি আলাদা জিনিস

ইন্টারভিউতে সবচেয়ে বেশি গুলিয়ে যায় তিনটি নাম, কারণ তিনটিই “D” আর “I” দিয়ে, আর প্রায়ই একসাথে আসে। কিন্তু এরা ভিন্ন স্তরের কথা:

Dependency injection নামটি Martin Fowler-এর ২০০৪ সালের একটি প্রবন্ধ (“Inversion of Control Containers and the Dependency Injection pattern”) থেকে প্রচলিত; সেখানে তিনি বলেন, “inversion of control” কথাটি এত সাধারণ যে container-গুলোর কাজ বোঝাতে আরও নির্দিষ্ট নাম দরকার। Inversion of control-এর ধারণা পুরোনো — framework নিয়ে ১৯৮০-র দশকের লেখায় (যেমন Johnson ও Foote, ১৯৮৮) পাওয়া যায় বলে সাধারণত উল্লেখ করা হয়, আর এর জনপ্রিয় ডাকনাম “Hollywood principle”: আমাদের ডাকবেন না, আমরাই আপনাকে ডাকব। DI container (যেমন Java-র Spring) কীভাবে কাজ করে, constructor বনাম setter injection, আর inheritance-এর বদলে composition — এসব পর্ব ৩৭-এর বিষয়।

DIP আর testability

DIP-এর সবচেয়ে দৈনন্দিন লাভ test-এ। Policy যখন একটি ছোট, নিজের ভাষার abstraction-এর ওপর নির্ভর করে, তখন test-এ সেই abstraction-এর একটি সরল বাস্তবায়ন (fake, stub) বসানো যায় — database, network, ঘড়ি বা random সংখ্যা ছাড়াই। ঘড়িও একটি dependency: “রাত ১২টার পর ছাড় বন্ধ” নিয়মের test-এ আসল ঘড়ি ব্যবহার করলে test শুধু রাতে পাস করবে! Clock abstraction নিলে test নিজে সময় ঠিক করে দিতে পারে। Python-এর testing পর্বে এর ব্যবহারিক রূপ দেখতে পারেন; কোন test double কখন উপযুক্ত, পর্ব ৪৯-এ।

কখন DIP বাড়াবাড়ি

প্রতিটি class-এর জন্য একটি interface — IPriceCalculator আর তার একমাত্র PriceCalculatorImpl — অনেক “enterprise” কোডবেসের পরিচিত দৃশ্য। এতে file দ্বিগুণ হয়, কোড পড়তে লাফাতে হয়, কিন্তু লাভ প্রায় নেই। Martin নিজেও বলেন, স্থির concrete জিনিসের (যেমন language-এর string class) ওপর সরাসরি নির্ভর করা সমস্যা নয়; DIP-এর লক্ষ্য অস্থির (volatile) detail. নিজেকে তিনটি প্রশ্ন করুন:

• এটি কি boundary? Database, network, file, ঘড়ি, তৃতীয় পক্ষের API, হার্ডওয়্যার — এদের পেছনে abstraction প্রায় সবসময় লাভজনক।
• এর কি দ্বিতীয় বাস্তবায়ন আছে বা আসবে? Test-এর fake-ও একটি বাস্তবায়ন। কোনো দিন না এলে পর্ব ২৬-এর YAGNI মনে করুন।
• এটি কি স্থির? Python-এর datetime.date, Decimal, নিজের value object (যেমন Money) — এদের interface-এর পেছনে লুকানো অপ্রয়োজনীয়।

একটি ছোট script বা দুই দিনের prototype-এ সরাসরি sqlite3 ডাকা সম্পূর্ণ যুক্তিসঙ্গত। পরে দরকার হলে abstraction বের করা (refactoring, পর্ব ৪২) সাধারণত সস্তা — যদি policy আর detail একই function-এ জট পাকিয়ে না থাকে। অর্থাৎ শুরু থেকে interface না লিখলেও, policy আর I/O আলাদা function-এ রাখার অভ্যাস প্রায় বিনামূল্যে ভবিষ্যতের পথ খোলা রাখে।

৮ · AI-এর যুগে SOLID

AI-কে “SOLID মেনে refactor করো” বললে সে আনন্দের সাথে কোড তিনগুণ লম্বা করে দেয়। কিছু ভুল প্রায়ই দেখা যায়:

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

• প্রতিটি subclass-এ base-এর contract test চালিয়েছি; কোনো test “skip” করতে হয়নি
• নতুন কোডে isinstance/type() দিয়ে subclass আলাদা করা বা NotImplementedError override নেই
• প্রতিটি নতুন interface-এর অন্তত দুটি বাস্তবায়ন (production আর test fake) আছে, বা লিখিত কারণ আছে
• Import-এর দিক নিজে দেখেছি: policy-র package detail-এর package import করে না
• AI-এর লেখা test ইচ্ছা করে ভাঙা কোডে চালিয়ে দেখেছি যে সত্যিই ফেল করে
• পুরো diff একটি আলাদা branch-এ pull request হিসেবে review করেছি; বড় refactoring ছোট commit-এ ভাগ করা (পর্ব ১৬, ১৮)
• Prompt-এ কোনো secret, password, গ্রাহকের তথ্য বা প্রতিষ্ঠানের গোপন কোড দিইনি; AI-এর দেওয়া কোডের উৎস ও licence নিয়ে সন্দেহ হলে যাচাই করেছি