Production-এর আগে code review কোনো diff approve করার ceremony নয়।

এটি code দেখতে যা করছে এবং real user, real data, failed provider, repeated request ও imperfect operation-এর মধ্যে system আসলে যা করবে—এই দুইয়ের gap খোঁজার চেষ্টা।

সব change-এ আমি নিচের প্রতিটি প্রশ্ন একই weight-এ ব্যবহার করি না। Static marketing page এবং payment callback-এর risk এক নয়। Checklist depth adjust করতে সাহায্য করে, কিন্তু গুরুত্বপূর্ণ category ভুলতে দেয় না।

Intended behavior দিয়ে শুরু

Implementation detail পড়ার আগে আমি জানতে চাই:

• কোন user বা system outcome বদলাবে?
• কোন route, job, component বা data model behavior-এর owner?
• Change-এর বাইরে কী?
• Acceptance-এর evidence কী?
• কোন existing behavior compatible রাখতে হবে?

এই context ছাড়া locally clean code approve হতে পারে, যদিও সেটি ভুল সমস্যা সমাধান করছে।

Compact scope এখানে কাজে লাগে। Process-টি আছে requirement থেকে shippable scope-এ।

Complete path trace

User-facing change-এ আমি entry থেকে effect পর্যন্ত trace করি:

1. user action বা external event;
2. client state ও validation;
3. server boundary;
4. authentication ও authorization;
5. domain rule;
6. persistence বা provider call;
7. response ও user feedback;
8. log, metric বা audit evidence।

File-by-file review যে gap লুকাতে পারে, এতে তা দেখা যায়।

Disabled button authorization নয়। Server action বা API route-এ access আবার enforce করতেই হবে।

প্রতিটি trust boundary review

Browser, webhook, file, environment variable, database record, URL, header বা external API থেকে আসা data risk অনুযায়ী validate করা দরকার।

আমি দেখি:

• syntax ও size limit;
• শুধু type নয়, domain meaning;
• ownership ও tenant scope;
• allowlisted field;
• safe query construction;
• output encoding;
• upload type ও storage rule;
• redirect ও URL restriction;
• webhook signature ও replay protection;
• secret handling ও log redaction।

TypeScript code নিয়ে ভাবতে সাহায্য করে। Untrusted request runtime-এ validate করে না।

Tenant data থাকলে এই review secure multi-tenant SaaS foundation-এর সঙ্গে সরাসরি যুক্ত।

Happy path-এর বাইরে দেখুন

Happy-path code সাধারণত পড়ার সবচেয়ে সহজ অংশ।

আমি জিজ্ঞেস করি কী হবে যখন:

• provider timeout করবে;
• একই action দুইবার submit হবে;
• user navigate away করবেন;
• একটি operation success আর পরেরটি fail হবে;
• database write conflict করবে;
• queue retry করবে;
• record আর থাকবে না;
• response ভুল order-এ আসবে;
• dependency degraded হবে;
• cleanup-ও fail করবে।

Operation অনুযায়ী answer হতে পারে idempotency, transaction, compensation, bounded retry, cancellation বা clear recoverable state।

মূল বিষয় হলো failure behavior design করা, accident হিসেবে রেখে দেওয়া নয়।

User-visible state check

Production review শুধু successful screenshot নয়।

Interactive UI-তে আমি দেখি implementation-এ আছে কি না:

• loading ও pending;
• empty data;
• validation error;
• server error;
• disabled action;
• success confirmation;
• long text ও narrow screen;
• keyboard operation;
• visible focus;
• accessible name;
• reduced motion;
• repeated submission;
• stale data।

Interface-কে system state সম্পর্কে সত্য বলতে হবে। কাজ চললেও button finished দেখালে usability এবং data—দুই risk হয়।

Data compatibility

Data change বিশেষ সতর্কতা চায়।

আমি দেখি:

• old record-এ new field অনুপস্থিত;
• new enum value old code-এ পৌঁছানো;
• rolling deployment-এর default behavior;
• index বা constraint change;
• backfill requirement;
• migration restart safety;
• rollback consequence;
• serialization change;
• timezone ও date assumption।

“Model compile করেছে” stored production data compatible হওয়ার evidence নয়।

API-কে contract হিসেবে review

API change সব caller-কে প্রভাবিত করে, edited folder-এর বাইরে থাকলেও।

আমি দেখি:

• request ও response schema;
• status code;
• error shape;
• authentication requirement;
• pagination ও ordering;
• idempotency behavior;
• version বা compatibility strategy;
• timeout ও cancellation;
• documentation ও example।

Deep design principle আছে growth সহ্য করতে পারে এমন API contract-এ।

Resource যেখানে খরচ হয় সেখানে performance

আমি প্রতিটি loop-কে performance problem বলি না।

Likely production cost দেখি:

• repeated database query;
• unbounded result;
• independent I/O sequential করা;
• বড় client bundle;
• expensive server rendering;
• duplicate provider call;
• missing cache বা invalidation;
• image ও font payload;
• hot request path-এর work।

Review-এ cost-কে user path এবং measurement plan-এর সঙ্গে যুক্ত করা দরকার। Frontend limit-এর জন্য পড়ুন client project performance budget।

Change কীভাবে operate হবে

Production-এর আগে কারও জানা দরকার:

• কোন configuration লাগবে;
• secret কীভাবে supply হবে;
• success বা failure কোন signal-এ বোঝা যাবে;
• alert-এর owner কে;
• support কীভাবে affected request চিনবে;
• feature flag আছে কি না;
• rollback কীভাবে;
• documentation বদলেছে কি না।

Observability মানে সবকিছু log করার permission নয়। Secret ও অপ্রয়োজনীয় personal data বাদ দিয়ে log useful হতে হবে।

Risk অনুযায়ী test

সঠিক boundary-তে behavior prove করে এমন focused test আমি prefer করি।

উদাহরণ:

• domain decision-এর pure unit test;
• storage ও authorization-এর integration test;
• provider adapter-এর contract test;
• fixed bug-এর regression test;
• critical user path-এর end-to-end coverage;
• unauthorized বা malformed request-এর negative test।

External API, clock, randomness এবং paid service deterministic test environment-এ control করা উচিত।

শেষ review question

আমার শেষ প্রশ্ন সহজ:

Production-এ fail করলে team কি জানতে পারবে কী হয়েছে, damage limit করতে পারবে, পরিষ্কারভাবে communicate করতে পারবে এবং recover করতে পারবে?

উত্তর unclear হলে code finished হতে পারে, release ready নয়।

আপনার release সামনে এবং independent production-readiness review দরকার হলে affected path, risk level ও release constraint পাঠান।