লিখিত ও মৌখিক (ভাইভা) প্রশ্ন — process, requirement, design, testing আর management

সংজ্ঞা: IEEE-র প্রচলিত সংজ্ঞায় software engineering হলো software-এর উন্নয়ন, পরিচালনা আর রক্ষণাবেক্ষণে একটি নিয়মবদ্ধ, শৃঙ্খলাপূর্ণ আর মাপা যায় এমন পদ্ধতির প্রয়োগ। Programming আজকের সমস্যার কোড লেখা; software engineering সেই কোডকে বহু বছর, বহু মানুষ মিলে নিরাপদে বদলানোর বিদ্যা — তাই এতে requirement, নকশা, test, version control, দলগত কাজ আর maintenance-ও পড়ে।

Brooks-এর চার কঠিনতা (“No Silver Bullet”, ১৯৮৬): complexity (অংশগুলোর পারস্পরিক জটিলতা), conformity (বাইরের নিয়ম আর system-এর সাথে মানিয়ে চলা), changeability (ক্রমাগত বদলের চাপ), invisibility (গঠন চোখে দেখা যায় না)।

নম্বর কোথায়: সংজ্ঞা (১), পার্থক্যে দুটি নির্দিষ্ট দিক (১), চার কঠিনতা নামসহ (২)। পর্ব ১

যেখানে নম্বর কাটে: “ভালো কোড লেখা” বলে থেমে যাওয়া; maintenance আর দলের দিকটি বাদ দেওয়া।

Software crisis: ১৯৬০-এর দশকের শেষে বড় project প্রায়ই দেরিতে শেষ হতো, বাজেট ছাড়াত আর ভুলে ভরা থাকত; হার্ডওয়্যার যত দ্রুত বড় হচ্ছিল, প্রোগ্রাম লেখার পদ্ধতি তত দ্রুত এগোয়নি। NATO সম্মেলন (Garmisch, ১৯৬৮) “software engineering” নামটিকে জনপ্রিয় করে — লক্ষ্য ছিল প্রোগ্রাম বানানোকে প্রকৌশলের নিয়মে আনা।

Brooks’s law (The Mythical Man-Month, ১৯৭৫): দেরি হওয়া project-এ লোক বাড়ালে প্রায়ই আরও দেরি — নতুনদের শেখাতে সময় যায়, আর যোগাযোগের পথ বাড়ে n(n−1)/2 হারে।

1. ৬ জনে: ৬ × ৫ ÷ ২ = ১৫টি পথ।
2. ৮ জনে: ৮ × ৭ ÷ ২ = ২৮টি পথ — ১৩টি বাড়ল, অথচ মানুষ বাড়ল মাত্র ২ জন।

নম্বর কোথায়: crisis-এর লক্ষণ (১), NATO-র সাল ও গুরুত্ব (১), Brooks’s law ও কারণ (১.৫), হিসাব (১.৫)। পর্ব ২ · পর্ব ১

যেখানে নম্বর কাটে: পথের সংখ্যা n² বা n লেখা; Brooks’s law-কে “কখনো লোক বাড়াবেন না” বলে চরম করে লেখা — project-এর শুরুতে বা স্বাধীন কাজে লোক বাড়ানো কাজে আসতে পারে।

পার্থক্য: fault = কোডের ভুল (যেমন >-এর জায়গায় >=), ঘুমিয়ে থাকতে পারে; error = নির্দিষ্ট ইনপুটে fault জেগে ভুল অবস্থা তৈরি করে; failure = সেই ভুল বাইরে দেখা দেয় — ব্যবহারকারী ভুল ফল পান।

1. DRE = release-এর আগে ধরা ÷ মোট = ৯০ ÷ (৯০ + ১০) = ০.৯০, অর্থাৎ ৯০%.
2. Availability = MTBF ÷ (MTBF + MTTR) = ৫০০ ÷ ৫০২ ≈ ০.৯৯৬০, অর্থাৎ প্রায় ৯৯.৬%.

মানে: MTTR অর্ধেক করলে (১ ঘণ্টা) availability প্রায় ৯৯.৮% — দ্রুত মেরামতও reliability-র মতোই গুরুত্বপূর্ণ।

নম্বর কোথায়: তিন সংজ্ঞা আর একটি উদাহরণ (২), DRE সূত্র ও মান (১.৫), availability (১.৫)। পর্ব ৩

যেখানে নম্বর কাটে: DRE-তে ৯০ ÷ ১০ = ৯ লেখা; MTTR-কে MTBF-এর সাথে যোগ না করা; fault আর failure গুলিয়ে ফেলা।

কখন কোনটি: requirement স্থির, ছোট, নিয়মে বাঁধা কাজে (যেমন পুরোনো system-এর হুবহু স্থানান্তর) waterfall; বড়, দামি, প্রযুক্তি-ঝুঁকির project-এ (নতুন payment বা রেলের সংকেত) spiral.

নম্বর কোথায়: চার–পাঁচ সারির টেবিল (৪), কখন কোনটি (১)। পর্ব ৪

যেখানে নম্বর কাটে: spiral-এর চার quadrant-এর নাম না জানা (লক্ষ্য ও বিকল্প → ঝুঁকি বিশ্লেষণ ও prototype → তৈরি ও যাচাই → পরের পরিকল্পনা); spiral-কে শুধু “বারবার waterfall” বলা।

সংজ্ঞা: SDLC হলো requirement → design → construction → testing → deployment → maintenance ধাপের জীবনচক্র; process model ঠিক করে ধাপগুলো কোন ক্রমে, কতবার আর কোন যাচাই-বিন্দু মেনে চলবে।

ছবি (খাতায় পাঁচটি ছোট স্কেচ): waterfall — ওপর থেকে নিচে সিঁড়ি; V-model — বাঁ বাহুতে requirement → system design → architecture → module design, তলায় coding, ডান বাহুতে unit → integration → system → acceptance test, আর প্রতিটি জোড়ার মাঝে আড়াআড়ি ড্যাশ রেখা; incremental — পরপর কয়েকটি ছোট waterfall, প্রতিটির শেষে একটি release; spiral — ভেতর থেকে বাইরে ঘোরা loop, চার quadrant; Agile — ছোট sprint-এর বৃত্ত, প্রতিটির শেষে কাজ করা increment আর feedback-এর তীর।

উপসংহার: কোনো মডেল সব জায়গায় সেরা নয়; requirement-এর স্থিরতা, ঝুঁকি আর চুক্তি দেখে বাছাই — বাস্তবে প্রায়ই hybrid. উত্তরটি ধাপে ধাপে গড়া আছে অংশ ১-এর stepper-এ।

নম্বর কোথায়: সংজ্ঞা (১), ছবির বর্ণনা (৩), টেবিল (৩), কখন কোনটি (২), উপসংহার (১)। পর্ব ৪ · পর্ব ৫

যেখানে নম্বর কাটে: incremental আর iterative এক বলে লেখা (প্রথমটি অংশ যোগ, দ্বিতীয়টি বারবার উন্নত করা — বাস্তবে একসাথে চলে); V-model-এর আড়াআড়ি জোড়া বাদ।

ভিত্তি: Agile Manifesto (২০০১) — ৪টি মূল্যবোধ, ১২টি নীতি। Scrum তার একটি হালকা কাঠামো; নিচের কথাগুলো Scrum Guide-এর ২০২০ সংস্করণ অনুযায়ী (আগের সংস্করণে “role” আর “Development Team” বলা হতো)।

• তিন দায়িত্ব: Product Owner (মূল্য বাড়ানো, Product Backlog-এর মালিক), Scrum Master (Scrum-এর কার্যকারিতা, বাধা দূর — project manager নন), Developers (প্রতিটি sprint-এ ব্যবহারযোগ্য increment).
• পাঁচ event: Sprint (এক মাস বা কম), Sprint Planning (এক মাসের sprint-এ সর্বোচ্চ ৮ ঘণ্টা), Daily Scrum (১৫ মিনিট), Sprint Review (সর্বোচ্চ ৪ ঘণ্টা), Sprint Retrospective (সর্বোচ্চ ৩ ঘণ্টা)।
• তিন artifact ও তার commitment: Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done.

ছবি: বাঁয়ে Product Backlog-এর স্তূপ → Sprint Planning → Sprint Backlog → একটি বড় বৃত্ত (sprint) আর তার ওপরে ছোট বৃত্ত (Daily Scrum) → Increment → Review আর Retrospective থেকে backlog-এ ফেরার তীর।

Forecast: গড় velocity = (১৮ + ২২ + ২০) ÷ ৩ = ২০; ১২০ ÷ ২০ = ৬ sprint. সৎ উত্তর পরিসরে: ধীরতম ১৮ ধরলে ১২০ ÷ ১৮ ≈ ৬.৭, অর্থাৎ ৭ sprint; দ্রুততম ২২-এ ১২০ ÷ ২২ ≈ ৫.৫, অর্থাৎ ৬ sprint. তাই “৬ থেকে ৭ sprint”.

নম্বর কোথায়: দায়িত্ব (২), event ও timebox (৩), artifact ও commitment (২), ছবি (১), forecast পরিসরসহ (২)। পর্ব ৫

যেখানে নম্বর কাটে: Scrum Master-কে দলের boss বলা; velocity-কে দলের পারফরম্যান্সের মাপ বা দুই দলের তুলনার সংখ্যা হিসেবে ব্যবহার; একটি মাত্র সংখ্যায় প্রতিশ্রুতি।

হিসাব (Little-এর সূত্র): গড় cycle time = গড় WIP ÷ গড় throughput = ১২ ÷ ৩ = ৪ দিন. Throughput একই থাকলে WIP ৬-এ নামালে ৬ ÷ ৩ = ২ দিন — কম কাজ একসাথে, তাড়াতাড়ি শেষ।

নম্বর কোথায়: চার সারির টেবিল (২.৫), সূত্র (১), দুই মান (১.৫)। পর্ব ৬

যেখানে নম্বর কাটে: সূত্র উল্টো লেখা (throughput ÷ WIP); “WIP কমালে throughput কমবে” ধরে নেওয়া — সূত্রটি গড়ের সম্পর্ক, ধরে নেয় system মোটামুটি স্থিতিশীল।

Git কেন: ২০০৫ সালে Linux kernel-এর দল যে tool ব্যবহার করত, তার বিনামূল্যের লাইসেন্স বন্ধ হলে Linus Torvalds Git লেখা শুরু করেন — গতি আর হাজারো developer-এর স্বাধীন কাজই ছিল লক্ষ্য। Git আর GitHub এক নয়: প্রথমটি tool, দ্বিতীয়টি repository রাখার অনলাইন সেবা।

নম্বর কোথায়: টেবিল (৩), Git-এর জন্ম ও কারণ (১)। পর্ব ৭

যেখানে নম্বর কাটে: “distributed মানে server নেই” লেখা — দলে সাধারণত একটি কেন্দ্রীয় remote থাকে, তবে সেটি প্রথা, বাধ্যবাধকতা নয়।

তিন এলাকা: working tree (যেখানে আপনি লেখেন) → git add → staging area বা index (পরের commit-এ যা যাবে) → git commit → repository (জমা হওয়া commit, .git-এর ভেতরে)। ছবিতে তিনটি বাক্স বাঁ থেকে ডানে, ওপরে ডানমুখী তীরে add আর commit, নিচে বাঁমুখী তীরে restore --staged আর restore.

দুই অক্ষরের মানে: বাঁ অক্ষর index-এর খবর, ডান অক্ষর working tree-র।

• M  — বদল stage করা, পরের commit-এ যাবে।
•  M — বদল হয়েছে কিন্তু stage হয়নি।
• ?? — untracked, Git এখনো চেনে না।

নম্বর কোথায়: তিন এলাকা ও ছবি (৩), তিনটি অবস্থা (২)। পর্ব ৮ · পর্ব ৯

যেখানে নম্বর কাটে: “commit ফোল্ডার থেকে নেয়” লেখা — commit নেয় index থেকে; add-এর পরে আবার বদলালে নতুন বদল commit-এ যায় না।

প্রমাণ (একই বদল নিয়ে পরপর তিনটি command):

$ git commit -m "Raise fee to 650"
[main 1df2880] Raise fee to 650
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git reset --soft HEAD~1
$ git status -s
M  fee.conf
$ git reset
Unstaged changes after reset:
M	fee.conf
$ git status -s
 M fee.conf
$ git reset --hard
HEAD is now at 453a5c6 Document SMS alerts
$ git status -s
$ git revert --no-edit HEAD
[main 29c941b] Revert "Document SMS alerts"
 Date: Thu Jan 15 10:08:00 2026 +0600
 1 file changed, 1 deletion(-)

--soft-এর পরে বদল staged (M ), git reset-এর পরে unstaged ( M), --hard-এর পরে বদল নেই। Push-করা commit-এ revert: পুরোনো commit না মুছে একটি নতুন উল্টো commit যোগ হয়, তাই সহকর্মীদের clone ভাঙে না।

নম্বর কোথায়: টেবিল (৩), revert-এর যুক্তি (২)। পর্ব ১১

যেখানে নম্বর কাটে: --hard-এর ঝুঁকির কথা না বলা; push-করা commit-এ reset আর push --force লেখা।

Branch: একটি নাম, যা একটি commit-এর দিকে নির্দেশ করে — ভেতরে ৪১ বাইটের একটি ছোট ফাইল (৪০ অক্ষরের hash আর newline), file-এর কপি নয়; তাই বানানো প্রায় বিনা খরচে। HEAD: “আপনি এখানে” — সাধারণত একটি branch-এর নাম ধরে রাখে; নতুন commit-এ শুধু সেই branch সামনে সরে।

Detached HEAD: কোনো commit বা tag সরাসরি checkout করলে (git switch --detach v1.0) HEAD কোনো branch নয়, সরাসরি commit ধরে। সেখানে commit করে branch না বানিয়ে চলে গেলে commit-টি কোনো নাম থেকে পৌঁছানো যায় না; git reflog থেকে hash নিয়ে git branch rescue <hash> দিয়ে বাঁচানো যায়।

নম্বর কোথায়: branch (১), HEAD (১), detached কখন (১), ঝুঁকি ও উদ্ধার (১)। পর্ব ১২

যেখানে নম্বর কাটে: “branch মানে পুরো ফোল্ডারের কপি”; detached HEAD-কে “ভুল” বা “repository নষ্ট” বলা।

পরিস্থিতি: main-এ একটি commit (7f41025) থেকে feature/sms branch খোলা হলো, তাতে দুটি commit; এর মধ্যে main-এ একটি নতুন commit এল।

$ git log --oneline --graph --all
* d6026a4 Raise fee to 600
| * 5d30014 Document SMS alerts
| * a1aa3eb Add SMS config
|/
* 7f41025 Add fee config and README

(ক) Merge: main-এ থেকে git merge feature/sms. দুই tip আর তাদের merge base (7f41025) মিলিয়ে three-way merge; ফল দুই parent-ওয়ালা একটি merge commit. পুরোনো commit-এর hash অপরিবর্তিত।

$ git merge --no-edit feature/sms
Merge made by the 'ort' strategy.
 README.md | 1 +
 sms.conf  | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 sms.conf
$ git log --oneline --graph --all
*   2e1c093 Merge branch 'feature/sms'
|\
| * 5d30014 Document SMS alerts
| * a1aa3eb Add SMS config
* | d6026a4 Raise fee to 600
|/
* 7f41025 Add fee config and README

(খ) Rebase: একই শুরুর অবস্থা থেকে feature/sms-এ git rebase main. Branch-এর নিজস্ব দুটি commit main-এর মাথার ওপর একে একে আবার বসে; parent বদলায়, তাই hash বদলায় (a1aa3eb → 71af9ef, 5d30014 → 453a5c6). তারপর main-এ merge করলে শুধু fast-forward.

$ git rebase main
Successfully rebased and updated refs/heads/feature/sms.
$ git log --oneline --graph --all
* 453a5c6 Document SMS alerts
* 71af9ef Add SMS config
* d6026a4 Raise fee to 600
* 7f41025 Add fee config and README
$ git switch main
Switched to branch 'main'
$ git merge feature/sms
Updating d6026a4..453a5c6
Fast-forward
 README.md | 1 +
 sms.conf  | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 sms.conf

কখন কোনটি: fast-forward হয় যখন বর্তমান branch অন্যটির পূর্বপুরুষ (নিজে কোনো নতুন commit নেই); না হলে three-way. সোনালি নিয়ম: অন্যরা যে commit-এর ওপর কাজ করছেন, তা rebase করবেন না; নিজের PR branch rebase করলে push --force-with-lease দিয়ে।

নম্বর কোথায়: দুই সংজ্ঞা (২), দুটি graph (৩), টেবিল (২), ff বনাম three-way (১.৫), সোনালি নিয়ম (১.৫)। পর্ব ১৩ · পর্ব ১৫

যেখানে নম্বর কাটে: rebase-এর পরেও পুরোনো hash লেখা; merge commit-এর একটি parent আঁকা; “rebase কাজ মুছে দেয়” — পুরোনো commit ORIG_HEAD আর reflog-এ থাকে।

Fetch শুধু নতুন commit আর remote-tracking ref (origin/main) আনে, আপনার branch ছোঁয় না; pull = fetch + merge (--rebase দিলে rebase, --ff-only দিলে শুধু fast-forward). pull.rebase বা pull.ff কিছুই ঠিক না থাকলে Git ২.৫৩ ভিন্ন হয়ে যাওয়া branch-এ থেমে যায় (fatal: Need to specify how to reconcile divergent branches.) — তাই নীতিটি একবার ঠিক করে নিন।

Rejected: সহকর্মী Nasrin আগে push করেছেন, তাই remote-এ এমন commit আছে যা Rahim-এর কাছে নেই। Push শুধু fast-forward হলে গৃহীত হয়:

$ git push origin main
To …/origin.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to '…/origin.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. …

সমাধান: fetch → merge বা rebase → আবার push. Force-with-lease: সাধারণ --force remote-এর অন্যের কাজ নীরবে মুছে দিতে পারে; lease আগে মিলিয়ে নেয় remote ঠিক আপনার জানা অবস্থায় আছে কি না, না থাকলে push বাতিল।

নম্বর কোথায়: fetch বনাম pull (২), rejected-এর কারণ ও সমাধান (১.৫), lease (১.৫)। পর্ব ১৪

যেখানে নম্বর কাটে: “rejected হলে --force দিন” লেখা; origin/main-কে একটি branch ভেবে তাতে commit করার কথা বলা।

অনুমান: CI আছে, main protected, PR-এ অন্তত একজনের review লাগে; web আর app একই repository-তে।

প্রস্তাব: trunk-based development (ছোট ধাপে GitHub Flow-এর মতো) + পুরোনো version-এর জন্য একটি release branch.

1. main = trunk: সবসময় deploy করার মতো; প্রতিটি কাজ এক–দুই দিনের feature/… branch → PR → review আর CI সবুজ → merge → web deploy.
2. অসমাপ্ত কাজ: feature flag-এর পেছনে merge, যাতে branch দীর্ঘজীবী না হয়।
3. release/2.x: v2.0.0 tag থেকে কাটা; শুধু bug fix. Fix আগে main-এ, তারপর git cherry-pick -x দিয়ে release branch-এ; সেখান থেকে v2.3.1-এর মতো patch tag.
4. নিয়ম লিখিত: Conventional Commits, SemVer, CONTRIBUTING-এ এই প্রবাহ।

ছবি: একটি লম্বা আনুভূমিক রেখা main, ওপরে-নিচে ছোট ছোট feature-এর বাঁক যা কয়েক commit পরেই ফেরে; v2.0.0 tag থেকে নিচে নেমে যাওয়া release/2.x, main-এর fix commit থেকে সেখানে ড্যাশ তীর (cherry-pick).

উপসংহার: ঘন web deploy-এ trunk-based; Git Flow তখনই, যখন নির্দিষ্ট দিনে version নম্বরসহ release আর অনেক version একসাথে চালু। Branch যত দীর্ঘজীবী, conflict-এর ঝুঁকি তত বেশি।

নম্বর কোথায়: অনুমান (১), প্রস্তাবের নিয়ম (৩), ছবি (২), তুলনা (২), পুরোনো version-এর fix পথ (১), উপসংহার (১)। পর্ব ১৭ · পর্ব ১৬ · পর্ব ১৮

যেখানে নম্বর কাটে: scenario না দেখে মুখস্থ Git Flow; পুরোনো version-এর fix কীভাবে যাবে না বলা; “সবাই সরাসরি main-এ push” — review আর CI ছাড়া।

Object: blob = ফাইলের লেখা (নাম ছাড়া); tree = নাম, mode আর hash-এর তালিকা (একটি folder); commit = একটি tree, parent, author, committer, সময় আর বার্তা। Git একটি content-addressed ভাণ্ডার: ID = SHA-1("<type> <size>\0<content>"). যেমন echo hello | git hash-object --stdin যেকোনো কম্পিউটারে দেয় ce01362….

Hash-এর শিকল: এক byte বদলালে blob-এর hash বদলায় → tree-র লেখা বদলায় → tree-র hash → commit-এর লেখা ও hash → পরের সব commit-এর parent-এর লেখা ও hash. তাই ইতিহাস গোপনে বদলানো ধরা পড়ে।

উদ্ধার: git reflog-এ HEAD-এর প্রতিটি চলাচল লেখা থাকে; HEAD@{1} বা hash দেখে git reset --hard HEAD@{1} বা git branch rescue <hash>. কিন্তু কখনো add বা commit না করা লেখা Git জানেই না — সেটি ফেরে না।

নম্বর কোথায়: তিন object (২), hash-এর শিকল (১.৫), reflog আর সীমা (১.৫)। পর্ব ৫২ · পর্ব ৫৩

যেখানে নম্বর কাটে: “Git প্রতিটি commit-এ শুধু diff রাখে” — যুক্তিতে পূর্ণ snapshot, ডিস্কে packfile-এ delta; reflog-কে চিরস্থায়ী ভাবা (মেয়াদ আর gc আছে)।

SemVer: MAJOR.MINOR.PATCH — ভাঙা পরিবর্তনে MAJOR, পুরোনো ব্যবহার না ভাঙা নতুন সুবিধায় MINOR, bug fix-এ PATCH; বড়টি বাড়লে ছোটগুলো শূন্য। Conventional Commits 1.0.0-এ ! বা BREAKING CHANGE: footer মানে ভাঙা পরিবর্তন।

(ক) 1.4.3 · (খ) 1.5.0 · (গ) 2.0.0.

নম্বর কোথায়: প্রতিটি সঠিক version (১ করে)। পর্ব ১৮

যেখানে নম্বর কাটে: (খ)-তে 1.5.2 লেখা — MINOR বাড়লে PATCH শূন্য হয়।

সংজ্ঞা: Requirement engineering হলো “কী বানাতে হবে” খুঁজে বের করা, লেখা, যাচাই করা আর পুরো project জুড়ে সামলানোর নিয়মবদ্ধ কাজ। কারণ: ভুল জিনিস নিখুঁতভাবে বানানোই সবচেয়ে দামি ভুল।

ধাপ (বহুল প্রচলিত সাত ভাগ):

1. Inception: সমস্যা, লক্ষ্য, stakeholder চিহ্নিত — power/interest grid-এ বসানো।
2. Elicitation: চাহিদা সংগ্রহ।
3. Elaboration: model আর বিস্তারিত বিবরণ।
4. Negotiation: পরস্পরবিরোধী চাহিদা আর অগ্রাধিকার মেলানো।
5. Specification: SRS, user story বা use case-এ লেখা।
6. Validation: review, prototype, requirement থেকে test case — “ঠিক জিনিস লিখেছি তো?”
7. Management: baseline, পরিবর্তন নিয়ন্ত্রণ, traceability.

ছবি: সাতটি বাক্স বৃত্তাকারে, ঘড়ির কাঁটার দিকে তীর; validation থেকে elicitation-এ আর management থেকে শুরুতে ফিরতি ড্যাশ তীর — একবার নয়, পুরো project জুড়ে চক্র।

Elicitation-এর কৌশল: interview (গভীর, কিন্তু মানুষ যা করেন সবসময় বলেন না); observation (কাজের জায়গায় দেখা — অলিখিত বা tacit জ্ঞান ধরা পড়ে); prototype (কাগজে বা স্ক্রিনে নকশা দেখিয়ে মত) — এছাড়া workshop, প্রশ্নমালা, পুরোনো নথি পড়া।

Feasibility-র পাঁচ দিক: প্রযুক্তি, অর্থনীতি (payback, NPV), মানুষ ও সংগঠন, সময়সূচি, আইন।

নম্বর কোথায়: সংজ্ঞা (১), ধাপ (৩), ছবি (২), কৌশল (২), feasibility (২)। পর্ব ২০ · পর্ব ২৪

যেখানে নম্বর কাটে: process-কে এক সরল রেখায় আঁকা; শুধু interview লেখা; যিনি টাকা দেন আর যিনি ব্যবহার করেন একই মানুষ ধরে নেওয়া।

Functional = system কী করবে (“ছাত্র roll দিয়ে ফলাফল দেখতে পারবেন”); non-functional = কতটা ভালোভাবে করবে — গতি, নিরাপত্তা, ব্যবহার-সহজতা, availability; constraint = কোন পথে করতেই হবে বা করা যাবে না।

মাপা যায় এমন রূপ: “ফল প্রকাশের দিন সেকেন্ডে ২০০টি অনুরোধে ফলাফল পাতার p95 latency 800 ms-এর কম হবে।” — এটাই fit criterion. EARS-এর ছাঁচে: “When a student submits a roll number, the system shall display the result within 2 seconds.”

ভালো requirement-এর গুণ (ISO/IEC/IEEE 29148): প্রয়োজনীয়, দ্ব্যর্থহীন, সম্পূর্ণ, একক, সম্ভব, যাচাইযোগ্য।

নম্বর কোথায়: দুই সংজ্ঞা ও উদাহরণ (২), মাপা যায় এমন NFR (২), গুণ (১)। পর্ব ২১

যেখানে নম্বর কাটে: সংখ্যা ছাড়া NFR; “user-friendly” বা “secure” লিখে থেমে যাওয়া।

পার্থক্য: use case একটি পূর্ণ গল্প — actor, লক্ষ্য, main success scenario আর extension; user story একটি ছোট প্রতিশ্রুতি — কার্ডে অল্প কথা, বাকিটা আলাপে আর acceptance criteria-তে (Card, Conversation, Confirmation).

INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.

Story: “As a librarian, I want the fine calculated automatically, so that members are charged consistently.”

Criterion: Given প্রতিদিনের জরিমানা ৫ টাকা আর ফেরতের শেষ দিন ১০ তারিখ, When সদস্য ১৩ তারিখে বই ফেরত দেন, Then জরিমানা হয় ১৫ টাকা।

নম্বর কোথায়: পার্থক্য (১.৫), INVEST (১), story-র তিন অংশ (১), সংখ্যাসহ Given-When-Then (১.৫)। পর্ব ২২

যেখানে নম্বর কাটে: story-তে “so that” বাদ; criterion-এ সংখ্যা ছাড়া “সঠিক জরিমানা হবে”।

«include»: base use case প্রতিবার included অংশটি চালায় — ড্যাশ রেখা, খোলা তীর base থেকে included-এর দিকে। যেমন “বই ধার” → «include» → “সদস্য যাচাই”। «extend»: শর্ত পূরণ হলে তবেই — তীর extending থেকে base-এর দিকে, extension point-সহ; যেমন “জরিমানা আদায়” → «extend» → “বই ফেরত” [দেরি হলে]।

Domain model: সমস্যার জগতের ধারণা (class), attribute আর association-এর multiplicity; এই স্তরে method, database table বা UI নেই।

নম্বর কোথায়: দুই সম্পর্ক ও তীরের দিক (২.৫), domain model (১.৫)। পর্ব ২৩

যেখানে নম্বর কাটে: «extend»-এর তীর উল্টো আঁকা; use case diagram-কে flowchart বানিয়ে ধাপের ক্রম দেখানো।

MoSCoW: Must, Should, Could, Won’t (এবার নয়)। RICE = Reach × Impact × Confidence ÷ Effort = ২,০০০ × ২ × ০.৮ ÷ ৪ = ৮০০. (Kano, WSJF-ও চলে।)

Traceability matrix: requirement → design → code → test-এর সুতো, দুই দিকেই; test-হীন requirement, অনাথ test আর পরিবর্তনের প্রভাব (impact analysis) দেখায়। Scope creep: নিয়ন্ত্রণ ছাড়া ধীরে ধীরে requirement যোগ হওয়া; প্রতিকার baseline, change request আর change control board.

নম্বর কোথায়: দুই কৌশল (১.৫), RICE (১.৫), traceability (১), scope creep (১)। পর্ব ২৪

যেখানে নম্বর কাটে: confidence-কে ৮০ ধরে গুণ (ফল ৮০,০০০); scope creep আর gold-plating গুলিয়ে ফেলা (দ্বিতীয়টি developer-এর নিজের যোগ করা, কেউ চায়নি)।

Coupling = module-দের পারস্পরিক নির্ভরতা (কম ভালো); cohesion = একটি module-এর ভেতরের মিল (বেশি ভালো)।

1. Content — অন্যের ভেতরের data বা কোড সরাসরি ছোঁয়া।
2. Common — একই global data অনেকে পড়ে-লেখে।
3. External — বাইরে থেকে চাপানো format বা protocol ভাগ করা (যেমন ব্যাংকের CSV).
4. Control — flag পাঠিয়ে অন্যের ভেতরের পথ বাছাই।
5. Stamp — পুরো record পাঠানো, যদিও লাগে একটু।
6. Data — শুধু দরকারি সরল মান parameter-এ।

Cohesion: coincidental (সম্পর্কহীন, “Utils”) → logical (একই ধরনের, flag দিয়ে বাছাই) → temporal (একই সময়ে চলে) → procedural (নির্দিষ্ট ক্রমে) → communicational (একই data নিয়ে) → sequential (একটির output পরেরটির input) → functional (এক module, এক কাজ)।

নম্বর কোথায়: দুই সংজ্ঞা (১), coupling-এর ক্রম ও ব্যাখ্যা (২), cohesion-এর ক্রম ও ব্যাখ্যা (২)। পর্ব ২৫

যেখানে নম্বর কাটে: ক্রম উল্টে ফেলা। বইভেদে নাম আর external-এর জায়গা একটু আলাদা — যে তালিকা লিখছেন তার উৎস (Myers বা Yourdon–Constantine) উল্লেখ করলে নিরাপদ।

1. I = Ce ÷ (Ca + Ce) = ৬ ÷ ৮ = ০.৭৫ — বেশ অস্থির, বদলের চাপ বাইরে থেকে আসে।
2. A = Na ÷ Nc = ১ ÷ ১০ = ০.১.
3. D = |A + I − 1| = |০.১ + ০.৭৫ − ১| = ০.১৫ — main sequence-এর কাছে, ভালো ভারসাম্য।

নম্বর কোথায়: প্রতিটি সূত্র ও মান (১ করে)। পর্ব ২৫

যেখানে নম্বর কাটে: Ca আর Ce উল্টে I = ০.২৫ লেখা; D-তে পরম মান না নেওয়া (−০.১৫)।

• DRY: প্রতিটি জ্ঞানের একটি উৎস — জরিমানার হার তিন file-এ নয়, একটি constant-এ। দেখতে এক কিন্তু আলাদা কারণে বদলায় এমন কোড জোড়া লাগানো DRY নয়।
• KISS: যতটা সম্ভব সরল — তিন লাইনের if-এর জায়গায় plugin কাঠামো নয়।
• YAGNI: এখন যা লাগে না, তা বানাবেন না — “পরে হয়তো দশ ভাষা লাগবে” বলে আজ translation engine নয়।
• Law of Demeter: শুধু কাছের বন্ধুর সাথে কথা — order.customer.pay(x), order.customer.wallet.balance -= x নয়।

নম্বর কোথায়: প্রতিটি নীতি ও উদাহরণ (১ করে)। পর্ব ২৬

যেখানে নম্বর কাটে: DRY-কে “কোনো দুই লাইন যেন এক না হয়” বলা; উদাহরণ ছাড়া শুধু পূর্ণ রূপ লেখা।

ভূমিকা: Robert C. Martin প্রায় ২০০০ সালের দিকে নীতিগুলো একসাথে লেখেন; “SOLID” নামটি পরে প্রচলিত হয়। লক্ষ্য: কম coupling, বেশি cohesion, যাতে বদল সস্তা হয়। উদাহরণ একটি কাল্পনিক ফলাফল পোর্টালের।

ছবি (DIP): আগে ResultService → MySqlResults (নিচের দিকে তীর); পরে ResultService → «interface» ResultRepository ◁┄ MySqlResults — detail থেকে তীর এখন ওপরের দিকে, তাই “inversion”.

সতর্কতা: নীতিগুলো আইন নয়। প্রথম বদল আসার আগেই সব জায়গায় interface বানানো YAGNI-র লঙ্ঘন; এক method-এর অগণিত class SRP নয়, ছড়িয়ে পড়া কোড।

নম্বর কোথায়: পাঁচ নীতি, প্রতিটির সংজ্ঞা ও উদাহরণ (৮), একটি ছবি (১), সীমা (১)। পর্ব ২৭ · পর্ব ২৮

যেখানে নম্বর কাটে: SRP-কে “একটি class একটি কাজ” বলে থামা; DIP আর dependency injection এক বলে লেখা; LSP-র উদাহরণে কোন প্রতিশ্রুতি ভাঙল তা না বলা।

অনুমান: সদস্য হিসেবে কেউ সরাসরি থাকেন না — ছাত্র বা শিক্ষক (তাই Member abstract); Loan মানে চলমান ধার — একটি ধারে ঠিক একটি কপি, আর একটি কপি একসাথে সর্বোচ্চ একটি চলমান ধারে (ফেরত হওয়া ধারের ইতিহাস আলাদা record-এ); কপি তার বইয়ের অংশ।

ছবির নিচে: checkLimit() দেখে চলমান ধার ৫-এর কম কি না। Composition-এর বদলে aggregation-ও যুক্তিসহ গ্রহণযোগ্য।

নম্বর কোথায়: (ক) class ও attribute (১.৫), সঠিক সম্পর্কের চিহ্ন (১.৫), multiplicity (১.৫), abstract ও অনুমান (০.৫); (খ) lifeline ও ক্রম (১.৫), call বনাম reply-এর তীর (১), alt ও create (১.৫), ব্যাখ্যা (১)। পর্ব ২৯ · পর্ব ৩০ · পর্ব ২৩

যেখানে নম্বর কাটে: হীরা ভুল প্রান্তে (অংশের দিকে) আঁকা; generalization-এ খোলা তীর আঁকা; “০..৫” না লিখে শুধু “*”; sequence-এ reply-কে কঠিন রেখায় আঁকা; শর্ত if-else-এর জন্য দুটি আলাদা diagram.

নম্বর কোথায়: তিন সংজ্ঞা ও notation (৩), উদাহরণ (১)। পর্ব ২৯

যেখানে নম্বর কাটে: হীরা অংশের প্রান্তে আঁকা; aggregation আর composition-কে কোড দেখে নিশ্চিতভাবে আলাদা করা যায় বলে দাবি — list[Seat] থেকে বোঝা যায় শুধু “অনেক”, মালিকানা নকশার সিদ্ধান্ত।

সংজ্ঞা: Design pattern হলো একটি নির্দিষ্ট প্রেক্ষাপটে বারবার ফিরে আসা নকশার সমস্যার নাম দেওয়া, পরীক্ষিত সমাধানের ছাঁচ — কপি করার কোড নয়। ধারণা Christopher Alexander-এর স্থাপত্য (১৯৭৭) থেকে; Gamma, Helm, Johnson আর Vlissides-এর ১৯৯৪ সালের বই ২৩টি pattern-কে বিখ্যাত করে।

তিন পরিবার: creational ৫টি (object তৈরি — singleton, factory method, abstract factory, builder, prototype), structural ৭টি (জোড়া দেওয়া — adapter, decorator, facade, proxy, composite, bridge, flyweight), behavioral ১১টি (আচরণ আর দায় ভাগ — strategy, observer, command, state ইত্যাদি)।

• Strategy: একই কাজের বদলযোগ্য পদ্ধতি। কাঠামো: Context-এর ভেতরে একটি «interface» Strategy-এর reference (association); DiscountEid, DiscountStudent ফাঁপা ত্রিভুজের ড্যাশ রেখায় (realization) Strategy implement করে। Context শুধু apply(price) ডাকে।
• Observer: একটি object বদলালে অনেক শ্রোতাকে খবর। কাঠামো: Subject (attach, detach, notify) 1 — 0..* «interface» Observer (update()); SmsAlert, EmailAlert Observer implement করে। ফল প্রকাশ হলে notify সবার update ডাকে।
• Decorator: interface না বদলে আচরণ যোগ (log, retry, cache). কাঠামো: «interface» Notifier; BasicNotifier আর LoggingDecorator দুটিই implement করে, আর decorator-এর ভেতরে একটি Notifier থাকে (is-a আর has-a একসাথে)। মোড়কের ক্রম বদলালে ফল বদলায়।

কখন নয়: প্রমাণিত সমস্যা ছাড়া pattern বসানো নিজেই anti-pattern; Python বা JavaScript-এ strategy প্রায়ই একটি function মাত্র।

নম্বর কোথায়: সংজ্ঞা ও ইতিহাস (১.৫), তিন পরিবার ও সংখ্যা (১.৫), তিন pattern-এর উদ্দেশ্য ও কাঠামো (২ করে, ৬), কখন নয় (১)। পর্ব ৩২ · পর্ব ৩৫ · পর্ব ৩৪

যেখানে নম্বর কাটে: pattern-এর নাম আর কোড দিয়ে উত্তর, কোন সমস্যা মেটায় তা নয়; Strategy আর State গুলিয়ে ফেলা (গঠন এক, কিন্তু Strategy বাছেন client, State বদলায় নিজে); Decorator আর Adapter এক বলা (Adapter interface বদলায়)।

Design by contract (Bertrand Meyer, Eiffel ভাষা): প্রতিটি operation একটি চুক্তি। precondition মানা ডাকার পক্ষের (caller) দায় — যেমন withdraw(amount)-এ amount > 0; postcondition কাজ-করা পক্ষের (supplier) দায় — balance ঠিক amount কমেছে; invariant সবসময় সত্য — balance ≥ 0. কোনটি ভাঙল দেখেই বোঝা যায় bug কার।

LSP: subtype precondition কড়া করতে পারে না, postcondition দুর্বল করতে পারে না, invariant রক্ষা করবে — নইলে base type-এর জন্য লেখা কোড ভাঙে।

নম্বর কোথায়: সংজ্ঞা (১), তিনটির দায় ও উদাহরণ (২), LSP-র নিয়ম (১)। পর্ব ৩১ · পর্ব ২৮

যেখানে নম্বর কাটে: বাইরের input যাচাইয়ে assert প্রস্তাব — python -O সব assert মুছে দেয়; trust boundary-তে সবসময়-চলা check লাগে।

DIP একটি নীতি (কে কার ওপর নির্ভর করবে — abstraction-এর ওপর); dependency injection একটি কৌশল (নির্ভরতা বাইরে থেকে দেওয়া — সাধারণত constructor-এ, সব জোড়া এক জায়গায়, composition root-এ); inversion of control একটি বড় ধারণা (কে কাকে ডাকবে তার নিয়ন্ত্রণ framework-এর হাতে — “আমাদের ডাকবেন না, আমরাই ডাকব”)।

Composition: base class-এর একটি “নিরীহ” বদল subclass ভেঙে দিতে পারে (fragile base class); object রেখে কাজ delegate করলে আচরণ চলার সময়েই বদলানো যায়। Inheritance রাখুন খাঁটি “is-a” আর LSP-মানা সম্পর্কে।

নম্বর কোথায়: তিন সংজ্ঞা (৩), composition-এর যুক্তি (১)। পর্ব ৩৭

যেখানে নম্বর কাটে: তিনটিকে সমার্থক লেখা; service locator-কে DI বলা — locator নির্ভরতা আবার লুকিয়ে ফেলে।

ADR (architecture decision record): একটি কঠিন-বদল সিদ্ধান্তের ছোট নথি — title, status, context, decision, consequences; কোডের পাশে docs/adr/-এ Git-এ।

নম্বর কোথায়: টেবিল (৩), ADR ও তার অংশ (২)। পর্ব ৩৮

যেখানে নম্বর কাটে: প্রতিটি style-এর শুধু সুবিধা লেখা; ADR-এ consequences বাদ।

MVC: model নিজের বদলের খবর view-কে দেয় (observer); controller ব্যবহারকারীর input নিয়ে model-কে ডাকে। Web framework-এর “MVC”-তে controller HTTP request সামলায় — একটু আলাদা রূপ। MVVM: view model state আর command প্রকাশ করে; data binding নিজে থেকে screen মেলায়, তাই view model UI ছাড়াই test হয়।

Business logic: model বা service layer-এ — view বা controller-এ নয় (massive view controller একটি পরিচিত anti-pattern).

নম্বর কোথায়: দুটি গঠন (৩), logic-এর জায়গা (১)। পর্ব ৩৯

যেখানে নম্বর কাটে: controller-এ হিসাব রাখার পরামর্শ; two-way binding-এর অসীম চক্রের ঝুঁকি না জানা।

Refactoring (Fowler, ১৯৯৯; ২য় সংস্করণ ২০১৮): বাইরে থেকে দেখা আচরণ একই রেখে ভেতরের কাঠামো উন্নত করা — আগে test, তারপর ছোট ধাপ, প্রতিটির পরে commit. Bug ঠিক করা বা feature যোগ refactoring নয়।

• Long function → Extract Function.
• একই switch বারবার → Replace Conditional with Polymorphism.
• লম্বা parameter-এর তালিকা → Introduce Parameter Object.

Technical debt (Cunningham, ১৯৯২): শর্টকাট হলো principal, প্রতিটি পরের বদলে বাড়তি সময় interest. Fowler-এর quadrant: জেনেশুনে বা অজান্তে × বিবেচনা করে বা বেপরোয়াভাবে। Lehman: (১) ব্যবহৃত software-কে ক্রমাগত বদলাতে হয়, নইলে কম কাজের হয়ে যায়; (২) যত্ন না নিলে বদলের সাথে জটিলতা বাড়ে।

নম্বর কোথায়: সংজ্ঞা (১), তিন smell ও প্রতিকার (১.৫), debt ও quadrant (১.৫), Lehman (১)। পর্ব ৪২ · পর্ব ৪৩

যেখানে নম্বর কাটে: refactoring-এর সাথে আচরণ বদল মেশানো; সব debt-কে খারাপ বলা — বিবেচনা করে নেওয়া ধার কখনো ঠিক সিদ্ধান্ত।

যন্ত্র আগে: formatting, অব্যবহৃত variable, type-এর ভুল ধরবে formatter, linter, type checker আর static analysis. মানুষ যা দেখেন, বড় থেকে ছোট: সঠিকতা আর test → নকশায় মানানসই কি না → পড়ার সুবিধা ও নাম → নিরাপত্তা → দরকারে performance → error handling → নথি।

মন্তব্য: নির্দিষ্ট আর কারণসহ; অবস্থা স্পষ্ট (blocking, nit, প্রশ্ন — লেবেল দিয়ে); আদেশের বদলে প্রশ্ন, আর ভালো কাজের প্রশংসা।

নম্বর কোথায়: ক্রম (২), মন্তব্যের তিন গুণ (২)। পর্ব ৪৪ · পর্ব ৪১

যেখানে নম্বর কাটে: review-কে শুধু bug ধরা বলা — জ্ঞান ভাগাভাগি আর সামঞ্জস্যও বড় ফল; মানুষের সময় formatting-এ খরচ।

Hexagonal: কেন্দ্রে application core; বাইরের জগতের সাথে কথা core-এর নিজের সংজ্ঞা দেওয়া port দিয়ে। Driving adapter (web, CLI, test) core-কে চালায়; driven adapter-কে (database, payment, SMS) চালায় core নিজে। Clean Architecture: entities, use cases, interface adapters, frameworks & drivers — চার বৃত্ত, আর source code-এর নির্ভরতা শুধু ভেতরের দিকে (dependency rule).

দাম: বেশি file, indirection আর data-র রূপান্তর; চার field-এর CRUD app-এ প্রায়ই over-engineering.

নম্বর কোথায়: port ও adapter-এর দুই ধরন (১.৫), dependency rule (১.৫), দাম (১)। পর্ব ৪০

যেখানে নম্বর কাটে: port-কে network port ভাবা; বৃত্তে তীর বাইরের দিকে আঁকা।

Verification: “জিনিসটি ঠিকভাবে বানাচ্ছি তো?” (Boehm: are we building the product right?) — spec মানা হয়েছে কি না; কৌশল: review ও inspection, static analysis, unit test. Validation: “ঠিক জিনিসটি বানাচ্ছি তো?” (are we building the right product?) — আসল প্রয়োজন মেটে কি না; কৌশল: acceptance test, prototype দেখানো, beta বা ব্যবহারকারীর সাথে পরীক্ষা।

নম্বর কোথায়: দুই সংজ্ঞা (১.৫), কৌশল (১.৫)। পর্ব ৪৫

যেখানে নম্বর কাটে: দুটির সংজ্ঞা উল্টে লেখা; verification-কে শুধু “কোড না চালিয়ে” বলা — unit test-ও spec-এর বিরুদ্ধে verification.

ভূমিকা: Dijkstra-র কথায়, test ভুলের উপস্থিতি দেখাতে পারে, অনুপস্থিতি নয়।

স্তর (কতটুকু জোড়া লাগিয়ে দেখছেন):

1. Unit — একটি function বা class; দ্রুত, অনেক।
2. Integration — কয়েকটি অংশ বা database-এর সাথে জোড়া; interface-এর ভুল।
3. System — পুরো system, functional আর non-functional দুই দিক।
4. Acceptance — গ্রাহক বা ব্যবহারকারীর দৃষ্টিতে, requirement-এর বিরুদ্ধে।

ছবি: একটি V — বাঁ বাহুতে ওপর থেকে requirement → system design → architecture → module design, তলায় coding, ডান বাহুতে নিচ থেকে unit → integration → system → acceptance; প্রতিটি জোড়ার মাঝে আড়াআড়ি ড্যাশ রেখা, লেবেল “test পরিকল্পনা এখানেই”।

ধরন বনাম স্তর: regression, performance, security, smoke — এগুলো test-এর ধরন, যেকোনো স্তরে হতে পারে। উপসংহার: test pyramid — নিচে অনেক unit, ওপরে অল্প end-to-end.

নম্বর কোথায়: ভূমিকা (১), চার স্তর (২), V-ছবি (২), black-box ও white-box কৌশল ও উদাহরণ (৪), উপসংহার (১)। পর্ব ৪৫ · পর্ব ৪৭ · পর্ব ৫১

যেখানে নম্বর কাটে: স্তর আর ধরন মিশিয়ে ফেলা (“regression একটি স্তর”); V-এর জোড়া ভুল (unit ↔ requirement); কৌশলের নাম দিয়ে উদাহরণ না দেওয়া।

1. Partition: অবৈধ < ১৮ (প্রতিনিধি ১০), বৈধ ১৮–৬০ (৩৫), অবৈধ > ৬০ (৭০); সাথে অবৈধ ধরন — ফাঁকা, দশমিক (২৫.৫), অক্ষর।
2. ২-মান BVA: প্রতিটি সীমা আর তার বাইরের প্রতিবেশী — ১৭, ১৮, ৬০, ৬১.
3. ৩-মান BVA: সীমার দুই পাশের প্রতিবেশীসহ — ১৭, ১৮, ১৯, ৫৯, ৬০, ৬১.

নম্বর কোথায়: তিনটি partition ও প্রতিনিধি (২), অবৈধ ধরন (০.৫), ২-মান (১), ৩-মান (১.৫)। পর্ব ৪৭

যেখানে নম্বর কাটে: শুধু বৈধ partition; সীমা ১৮ আর ৬০ নিজেই বাদ দেওয়া; প্রতিটি সংখ্যার জন্য আলাদা partition.

def fine(days, teacher):
    amount = 0                    # node 1
    if days > 7:                  # node 2
        amount = (days - 7) * 5   # node 3
    else:
        log("on time")            # node 4
    if teacher:                   # node 5
        amount = amount // 2      # node 6
    return amount                 # node 7

Graph: ৭টি node; edge ১→২, ২→৩, ২→৪, ৩→৫, ৪→৫, ৫→৬, ৫→৭, ৬→৭ — মোট ৮টি।

1. V(G) = E − N + 2P = ৮ − ৭ + ২ = ৩.
2. V(G) = decision + ১ = ২ + ১ = ৩ (node ২ আর ৫).
3. Region: দুটি ভেতরের (২-৩-৫-৪ আর ৫-৬-৭) + বাইরের একটি = ৩.

Basis path ও input: ১-২-৪-৫-৭ → (৩, False) → ০; ১-২-৩-৫-৭ → (১০, False) → ১৫; ১-২-৩-৫-৬-৭ → (১০, True) → ৭.

নম্বর কোথায়: সঠিক graph (১.৫), তিন হিসাব (২), basis path ও প্রত্যাশিত ফল (১.৫)। পর্ব ৫০

যেখানে নম্বর কাটে: সূত্রে P বাদ বা ভুল (এক function-এ P = ১); else-কে আলাদা decision গোনা; region গুনতে বাইরের region ভুলে যাওয়া।

Test double (Meszaros, ২০০৭): dummy — শুধু জায়গা ভরে; stub — ঠিক করা উত্তর দেয়; spy — ডাকগুলো লিখে রাখে; mock — আগে থেকে প্রত্যাশা জানে আর নিজে যাচাই করে; fake — সত্যি কাজ করে কিন্তু সরলভাবে (in-memory database). নামের ব্যবহার framework আর লেখকভেদে আলাদা — Python-এর Mock object দিয়ে stub-ও বানানো যায়।

Mutation testing: কোডে ছোট ভুল (যেমন >= → >) ঢুকিয়ে দেখা test fail করে কি না — test-এর test. Score = killed ÷ (মোট − equivalent) = ৪০ ÷ ৪৫ ≈ ০.৮৮৯, অর্থাৎ ৮৮.৯%.

নম্বর কোথায়: পাঁচ ধরন (২.৫), mutation-এর সংজ্ঞা (১), হিসাব (১.৫)। পর্ব ৪৯ · পর্ব ৫০

যেখানে নম্বর কাটে: ৪০ ÷ ৫০ = ৮০% লেখা (equivalent বাদ না দেওয়া); mock আর stub এক বলা।

TDD (Kent Beck, ২০০২): red — একটি ব্যর্থ test লিখুন; green — পাস করানোর সবচেয়ে সরল কোড; refactor — test সবুজ রেখে কোড পরিষ্কার। প্রতিটি চক্র কয়েক মিনিটের, একবারে একটিই নতুন আচরণ। লাভ: ছোট interface, কম coupling — test উপজাত ফল।

Test pyramid: নিচে অনেক দ্রুত unit test, মাঝে কম integration, ওপরে অল্প ধীর end-to-end. Ice-cream cone (অনেক হাতে করা আর UI test, অল্প unit) ধীর, দামি আর flaky — feedback দেরিতে আসে। আকার নিয়ে বিতর্ক আছে (testing trophy, honeycomb), তবে cone এড়ানোয় সবাই একমত।

নম্বর কোথায়: তিন ধাপ (২), TDD-র লাভ (১), pyramid ও cone (২)। পর্ব ৪৮ · পর্ব ৫১

যেখানে নম্বর কাটে: red ধাপ বাদ (test আগে fail করতে দেখা জরুরি — নইলে test হয়তো কিছুই যাচাই করে না); refactor-এ নতুন আচরণ যোগ।

সংজ্ঞা: continuous integration একটি অনুশীলন, tool নয় — সবাই ছোট পরিবর্তন অন্তত দিনে একবার mainline-এ মেলান, আর প্রতিটিতে স্বয়ংক্রিয় build ও test চলে। Continuous delivery — প্রতিটি সবুজ পরিবর্তন release-যোগ্য, production-এ পাঠানো একটি বোতামের সিদ্ধান্ত; continuous deployment সেই বোতামও তুলে দেয়।

ছবি (বাঁ থেকে ডানে): push বা PR (trigger) → checkout → dependency (cache থেকে) → lint ও build → unit test → integration test ও security scan → artifact (একবার build, একটি digest) → staging-এ deploy ও acceptance test → [বোতাম] → production. প্রতিটি বাক্সের নিচ থেকে developer-এর দিকে লাল ফিরতি তীর “ব্যর্থ হলে থামা, খবর দেওয়া”।

1. Fail fast: সস্তা আর দ্রুত ধাপ আগে; একটি ধাপ ব্যর্থ হলে নির্ভরশীল ধাপগুলো বাদ।
2. Build একবার, deploy বহুবার: একই artifact dev থেকে prod; বদলায় শুধু config.
3. Main সবুজ রাখা: required check; লাল হলে আগে revert.
4. নিরাপত্তা: secret masked, ন্যূনতম অনুমতি, fork-এর PR-এ secret নয়।

DORA-র চার metric (Accelerate, ২০১৮): deployment frequency, lead time for changes (commit থেকে production), change failure rate, time to restore service — প্রথম দুটি গতি, শেষ দুটি স্থিতি; জোড়ায় দেখুন, লক্ষ্য বানালে নষ্ট হয় (Goodhart).

নম্বর কোথায়: তিন সংজ্ঞা (৩), ছবি (৩), নীতি (২), DORA (২)। পর্ব ৫৮ · পর্ব ৫৯ · System Design · Deployment

যেখানে নম্বর কাটে: “Jenkins থাকলেই CI” লেখা; delivery আর deployment এক বলা; প্রতিটি environment-এ আবার build-এর পরামর্শ।

1. E = a × KLOC^b = 2.4 × 20^1.05 ≈ 2.4 × 23.23 ≈ ৫৫.৮ person-month.
2. D = c × E^d = 2.5 × 55.8^0.38 ≈ ১১.৫ মাস.
3. দল = E ÷ D ≈ ৫৫.৮ ÷ ১১.৫ ≈ ৪.৮ জন, অর্থাৎ প্রায় ৫ জন।

মন্তব্য: effort আর সময় অদলবদলযোগ্য নয় — COCOMO-র সময়ের সূত্র effort-এর দুর্বল ঘাত (০.৩৮), আর Brooks’s law অনুযায়ী বেশি লোকে যোগাযোগের পথ বাড়ে (৫ জনে ১০টি, ১০ জনে ৪৫টি)। Basic মডেল শুধু আকার দেখে; পরীক্ষায় দেওয়া ধ্রুবকই ব্যবহার করুন।

নম্বর কোথায়: E (২), D (১.৫), দল (০.৫), মন্তব্য (১)। পর্ব ৬০ · পর্ব ৬৬

যেখানে নম্বর কাটে: COCOMO 81-এর a আর COCOMO II-এর exponent মেশানো; D-র সূত্রে KLOC বসানো; একক (PM, মাস) বাদ।

Network (activity-on-node): Start → A; A থেকে দুই শাখা B → D আর C → E; D আর E মিলে F → End. প্রতিটি node-এ চার ঘর: ES, EF ওপরে; LS, LF নিচে।

(ক) Forward pass: ES = পূর্বসূরিদের EF-এর সর্বোচ্চ (F-এর ES = max(১২, ৮) = ১২); backward pass: LF = উত্তরসূরিদের LS-এর সর্বনিম্ন। Critical path A → B → D → F = ১৪ দিন; C আর E-র total float ৪ দিন.

(খ) PERT: t_e = (a + 4m + b) ÷ 6, σ² = ((b − a) ÷ 6)².

1. t_e: A = ৩, B = ৪, D = (৩ + ২০ + ১৩) ÷ ৬ = ৬, F = ২ → μ = ১৫ দিন (D-র অনুমান ডানে হেলানো, তাই ১৪ নয়)।
2. σ²: ০.১১ + ০.৪৪ + ২.৭৮ + ০.১১ = ৩.৪৪ → σ ≈ ১.৮৬.
3. Z = (১৬ − ১৫) ÷ ১.৮৬ ≈ ০.৫৪ → normal টেবিল থেকে P ≈ ০.৭০৫, অর্থাৎ প্রায় ৭০%.

অনুমান ও সীমা: C আর E-র অনিশ্চয়তা দেওয়া নেই; ধরা হলো ৪ দিনের float-এ সেই পথ critical হয় না। PERT শুধু একটি পথ দেখে, তাই হিসাবটি আশাবাদী।

নিচের block-টি একই হিসাব চালিয়ে মিলিয়ে দেয়:

// CPM forward/backward pass + PERT for the critical path + Basic COCOMO
const acts = { A: [3, []], B: [4, ["A"]], C: [2, ["A"]],
               D: [5, ["B"]], E: [3, ["C"]], F: [2, ["D", "E"]] };
const ES = {}, EF = {}, LS = {}, LF = {}, ids = Object.keys(acts);
for (const x of ids) {                       // forward pass
  ES[x] = Math.max(0, ...acts[x][1].map(p => EF[p]));
  EF[x] = ES[x] + acts[x][0];
}
const T = Math.max(...ids.map(x => EF[x]));
for (const x of [...ids].reverse()) {        // backward pass
  const succ = ids.filter(y => acts[y][1].includes(x));
  LF[x] = Math.min(T, ...succ.map(y => LS[y]));
  LS[x] = LF[x] - acts[x][0];
}
for (const x of ids)
  console.log(x, "ES", ES[x], "EF", EF[x], "LS", LS[x], "LF", LF[x], "float", LS[x] - ES[x]);
console.log("project length =", T, "days");
const pert = { A: [2, 3, 4], B: [2, 4, 6], D: [3, 5, 13], F: [1, 2, 3] };
let mu = 0, v = 0;
for (const [a, m, b] of Object.values(pert)) { mu += (a + 4 * m + b) / 6; v += ((b - a) / 6) ** 2; }
const sd = Math.sqrt(v);
console.log("PERT mean", mu.toFixed(2), "variance", v.toFixed(2), "sd", sd.toFixed(2),
            "Z(16) =", ((16 - mu) / sd).toFixed(2));
const E = 2.4 * 20 ** 1.05, D = 2.5 * E ** 0.38;  // organic, 20 KLOC
console.log("COCOMO organic 20 KLOC:", E.toFixed(1), "PM,", D.toFixed(1), "months,",
            (E / D).toFixed(1), "people");

A ES 0 EF 3 LS 0 LF 3 float 0
B ES 3 EF 7 LS 3 LF 7 float 0
C ES 3 EF 5 LS 7 LF 9 float 4
D ES 7 EF 12 LS 7 LF 12 float 0
E ES 5 EF 8 LS 9 LF 12 float 4
F ES 12 EF 14 LS 12 LF 14 float 0
project length = 14 days
PERT mean 15.00 variance 3.44 sd 1.86 Z(16) = 0.54
COCOMO organic 20 KLOC: 55.8 PM, 11.5 months, 4.8 people

নম্বর কোথায়: network (২), forward ও backward pass (২), critical path ও float (২), t_e ও μ (১.৫), σ ও Z (১.৫), সম্ভাবনা ও সীমা (১)। পর্ব ৬১ · পর্ব ৬৬

যেখানে নম্বর কাটে: σ যোগ করা (variance যোগ হয়, তারপর বর্গমূল); F-এর ES-এ ছোট মানটি (৮) নেওয়া; float শুধু critical কাজের জন্য গোনা।

প্রক্রিয়া (চার ধাপের চক্র): চিহ্নিত করা (checklist, আগের project, brainstorming) → বিশ্লেষণ (সম্ভাবনা × ক্ষতি) → জবাবের পরিকল্পনা (এড়ানো, কমানো, হস্তান্তর, মেনে নেওয়া) → নজরদারি (প্রতি sprint-এ register হালনাগাদ, trigger). ছবি: চারটি বাক্স বৃত্তাকারে, শেষ থেকে প্রথমে ফিরতি তীর।

ফল: মোট RE = ৪ + ৬ + ৩ = ৳১৩ লাখ. RE-তে ক্রম R2 > R1 > R3, কিন্তু RRL-এ R1 (৩.২) > R2 (২.০) > R3 (০.৫)। তাই আগে R1 আর R2 — RRL ১-এর বেশি, ৳৩ লাখে ৳৭.২ লাখ প্রত্যাশিত ক্ষতি কমে। R3-এর প্রতিকার পোষায় না (RRL < ১); contingency রেখে নজরদারি।

Register-এর কলাম: id, “যদি… তাহলে…” বর্ণনা, P, L, RE, মালিক, প্রতিকার, trigger, অবস্থা।

নম্বর কোথায়: প্রক্রিয়া ও ছবি (২), তিন RE ও মোট (২), RRL (২), অগ্রাধিকারের যুক্তি (২), register-এর কাঠামো ও মালিক (২)। পর্ব ৬২ · পর্ব ৪

যেখানে নম্বর কাটে: শুধু RE দেখে ক্রম; RRL-এ খরচ দিয়ে ভাগ না করা; প্রতিটি risk-এর মালিক না রাখা। মানুষের ক্ষতি বা গোপনীয়তার মতো ঝুঁকি শুধু টাকায় মাপা যায় না — সেটিও এক লাইনে বলুন।

SV = EV − PV = −৳১০ লাখ; CV = EV − AC = −৳৫ লাখ; SPI = EV ÷ PV = ০.৮০; CPI = EV ÷ AC ≈ ০.৮৯. দুটিই ১-এর কম: project সময়ে পিছিয়ে আর বাজেট ছাড়িয়েছে — প্রতি ৳১ খরচে ৳০.৮৯-এর কাজ হচ্ছে।

নম্বর কোথায়: চার মান (২), ব্যাখ্যা (১)। পর্ব ৬১

যেখানে নম্বর কাটে: PV − EV লিখে চিহ্ন উল্টানো; CPI-তে AC ÷ EV.

QA প্রক্রিয়া ঠিক রাখে — প্রতিরোধ (review-এর নিয়ম, checklist, প্রশিক্ষণ); QC পণ্যে defect খোঁজে — ধরা (test, inspection).

CMMI: (১) Initial — কাজ হয় কয়েকজনের দক্ষতায়; (২) Managed — project-স্তরে পরিকল্পনা ও নজর; (৩) Defined — প্রতিষ্ঠান জুড়ে মানক প্রক্রিয়া; (৪) Quantitatively Managed — সংখ্যা ও control limit দিয়ে নিয়ন্ত্রণ; (৫) Optimizing — কারণ বিশ্লেষণ করে ক্রমাগত উন্নতি।

নম্বর কোথায়: QA বনাম QC (১.৫), পাঁচ level ক্রমসহ (২.৫)। পর্ব ৬২

যেখানে নম্বর কাটে: QA-কে শুধু “testing দল” বলা; level-এর ক্রম ভুল।

নৈতিকতা: ACM/IEEE-CS Code (১৯৯৯)-এর আট নীতির প্রথমটি Public — স্বার্থে সংঘাত হলে জনস্বার্থ আগে। করণীয়: bug-এর প্রভাব (কতজন, কত টাকা) লিখিতভাবে জানানো, fix বা প্রকাশ্য সতর্কতার বিকল্প প্রস্তাব, সিদ্ধান্ত লিখে রাখা; ক্ষতি গুরুতর হলে উচ্চতর কর্তৃপক্ষকে জানানো।

License: GPL copyleft — বিতরণ করলে সাধারণত পুরো combined work-এর source একই শর্তে দিতে হয়; বন্ধ-উৎসের app-এ এটি প্রায়ই অসম্ভব। MIT বা Apache-2.0-এর মতো permissive license-এ মূলত notice রাখলেই চলে। সন্দেহে আইনি পরামর্শ।

Four-fifths: ৩০ ÷ ৫০ = ০.৬০, যা ০.৮০-এর কম — বিরূপ প্রভাবের একটি মোটা দাগের সতর্কসংকেত; কারণ খুঁজতে আরও বিশ্লেষণ লাগে, এটি একা প্রমাণ নয়।

নম্বর কোথায়: নীতির নাম ও করণীয় (২), license (১.৫), four-fifths (১.৫)। পর্ব ৬৪ · পর্ব ৬৩

যেখানে নম্বর কাটে: “ব্যবস্থাপকের কথাই শেষ কথা” লেখা; GPL আর LGPL এক বলা; ০.৬-কে “বৈষম্যের প্রমাণ” বলা।

Software ক্ষয় হয় না কিন্তু বদলের চাপে খারাপ হয়; তৈরির খরচ মূলত নকশা আর মানুষের, কপির খরচ প্রায় শূন্য; আর গঠন চোখে দেখা যায় না।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… তাহলে খরচের বড় অংশ কোথায়? — জীবনকালের maintenance-এ, এমনটিই বহুল উদ্ধৃত; সংখ্যা নিয়ে বিতর্ক আছে। পর্ব ১

Process ও tool-এর চেয়ে মানুষ ও পারস্পরিক যোগাযোগ; বিস্তারিত নথির চেয়ে কাজ করা software; চুক্তির দর-কষাকষির চেয়ে গ্রাহকের সাথে সহযোগিতা; পরিকল্পনা মানার চেয়ে পরিবর্তনে সাড়া।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… তাহলে নথি লাগে না? — লাগে; ডান দিকেরও মূল্য আছে, বাঁ দিকের মূল্য বেশি — Manifesto-তেই লেখা। পর্ব ৫

না। Scrum Master দলের কাছে Scrum কার্যকর করার দায় নেন — বাধা সরানো, coaching; কাজ বণ্টন বা boss-এর ভূমিকা নয়। কী বানানো হবে ঠিক করেন Product Owner, কীভাবে — Developers.
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… Daily Scrum কে চালান? — Developers-দের event; Scrum Master নিশ্চিত করেন যে এটি হয় আর ১৫ মিনিটে থাকে। পর্ব ৫

Little-এর সূত্রে cycle time = WIP ÷ throughput; throughput একই থাকলে কম WIP মানে প্রতিটি কাজ তাড়াতাড়ি শেষ, অর্ধেক-শেষ কাজের অপচয় আর context switch কমে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… limit খুব কম হলে? — মানুষ অলস বসে থাকেন, throughput কমে; limit ঠিক হয় পর্যবেক্ষণে। পর্ব ৬

না। Git আপনার কম্পিউটারে চলা version control tool; GitHub (বা GitLab, Bitbucket) Git repository রাখার অনলাইন সেবা, সাথে pull request, issue, CI.
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… Pull request কি Git-এর command? — না, platform-এর সুবিধা; Git-এর নিজের পথ email-এ patch (format-patch, am). পর্ব ৭ · পর্ব ১৬

File-এর বর্তমান লেখা blob হিসেবে object store-এ রাখে আর index-এ সেই path-এর পাশে blob-এর hash লেখে — পরের commit-এর খসড়া।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… add-এর পরে file বদলালে commit-এ কোনটি যায়? — add করার সময়ের লেখা; নতুন বদলের জন্য আবার add. পর্ব ৮ · পর্ব ৫২

.gitignore শুধু untracked file-এর জন্য; file আগেই track হলে git rm --cached <file> দিয়ে index থেকে সরিয়ে commit করতে হয়।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… সেটি যদি password-এর file হয়? — ইতিহাসে থেকেই যায়; আগে key বাতিল ও বদল, তারপর history পরিষ্কার। পর্ব ১০ · পর্ব ৫৭

প্রথমটি working tree বনাম index (যা এখনো stage হয়নি); দ্বিতীয়টি index বনাম শেষ commit (যা commit-এ যাবে); তৃতীয়টি working tree বনাম শেষ commit (সব মিলিয়ে)।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… @@ -5,7 +5,7 @@ মানে? — পুরোনো আর নতুন ফাইলের ৫ নম্বর লাইন থেকে ৭টি লাইনের অংশ। পর্ব ৯

না। HEAD~2 = প্রথম parent ধরে দুই ধাপ পেছনে (“দাদা”); HEAD^2 = merge commit-এর দ্বিতীয় parent (মিশে আসা branch-এর দিক)।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… সাধারণ commit-এ HEAD^2? — দ্বিতীয় parent নেই, তাই Git ত্রুটি দেখায়। পর্ব ৯

Revert: নতুন একটি উল্টো commit যোগ হয়, ইতিহাস বদলায় না, তাই সহকর্মীদের clone ভাঙে না। Reset শেয়ার করা history মুছে দেয়, তারপর force push লাগে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… একটি merge commit revert করবেন কীভাবে? — git revert -m 1 <merge>: কোন parent-কে মূলধারা ধরবেন, তা বলে দিতে হয়। পর্ব ১১

<<<<<<< HEAD থেকে ======= পর্যন্ত বর্তমান branch-এর (ours) লেখা, তার নিচে >>>>>>> feature পর্যন্ত আনা branch-এর (theirs) লেখা। ঠিক করে marker মুছে git add, তারপর commit; ফিরতে git merge --abort.
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… base-এর লেখাও দেখতে চাইলে? — merge.conflictStyle diff3 বা zdiff3. পর্ব ১৩ · পর্ব ৫৪

না। Git লেখার লাইন মেলায়, অর্থ নয় — একজন function-এর নাম বদলালেন, আরেকজন পুরোনো নামে নতুন ডাক যোগ করলেন; conflict ছাড়াই merge, কিন্তু build ভাঙে (semantic conflict).
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… ধরবেন কীভাবে? — merge-এর পরে test আর CI; ছোট branch, ঘন merge. পর্ব ১৩

git rebase -i-এর todo list-এ pick, reword, edit, squash, fixup, drop লিখে commit মেলানো, ক্রম বদলানো, বার্তা ঠিক করা বা বাদ দেওয়া যায় — PR-এর আগে ইতিহাস গোছাতে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… squash আর fixup-এর পার্থক্য? — দুটিই আগের commit-এ মেশে; squash বার্তা জোড়া দিতে editor খোলে, fixup নতুনটির বার্তা ফেলে দেয়। পর্ব ১৫

History-র ওপর binary search: একটি ভালো আর একটি খারাপ commit দিলে Git মাঝেরটি checkout করে, আপনি good বা bad বলেন — প্রতি ধাপে সন্দেহের পরিসর অর্ধেক; ১,০০০টিতে প্রায় ⌈log₂ ১০০০⌉ = ১০ ধাপ।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… স্বয়ংক্রিয় করবেন কীভাবে? — git bisect run + script: exit 0 ভালো, 125 skip, 1–127-এর বাকিগুলো খারাপ। পর্ব ৫৫

অর্ধেক কাজ commit না করে তুলে রেখে অন্য branch-এ জরুরি কাজে যেতে; git stash push -u untracked file-ও নেয়। apply ফিরিয়ে আনে কিন্তু entry রাখে; pop এনে মুছে দেয় — তবে conflict হলে pop-ও entry রেখে দেয়।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… দীর্ঘদিনের জন্য? — stash নয়, একটি WIP commit বা git worktree. পর্ব ৫৬

না। user.name আর user.email যে কেউ যা খুশি বসাতে পারেন। প্রমাণ দেয় cryptographic স্বাক্ষর — git commit -S, git tag -s, যাচাইয়ে git verify-commit.
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… একটি API key push হয়ে গেলে প্রথম কাজ? — key বাতিল ও নতুন key; history পরিষ্কার পরে, কারণ পুরোনো clone-এ কপি থেকে যায়। পর্ব ৫৭

Monorepo-তে সব project এক ইতিহাসে, তাই একাধিক project-এর বদল এক commit-এ — দাম হলো tooling (affected build, cache). Submodule অন্য repository-র শুধু একটি commit id pin করে রাখে; সেটি নিজে থেকে এগোয় না।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… বড় binary file? — Git LFS: Git-এ ছোট pointer, আসল file আলাদা জায়গায়। পর্ব ১৯

অনেক জ্ঞান tacit — মানুষ যা করেন, তা সবসময় মুখে বলেন না বা বলতে পারেন না; আর একজনের কণ্ঠ পুরো user class নয়। তাই observation, prototype আর পুরোনো নথি লাগে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… stakeholder কারা? — যাঁরা প্রভাবিত হন বা প্রভাব ফেলেন: ব্যবহারকারী, ক্রেতা, operator, নিয়ন্ত্রক। পর্ব ২০

Small — একটি sprint-এ শেষ হয়, অনুমান করা যায়; Testable — acceptance criteria দিয়ে “শেষ হয়েছে” যাচাই করা যায়।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… বড় story ভাঙবেন কীভাবে? — মূল্য রেখে উল্লম্বভাবে (UI থেকে database পর্যন্ত সরু টুকরো), স্তর ধরে নয়। পর্ব ২২

Requirement validation জিজ্ঞেস করে লেখা চাহিদাই ঠিক চাহিদা কি না (stakeholder-এর সাথে review, prototype); verification পরে দেখে তৈরি জিনিস সেই লেখা চাহিদা মানে কি না।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… কোড লেখার আগে ভুল ধরা কেন সস্তা? — দেরিতে ধরা ভুল নকশা, কোড আর test সব জায়গায় বদল চায়। পর্ব ২৪

Cohesion বেশি হলে এক বদলের কারণ এক জায়গায় থাকে; coupling কম হলে সেই বদল বাইরে ছড়ায় না — দুটো মিলে বদল সস্তা আর নিরাপদ।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… অতিরিক্ত ভাগ করলে? — অগণিত ছোট module-এর মধ্যে যোগাযোগই নতুন coupling; ভারসাম্য লাগে। পর্ব ২৫

গণিতে হ্যাঁ, কোডে setter থাকলে না: Rectangle-এর প্রতিশ্রুতি “width বদলালে height বদলায় না” Square রাখতে পারে না — LSP ভাঙে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… সমাধান? — immutable shape, বা দুটি আলাদা type একটি Shape interface-এর নিচে। পর্ব ২৮

লুকানো global state: যেকোনো জায়গা থেকে বদলানো যায়, test একটি আরেকটির ওপর নির্ভর করে, নির্ভরতা constructor-এ দেখা যায় না।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… একটিমাত্র instance তবু দরকার হলে? — composition root-এ একবার বানিয়ে dependency injection দিয়ে দেওয়া; DI container-এ singleton lifetime. পর্ব ৩৩ · পর্ব ৩৭

দুটিতেই context একটি interface-এর object-কে কাজ দেয়; Strategy বাছেন client (কোন ছাড়ের নিয়ম), State বদলায় object নিজে, ঘটনার জবাবে (ধার → ফেরত → জরিমানা বাকি)।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… State pattern ছাড়া? — বড় switch, যা প্রতিটি নতুন অবস্থায় অনেক জায়গায় বদলায়। পর্ব ৩৬

Michael Feathers-এর সংজ্ঞায় test ছাড়া কোড। আগে characterization test দিয়ে আজকের আচরণ ধরে রাখা, তারপর ছোট নিরাপদ বদল; নতুন কাজ sprout বা wrap করে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… পুরো নতুন করে লিখলে? — বড় rewrite ঝুঁকিপূর্ণ; strangler fig — নতুন অংশ পাশে বসিয়ে ধীরে ধীরে পুরোনোটি সরানো। পর্ব ৪৩

Comment বলে “কেন” (ব্যবসার নিয়ম, অপ্রত্যাশিত সিদ্ধান্তের কারণ), কোড বলে “কী”। ভালো নাম আর ছোট function বেশিরভাগ “কী”-এর comment অপ্রয়োজনীয় করে; commented-out কোড মুছে ফেলুন — Git মনে রাখে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… formatting নিয়ে review-এ তর্ক? — না; স্বয়ংক্রিয় formatter. পর্ব ৪১

না। Coverage বলে কোন কোড চলেছে, ঠিক চলেছে কি না নয় — assertion ছাড়া test-ও ১০০% দিতে পারে। আর বাদ পড়া requirement-এর কোডই নেই, তাই coverage তা ধরে না।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… test কতটা ভালো, মাপবেন কীভাবে? — mutation score. পর্ব ৫০

Stub ঠিক করা উত্তর দেয় — ফল দেখে যাচাই (state verification); mock প্রত্যাশিত ডাক জানে আর নিজে যাচাই করে (behaviour verification). Value বা ছোট pure কোড mock করবেন না; নিজের নয় এমন API নিজের adapter-এর পেছনে রাখুন।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… বেশি mock-এর ক্ষতি? — implementation-এর সাথে বাঁধা ভঙ্গুর test, আর আসল API বদলালেও test সবুজ (mock drift). পর্ব ৪৯

কোড না বদলেও কখনো পাস, কখনো ফেল — কারণ প্রায়ই নির্দিষ্ট sleep, ভাগ করা অবস্থা, test-এর ক্রম, সময়-অঞ্চল বা বাইরের service. অন্ধ retry দিয়ে ঢাকা সমাধান নয়।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… তাহলে কী করবেন? — পরিসংখ্যান নিয়ে মালিকসহ quarantine, তারপর কারণ ধরে ঠিক। পর্ব ৫১

না। CI-র “integration” মানে অন্তত দিনে একবার mainline-এ মেলানো; দীর্ঘ branch-এ test চালানো শুধু “branch-এ test”.
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… অসমাপ্ত feature তাহলে কীভাবে main-এ যাবে? — feature flag-এর পেছনে, বা ছোট ছোট নিরাপদ ধাপে। পর্ব ৫৮

Story point আপেক্ষিক আকার — জটিলতা, কাজের পরিমাণ আর অনিশ্চয়তা মিলিয়ে, দলের নিজস্ব মাপ; ঘণ্টা পরম সময়। Planning poker-এ সবাই একসাথে কার্ড দেখান, যাতে প্রথম কথা বলা মানুষের প্রভাব (anchoring) কমে।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… দুই দলের velocity তুলনা? — অর্থহীন; point-এর মাপ দলভেদে আলাদা। পর্ব ৬০

কতজন মানুষ হঠাৎ চলে গেলে project আটকে যায়; Git history-তে কে কোন file জানেন দেখে, সবচেয়ে বেশি জানা মানুষকে একে একে সরিয়ে দেখা যায় কখন অর্ধেকের বেশি file অভিভাবকহীন।
তারপর পরীক্ষক জিজ্ঞেস করতে পারেন… বাড়াবেন কীভাবে? — pair programming, code review-এ ঘুরিয়ে reviewer, লেখা নথি। পর্ব ৬৩