CRUD সবাই পারে - capstone-কে interview-এ বলার মতো গল্প বানায় তার জটিল feature-টা। আজ সেই অংশটা: যেখানে একাধিক ধাপ, একাধিক ধারণা একসাথে কাজ করে। Option অনুযায়ী চেহারা বদলাবে, কিন্তু গাঁথনির নিয়ম একই।
Khabar Dhandha হলে - order flow
Order দেওয়া মানে একটা লম্বা শৃঙ্খল: cart-এর item যাচাই, দাম হিসাব (client-এর পাঠানো দামে ভরসা নয় - server নিজে menu থেকে হিসাব করবে), zone অনুযায়ী delivery charge, তারপর transaction-এ order + items + stock একসাথে। Status বদলানোর শৃঙ্খলাও ঠিক করুন - 'delivered' order আবার 'pending' হতে পারবে না। Status বদলালেই queue দিয়ে notification, আর customer পাবে Socket.io-তে live আপডেট। সপ্তাহ ৩-এর তিনটা ধারণাই এখানে একসাথে মিলছে।
// status কোন পথে বদলাতে পারবে - এক জায়গায় লিখে রাখা
const NEXT_STATUS = {
pending: ["confirmed", "cancelled"],
confirmed: ["preparing", "cancelled"],
preparing: ["on-the-way"],
"on-the-way": ["delivered"],
delivered: [],
cancelled: [],
};
if (!NEXT_STATUS[order.status].includes(newStatus)) {
throw new Error("এই status থেকে ওই status-এ যাওয়া যাবে না");
}অন্য option নিলে
Job board নিলে জটিল অংশটা হলো filter ও search - ধরন, জায়গা, বেতনের range মিলিয়ে Prisma query, সাথে cursor pagination, আর application-এর status flow একই শৃঙ্খলায়। Chat backend নিলে জটিল অংশ হলো message history-র pagination আর online status - কে অনলাইন সেটা Redis-এ রাখা, যাতে server বাড়লেও হিসাব মেলে।
যেটাই করুন, আজকের শেষে নিজেকে একটা প্রশ্ন করুন: এই feature-টা interview-তে গল্প করে বলতে পারব তো - সমস্যা কী ছিল, কোন কোন ধারণা কীভাবে গাঁথলাম, কোন সিদ্ধান্তটা কেন নিলাম? গল্পটা তৈরি থাকলেই capstone তার কাজ করেছে।
সবাই যে ভুলটা করে
জটিল feature বানাতে গিয়ে মূল শৃঙ্খলা ভেঙে ফেলা - যেমন status যেকোনো অবস্থা থেকে যেকোনো অবস্থায় বদলাতে দেওয়া, কিংবা client-এর পাঠানো দামেই order নেওয়া। Feature যত জটিল, নিয়ম তত পরিষ্কারভাবে কোডে লিখে রাখতে হয়।
আজকের Practice
আপনার capstone-এর জটিল feature-টা শেষ করুন - status-এর শৃঙ্খলা কোডে লিখে, transaction যেখানে লাগে সেখানে বসিয়ে। তারপর feature-টার গল্পটা তিন-চার বাক্যে লিখে ফেলুন - এটাই interview-এর উত্তর।
Interview-এ কীভাবে বলবেন
নিজেকে যাচাই করুন: 'আমার capstone-এর কঠিন অংশটা ছিল বহু-ধাপের flow-টা নিরাপদ রাখা - দাম server-এ হিসাব করা, transaction-এ পুরো order, status বদলের নির্দিষ্ট শৃঙ্খলা, আর প্রতিটা বদলে queue ও real-time দিয়ে খবর পাঠানো।'