Design pattern কী — Gang of Four, pattern-এর ভাষা আর কখন নয়

১ · Design pattern কী — নাম দেওয়া, বারবার ব্যবহারযোগ্য সমাধান

মডিউল ৫-এ আপনি নকশার নীতি শিখেছেন: coupling-cohesion (পর্ব ২৫), DRY-KISS-YAGNI (পর্ব ২৬), SOLID (পর্ব ২৭-২৮), আর UML-এ নকশা আঁকা (পর্ব ২৯-৩০)। নীতি বলে কোন দিকে যেতে হবে। কিন্তু প্রতিদিনের কাজে প্রশ্নটা আরও নির্দিষ্ট: “এই ধরনের সমস্যা আগে কেউ সমাধান করেছে? কীভাবে?” এই প্রশ্নের জমানো উত্তরগুলোর নাম design pattern.

সংজ্ঞার প্রতিটি শব্দের ওজন আছে:

• বারবার ফিরে আসা: একবার দেখা চালাকি pattern নয়। Pattern-লেখকদের মধ্যে একটি প্রচলিত রীতি আছে — অন্তত তিনটি স্বাধীন বাস্তব ব্যবহার (known uses) না দেখলে কোনো সমাধানকে pattern বলা হয় না। একে অনেকে pattern-এর “rule of three” বলেন (পর্ব ২৬-এর refactoring-এর rule of three-এর থেকে আলাদা প্রসঙ্গ, তবে চিন্তা কাছাকাছি)।
• প্রেক্ষাপট: একই সমাধান এক প্রেক্ষাপটে ঠিক, আরেকটিতে ভুল।
• শর্ত (forces): যে চাহিদাগুলো একে অপরকে টানে — নমনীয়তা চাই, কিন্তু সরলতাও চাই; গতি চাই, কিন্তু মেমরি কম। Pattern এই টানাপোড়েনের একটি ভারসাম্য।
• ফলাফল: প্রতিটি pattern-এর দাম আছে — বেশি class, বেশি indirection, পড়তে বেশি সময়। দাম না জানলে pattern জানা অর্ধেক।

Pattern কী নয়

২ · স্থপতির খাতা থেকে software-এ — Alexander থেকে Gang of Four

Alexander-এর pattern ছিল মানুষের বসবাসের জায়গার জন্য, GoF-এর pattern class আর object-এর দায় ভাগের জন্য — কিন্তু ছাঁচটি একই থাকল। আর সবচেয়ে বড় উত্তরাধিকার হলো শব্দভান্ডার: “এখানে একটা Adapter বসাই” বললে আধা পাতার ব্যাখ্যা বেঁচে যায়।

৩ · GoF-এর ২৩টি pattern — তিন পরিবার আর মডিউল ৬-এর মানচিত্র

GoF pattern-গুলোকে দুইভাবে ভাগ করেছেন। প্রথম ভাগ উদ্দেশ্য (purpose) ধরে:

• Creational pattern — object তৈরির প্রক্রিয়া আড়াল করে: কে, কখন, কোন class-এর object বানাবে।
• Structural pattern — class আর object জোড়া দিয়ে বড় কাঠামো বানায়: মোড়ানো, সাজানো, সামনে একটি সরল দরজা।
• Behavioral pattern — object-গুলোর মধ্যে আচরণ আর দায় ভাগ করে: কে কাকে জানাবে, কে কোন ধাপ করবে, কোন algorithm চলবে।

দ্বিতীয় ভাগ পরিসর (scope) ধরে: কিছু pattern class-এর স্তরে, inheritance দিয়ে, compile-এর সময় ঠিক হয় (যেমন Factory Method, Template Method, Interpreter, আর Adapter-এর class রূপ); বাকি বেশিরভাগ object-এর স্তরে, composition দিয়ে, চলার সময় বদলানো যায়। দ্বিতীয় দলটি অনেক বড় — অংশ ৫-এ এর কারণ দেখবেন।

নামগুলো এক লাইনে — বিস্তারিত পরের পর্বগুলোতে। যে চারটি pattern-এর আলাদা পর্ব নেই (Bridge, Flyweight, Interpreter, Memento), সেগুলোর পরিচয় এখানে একটু বেশি দেওয়া হলো।

৪ · একটি pattern-এর বিবরণ পড়া — GoF-এর ছাঁচ আর class diagram

GoF বইয়ের প্রতিটি pattern একই ছাঁচে লেখা। ছাঁচটি চিনলে যেকোনো pattern বই — বা অনলাইনের যেকোনো বিবরণ — দ্রুত পড়া যায়, আর কোন অংশ বাদ পড়েছে তাও ধরা যায়।

তেরোটি অংশের মধ্যে প্রথমবার পড়ার সময় তিনটিতে জোর দিন: Intent (কী সমস্যা), Applicability (কখন), আর Consequences (দাম)। অনেক অনলাইন লেখা শুধু Structure আর Sample Code দেখায় — ঠিক যে দুটি অংশ একা পড়লে pattern “মুখস্থ করার জিনিস” মনে হয়। নিচের stepper-এ Strategy pattern-এর বিবরণ অংশ ধরে পড়া হলো — বইয়ের ভাষা নয়, আমাদের সংক্ষেপ। “পরে” চাপুন।

Pattern-এর class diagram পড়া

পর্ব ২৯-এ (UML class diagram) আপনি সব চিহ্ন শিখেছেন। Pattern-এর diagram পড়তে শুধু চারটি প্রশ্ন করুন: (১) কোনটি চুক্তি — interface বা abstract class (নাম italic বা «interface»)? (২) কোন class-গুলো চুক্তি পূরণ করে — ফাঁপা ত্রিভুজ, ড্যাশ রেখায় realization, পূর্ণ রেখায় generalization? (৩) কে কাকে ধরে রাখে — হীরা বা তীরওয়ালা association? (৪) কে কাকে শুধু ব্যবহার করে বা বানায় — ড্যাশ খোলা তীর? তারপর নামগুলো আপনার সমস্যার শব্দে বদলে নিন: Context = Checkout, Strategy = Discount.

৫ · GoF-এর দুই মূল নীতি — interface ধরে লিখুন, composition বেছে নিন

অনেকে ভুলে যান, GoF বইয়ের প্রথম অধ্যায়টি pattern-এর তালিকা নয় — একটি নকশা-দর্শন। সেখানে দুটি নীতি আছে, যা পরের ২৩টি pattern-এর অনেকগুলোর ভিত্তি।

এই দুই নীতি দেখলে বোঝা যায়, কেন GoF-এর বেশিরভাগ pattern “object” পরিসরের। Strategy, Decorator, Observer, Composite, State — সবগুলোতে একটি object আরেকটি object-কে interface ধরে ধরে রাখে, আর চলার সময় তাকে বদলানো যায়। পর্ব ৩৭-এ (dependency injection আর composition) দেখবেন, এই object-গুলো বাইরে থেকে জোড়া লাগানোর পরিচ্ছন্ন উপায় কী। আর মনে রাখুন — GoF inheritance নিষেধ করেননি; Template Method আর Factory Method inheritance-এর ওপরই দাঁড়িয়ে। নীতিটি “অগ্রাধিকার”, নিষেধাজ্ঞা নয়।

৬ · আধুনিক ভাষায় pattern — function যখন নিজেই strategy

GoF-এর উদাহরণ ১৯৯০-এর দশকের C++-এ। সেই C++-এ function-কে মানের মতো পাঠানোর সহজ পথ ছিল সীমিত (function pointer ছিল, কিন্তু চারপাশের data ধরে রাখা lambda আসে C++11-এ, ২০১১ সালে)। তাই “একটি আচরণ পাঠাও” বোঝাতে একটি class বানিয়ে তার object পাঠানো হতো। JavaScript আর Python-এ function first-class — variable-এ রাখা যায়, argument-এ পাঠানো যায়, ফেরত দেওয়া যায়। Java-তেও lambda এসেছে Java 8-এ (২০১৪)। ফলে কয়েকটি pattern-এর চেহারা নাটকীয়ভাবে ছোট হয়ে যায়।

চালিয়ে দেখুন — একই ছাড়ের সমস্যা, দুই সমাধান

একটি কাল্পনিক অনলাইন বাজার অ্যাপ। Checkout-এ তিন রকম ছাড়: কোনো ছাড় নেই, ১০% ছাড়, আর ১০০০ টাকা বা বেশি কিনলে ২০০ টাকা ছাড়। (A) অংশে GoF-ধাঁচের Strategy — একটি abstract base class আর প্রতি নিয়মে একটি class; (B) অংশে একই চিন্তা শুধু function দিয়ে, যেখানে higher-order function নিয়ম বানায়। শেষে প্রতিটি সমাধানের সংজ্ঞা কত লাইনের, তা function-এর নিজের source থেকে গোনা হয়েছে।

// Fictional online bazaar: pluggable discount rules, solved two ways.
// (A) GoF-style Strategy: an abstract base class + one class per rule
class Discount { apply(total) { throw new Error("abstract"); } }
class NoDiscount extends Discount { apply(t) { return t; } }
class PercentOff extends Discount {
  constructor(p) { super(); this.p = p; }
  apply(t) { return Math.round(t * (100 - this.p) / 100); }
}
class FlatOff extends Discount {
  constructor(amount, min) { super(); this.amount = amount; this.min = min; }
  apply(t) { return t >= this.min ? t - this.amount : t; }
}
class Checkout {
  constructor(strategy) { this.strategy = strategy; }
  pay(total) { return this.strategy.apply(total); }
}
// (B) The same idea with plain functions: a strategy is just a function
const none = t => t;
const percentOff = p => t => Math.round(t * (100 - p) / 100);
const flatOff = (amount, min) => t => (t >= min ? t - amount : t);
const pay = (rule, total) => rule(total);

const A = [new NoDiscount(), new PercentOff(10), new FlatOff(200, 1000)];
const B = [none, percentOff(10), flatOff(200, 1000)];
for (const total of [450, 1200, 2500]) {
  const a = A.map(s => new Checkout(s).pay(total));
  const b = B.map(rule => pay(rule, total));
  console.log(total, "classes:", a.join(" "), "| functions:", b.join(" "),
              a.join() === b.join() ? "same" : "DIFFERENT");
}
const lines = f => f.toString().split("\n").length;
const sum = fs => fs.map(lines).reduce((x, y) => x + y, 0);
console.log("lines A:", sum([Discount, NoDiscount, PercentOff, FlatOff, Checkout]),
            "| lines B:", sum([none, percentOff, flatOff, pay]));

450 classes: 450 405 450 | functions: 450 405 450 same
1200 classes: 1200 1080 1000 | functions: 1200 1080 1000 same
2500 classes: 2500 2250 2300 | functions: 2500 2250 2300 same
lines A: 14 | lines B: 4

Observer বনাম callback — একই ঘটনা, দুই পোশাক

একটি কাল্পনিক বাস-টিকিট অ্যাপ। একটি seat-এর অবস্থা বদলালে SMS অংশ আর কাউন্টারের screen জানবে। (A)-তে GoF Observer — subject একটি তালিকায় observer object রাখে, যাদের update() আছে। (B)-তে একই কাজ callback দিয়ে — listener নিছক একটি function, আর on() একটি “বন্ধ করার” function ফেরত দেয়। দুই অংশেই প্রথম ঘটনার পর SMS অংশকে সরানো হয়।

// Fictional bus-ticket app: when a seat changes, several parts must react.
let log = [];
// (A) GoF Observer: a subject keeps observer OBJECTS that have update()
class SeatSubject {
  constructor() { this.observers = []; }
  attach(o) { this.observers.push(o); }
  detach(o) { this.observers = this.observers.filter(x => x !== o); }
  notify(ev) { for (const o of this.observers) o.update(ev); }
}
class SmsObserver { update(ev) { log.push(`sms ${ev.seat} ${ev.status}`); } }
class BoardObserver { update(ev) { log.push(`board ${ev.seat}=${ev.status}`); } }
// (B) The same with callbacks: a listener is just a FUNCTION
function makeEmitter() {
  const fns = new Set();
  return {
    on(f) { fns.add(f); return () => fns.delete(f); },  // returns "off"
    emit(ev) { fns.forEach(f => f(ev)); },
  };
}
const subject = new SeatSubject(), sms = new SmsObserver();
subject.attach(sms); subject.attach(new BoardObserver());
subject.notify({ seat: "A3", status: "booked" });
subject.detach(sms);
subject.notify({ seat: "B1", status: "free" });
const fromObserver = log; log = [];

const seats = makeEmitter();
const offSms = seats.on(ev => log.push(`sms ${ev.seat} ${ev.status}`));
seats.on(ev => log.push(`board ${ev.seat}=${ev.status}`));
seats.emit({ seat: "A3", status: "booked" });
offSms();
seats.emit({ seat: "B1", status: "free" });
console.log("observer :", fromObserver.join(" ; "));
console.log("callbacks:", log.join(" ; "));
console.log("same result:", fromObserver.join() === log.join());

observer : sms A3 booked ; board A3=booked ; board B1=free
callbacks: sms A3 booked ; board A3=booked ; board B1=free
same result: true

৭ · GoF-এর বাইরে — enterprise, concurrency, cloud আর architecture pattern

২৩টি GoF pattern পুরো জগৎ নয়, একটি পাড়া মাত্র। একই ছাঁচে — প্রেক্ষাপট, সমস্যা, সমাধান, ফলাফল — আরও অনেক catalog লেখা হয়েছে। প্রতিটির জন্য এক লাইন:

শিক্ষাটি একটাই: “pattern” কোনো বইয়ের সম্পত্তি নয়, অভিজ্ঞতা লিখে রাখার একটি ধরন। যেকোনো ক্ষেত্রে — testing, UI, security, data pipeline — অভিজ্ঞ মানুষ বারবার একই সমাধানে পৌঁছালে কেউ না কেউ তার নাম দেন।

৮ · Anti-pattern আর কখন pattern নয়

Pattern যদি “বারবার কাজ করা সমাধান” হয়, তবে anti-pattern হলো “বারবার দেখা যায় এমন সমাধান, যা দেখতে যুক্তিসংগত, কিন্তু শেষ পর্যন্ত লাভের চেয়ে ক্ষতি বেশি করে”। শব্দটি সাধারণত Andrew Koenig-এর নামে উল্লেখ হয় — ১৯৯৫ সালে Journal of Object-Oriented Programming-এ একটি লেখায় তিনি এটি ব্যবহার করেন। ১৯৯৮ সালে Brown, Malveau, McCormick ও Mowbray-এর AntiPatterns বইটি ধারণাটিকে জনপ্রিয় করে।

কখন pattern নয় — পাঁচটি প্রশ্ন

1. সমস্যাটি কি আজ আছে? “পরে লাগতে পারে” প্রমাণ নয়। পর্ব ২৬-এর YAGNI: দ্বিতীয় রূপ আসার আগে strategy বানানো প্রায়ই অপচয়।
2. সবচেয়ে সরল সমাধান কী, আর সেটা কেন যথেষ্ট নয়? একটি function, একটি dictionary, একটি if — এগুলোর সাথে তুলনা না করে pattern বেছে নেবেন না (KISS).
3. ভাষা কি কাজটা আগেই করে দেয়? Iterator লিখতে বসার আগে for…of, Observer-এর আগে ভাষার event ব্যবস্থা।
4. দাম কে দেবে? প্রতিটি নতুন class আর indirection পরের পাঠককে পড়তে হবে।
5. পরে আনা কি কঠিন হবে? ভালো test থাকলে সরল কোড থেকে pattern-এ যাওয়া কয়েক মিনিটের refactoring (পর্ব ৪২)। আজ সরল রাখার ঝুঁকি সাধারণত কম।

চালিয়ে দেখুন — একটি খেলনা “pattern smell” খোঁজক

নিচের Python প্রোগ্রাম standard library-র ast module দিয়ে একটি কাল্পনিক দোকান-অ্যাপের কোড পড়ে (চালায় না, শুধু গঠন দেখে)। নিয়ম দুটি, স্পষ্ট করে বলা: R1 — যে class-এর কোনো base class নেই আর public method ঠিক একটি, সেটি সম্ভবত class-এর পোশাক পরা একটি function; R2 — যে base class-এর ঠিক একটি subclass, সেটি সম্ভবত অকালপক্ব abstraction. এগুলো বিচার নয়, প্রশ্ন তোলার সংকেত।

import ast

SOURCE = '''
class PriceFormatter:
    def __init__(self, currency): self.currency = currency
    def format(self, amount): return f"{amount} {self.currency}"
class VatCalculator:
    def calculate(self, amount): return amount * 15 // 100
class Cart:
    def __init__(self): self.items = []
    def add(self, item): self.items.append(item)
    def total(self): return sum(i.price for i in self.items)
class ShippingRule:
    def cost(self, kg): raise NotImplementedError
class FlatShipping(ShippingRule):
    def cost(self, kg): return 60
'''
# Stated toy heuristic, not a law:
#  R1  no base class, exactly ONE public method -> probably a function
#  R2  a base class with exactly ONE subclass   -> single-use abstraction
classes = [n for n in ast.parse(SOURCE).body if isinstance(n, ast.ClassDef)]
children = {}
for c in classes:
    for b in c.bases: children.setdefault(b.id, []).append(c.name)
for c in classes:
    methods = [f.name for f in c.body if isinstance(f, ast.FunctionDef)]
    public = [m for m in methods if not m.startswith("_")]
    kids = children.get(c.name, [])
    if len(kids) == 1:
        print(f"{c.name}: R2 only {kids[0]} implements it -> inline until a 2nd rule")
    elif not c.bases and len(public) == 1:
        extra = " (pass its __init__ data as a parameter)" if "__init__" in methods else ""
        print(f"{c.name}: R1 one method '{public[0]}' -> plain function{extra}")
    else:
        print(f"{c.name}: ok (public methods: {len(public)}, base classes: {len(c.bases)})")

PriceFormatter: R1 one method 'format' -> plain function (pass its __init__ data as a parameter)
VatCalculator: R1 one method 'calculate' -> plain function
Cart: ok (public methods: 2, base classes: 0)
ShippingRule: R2 only FlatShipping implements it -> inline until a 2nd rule
FlatShipping: ok (public methods: 1, base classes: 1)

এবার একটি পুরো over-patterned নকশাকে ধাপে ধাপে সরল করা যাক। কাল্পনিক একটি বিশ্ববিদ্যালয়ের ফলাফল পোর্টালে GPA হিসাবের কোড। নিয়ম একটিই, আর তিন বছরে বদলায়নি; তবু কেউ “ভবিষ্যতের জন্য” ছয়টি pattern-এর চিহ্ন বসিয়েছেন। প্রতিটি ধাপে আগে test চলে, পরে বদল।

৯ · Pattern বেছে নেওয়া — সমস্যা থেকে নাম, আর review-ইন্টারভিউতে pattern-এর ভাষা

নতুনদের সবচেয়ে বড় ভুল হলো pattern দিয়ে শুরু করা: “আজ একটা Visitor ব্যবহার করব।” পেশাদার পথ উল্টো — সমস্যা থেকে শুরু, কী বদলায় তা খোঁজা, তারপর সবচেয়ে সরল সমাধানের সাথে pattern-এর তুলনা। নিচের টেবিলটি একটি শুরুর মানচিত্র, আইন নয়।

এখন একটি কাল্পনিক সমস্যা নিয়ে পুরো সিদ্ধান্ত-প্রক্রিয়া। একটি বাস-টিকিট অ্যাপে ঈদের আগে seat-এর অবস্থা বদলালে কয়েকটি অংশকে জানাতে হয়, আর নতুন অংশ যোগ হতেই থাকে। “পরে” চাপুন।

অনুশীলনের খেলনা — সমস্যার শব্দ থেকে pattern-এর তালিকা

নিচের প্রোগ্রাম বেছে নেওয়ার অনুশীলনের জন্য, সিদ্ধান্তের জন্য নয়। প্রতিটি pattern-এর কয়েকটি “সংকেত-শব্দ” আছে; একটি সমস্যার বর্ণনায় যতগুলো সংকেত-শব্দ পাওয়া যায়, সেটাই score. সমান score হলে নামের বর্ণানুক্রম। ০ score দেখানো হয় না। সমস্যাগুলো ইংরেজিতে, কারণ শব্দ মেলানো ইংরেজি অক্ষরে।

// Toy pattern finder (study aid only). Stated rule: score = number of a pattern's
// cue words found in the problem; ties alphabetical; score 0 is not shown.
const catalogue = {
  "Adapter":         ["incompatible", "legacy", "convert", "wrap", "interface"],
  "Builder":         ["construct", "options", "step", "complex", "object"],
  "Command":         ["undo", "queue", "request", "action", "history"],
  "Composite":       ["tree", "nested", "part", "whole", "uniform"],
  "Decorator":       ["add", "wrap", "layer", "runtime", "optional"],
  "Facade":          ["subsystem", "complex", "simple", "entry", "many"],
  "Factory Method":  ["create", "subclass", "decide", "type"],
  "Iterator":        ["traverse", "collection", "sequence", "hide"],
  "Observer":        ["notify", "subscribe", "event", "many", "change"],
  "State":           ["status", "mode", "transition", "state"],
  "Strategy":        ["algorithm", "rule", "swap", "variant", "policy"],
  "Template Method": ["steps", "skeleton", "order", "hook", "subclass"],
};
function suggest(problem, top = 3) {
  const words = new Set(problem.toLowerCase().split(/[^a-z]+/));
  return Object.entries(catalogue)
    .map(([name, cues]) => [name, cues.filter(w => words.has(w)).length])
    .filter(([, score]) => score > 0)
    .sort((a, b) => b[1] - a[1] || (a[0] < b[0] ? -1 : 1))
    .slice(0, top);
}
const problems = [
  "notify many screens when a seat status change event happens",
  "swap the delivery fee rule for each district variant",
  "wrap a legacy payment library with an incompatible interface",
  "undo the last action in a ticket editor",
  "print one invoice as a PDF",
];
for (const p of problems) {
  const r = suggest(p).map(([n, s]) => `${n}(${s})`).join(", ");
  console.log(`${p}\n   -> ${r || "no cue matched: maybe no pattern needed"}`);
}

notify many screens when a seat status change event happens
   -> Observer(4), Facade(1), State(1)
swap the delivery fee rule for each district variant
   -> Strategy(3)
wrap a legacy payment library with an incompatible interface
   -> Adapter(4), Decorator(1)
undo the last action in a ticket editor
   -> Command(2)
print one invoice as a PDF
   -> no cue matched: maybe no pattern needed

Code review আর ইন্টারভিউতে pattern-এর ভাষা

Pattern-এর সবচেয়ে বড় দৈনন্দিন লাভ শব্দভান্ডার। Code review-এ (পর্ব ৪৪) “এখানে Strategy” বললে reviewer জানেন কী খুঁজতে হবে: চুক্তিটা কোথায়, রূপগুলো কোথায়, কে বেছে দেয়। তবে ভাষার সাথে দায়িত্বও আসে:

• নাম বলুন, কারণও বলুন। “Observer ব্যবহার করেছি, কারণ খবর-পাওয়ার তালিকা প্রতি মাসে বাড়ছে” — কারণ ছাড়া pattern-এর নাম শুধু অলংকার।
• Review-তে উল্টো প্রশ্নও করুন। “এই abstraction কোন বদল সহজ করছে? দ্বিতীয় রূপটি কোথায়?” — pattern-itis ধরার সবচেয়ে ভদ্র প্রশ্ন।
• ইন্টারভিউতে সাধারণত তিন রকম প্রশ্ন আসে: একটি pattern বোঝানো (intent, কাঠামো, একটি উদাহরণ), দুটি pattern-এর পার্থক্য (Strategy বনাম State, Adapter বনাম Decorator), আর “আপনার কোনো project-এ pattern কোথায় কাজে লেগেছে, আর কোথায় ভুল ছিল”। শেষটিতে অতিরিক্ত pattern সরানোর গল্পও শক্ত উত্তর। পর্ব ৭০-এ (Software engineering ইন্টারভিউ) আরও অনুশীলন।

১০ · AI-এর যুগে — AI-এর “pattern-সমৃদ্ধ” কোড যাচাই

AI-কে design pattern ব্যবহার করে কোড লিখতে বললে প্রায় সবসময় কোড আসে — অনেক interface, factory আর manager-সহ। দেখতে পেশাদার, কিন্তু প্রয়োজন আছে কি না, তা AI জানে না; সে জানে আপনি pattern চেয়েছেন। এই বিষয়ে AI-এর চেনা ভুল:

AI-এর দেওয়া pattern-ওয়ালা কোড হাতে পেলে — চেকলিস্ট

• প্রতিটি pattern-এর পেছনে একটি প্রমাণিত বদলের অক্ষ আছে; না থাকলে সরল রূপে নামিয়েছি
• Pattern-এর নাম তার Intent-এর সাথে মেলে; Adapter-Decorator, Strategy-State গুলিয়ে যায়নি
• UML diagram-এর প্রতিটি তীর আর হীরা কোডের সম্পর্কের সাথে মিলিয়েছি
• আগের test রেখে চালিয়েছি; একটি ইচ্ছাকৃত bug ঢুকিয়ে দেখেছি test ব্যর্থ হয়
• Diff পুরোটা একটি আলাদা branch-এ পড়েছি; চোখ বন্ধ করে merge করিনি
• উদ্ধৃতি, বই আর বছর মূল উৎসে মিলিয়েছি; কোডের license আর prompt-এর গোপনীয়তা দেখেছি