Claude Code থেকে ফিচার স্পেস: একটি সহজ ওয়ার্কফ্লো

Q: কোন আউটপুট এবং সাইড-এফেক্টগুলো স্পেসে থাকা উচিত?

দৃষ্টিগোচর জিনিসগুলোতে মনোযোগ দিন: - সফল ফলাফল (কোন পরিবর্তন হয়, ব্যবহারকারী কী দেখে) - সাধারণ ত্রুটির ধরন (সাইন ইন নেই, অনুমতি নেই, পাওয়া যায়নি, ভ্যালিডেশন ত্রুটি) - সাইড-এফেক্ট (রেকর্ড আপডেট, ইমেল/নোটিফিকেশন পাঠানো, ব্যাকগ্রাউন্ড জব কিউ করা) সাইড-এফেক্ট গুরুত্বপূর্ণ কারণ সেগুলো অন্য ফিচার, সাপোর্ট ও অপস দলে প্রভাব ফেলে।

Q: কোন এজ কেসগুলো লাইভিং স্পেসে সবচেয়ে জরুরি?

গোছালোভাবে স্পষ্টভাবে লিখুন: - Empty states (ফলাফল নেই, অনুমতি নেই) - Retries/timeouts এবং পরবর্তী করণীয় - Duplicate submissions (ডাবল-ক্লিক, রিফ্রেশ) - Concurrency (দুইজন একই রেকর্ড এডিট করলে) - Time-based rules (মেয়াদ উত্তীর্ণ, কুলডাউন) এগুলোই সাধারণত আশ্চর্যের ও বাগের উত্স।

লগ ইন শুরু করুন

কেন আপনার কোডের সাথে মিল থাকা স্পেস দরকার\n\nমানুষেরা অ্যাপ কী করে সে সম্পর্কে ভিন্নভাবে মনে রাখে, তাই মতবিরোধ হয়। সাপোর্ট মনে রাখে সর্বশেষ রাগান্বিত টিকেটটি। সেলস মনে রাখে ডেমো পথে যা দেখিয়েছিল। ইঞ্জিনিয়াররা মনে রাখে ফিচারটা কীভাবে করার কথা ছিল। তিনজনকে জিজ্ঞেস করলে তিনটি আত্মবিশ্বাসী উত্তর পাবেন, যেগুলো বর্তমান বিল্ডের সাথে মেলেনা।\n\nসময়ের সঙ্গে সঙ্গে কোডই একমাত্র উৎস হয়ে যায় যা আপ-টু-ডেট থাকে। ডকস আলাদা হয়, টিকিট বন্ধ হয়, এবং দ্রুত ফিক্স গুলো জমে যায়। একটা রুটে নতুন ভ্যালিডেশন যোগ হয়। UI টগল ডিফল্ট বদলায়। হ্যান্ডলার ভিন্ন এরর ফেরত দিতে শুরু করে। কেউ স্পেস আপডেট করে না কারণ এটা অপশনাল মনে হয়, এবং প্রতিটি পরিবর্তন ডকুমেন্ট করার জন্য খুব ছোট মনে হয়।\n\nএটার ফলে predictable সমস্যা হয়ে দাঁড়ায়। টিমগুলো এমন কনডিশন শিপ করে যা এজ কেসগুলো ভেঙে দেয় যেগুলো তাদের জানা ছিল না। QA শুধু হ্যাপি পাথ টেস্ট করে এবং হ্যান্ডলারগুলোর ভেতরে লুকানো নিয়মগুলো মিস করে। নতুন সহকর্মীরা UI থেকে আচরণ কপি করে নেওয়ায় বাস্তব সীমাবদ্ধতা বোঝে না। স্টেকহোল্ডাররা চর্চা করে মতামত নিয়ে, বদলে সম্মত আচরণের দিকে ইঙ্গিত করে না।\n\nভালো ফলাফল মানে একটা নিখুঁত ডকুমেন্ট নয়। এটা যৌথ স্পষ্টতা। প্রত্যেককে জানতে হবে: “আমি X করলে কী হবে?” এবং “সিস্টেম কি গ্যারান্টি দেয়?” অনুমান ছাড়া। ফলে কম সারপ্রাইজ, ছোট রিভিউ সাইকেল, এবং কম “হয় তো এটা আগে থেকেই করে” মুহূর্ত—কারণ টিম একই সুত্র দেখছে।\n\nযখন স্পেস কোডের সাথে মেলে, তখন পরিবর্তন পরিকল্পনা করা নিরাপদ হয়। আপনি স্থিতিশীলতা, আকস্মিকতা এবং অনুপস্থিতি শিপ করার আগে দেখতে পাবেন।\n\n## লাইভিং স্পেস এবং গ্যাপস লিস্ট কি\n\nলাইভিং স্পেস হলো সংক্ষিপ্ত, সম্পাদনাযোগ্য বর্ণনা যা বলে অ্যাপ আজ কী করে। এটা একবারের ডকুমেন্ট নয়। আচরণ বদলালে এটা বদলে যায়, যাতে টিম এটাকে বিশ্বাস করতে পারে।\n\nকথ্য হচ্ছে: routes, handlers এবং স্ক্রিন থেকে বাস্তব আচরণ পড়ে, তারপর সোজাসাপ্টা ভাষায় তা লিখে রাখা। উদাহরণস্বরূপ Claude Code ব্যবহার করার কথা বললে লক্ষ্যই সোজা: বাস্তব আচরণ পড়ুন এবং লিখে রাখুন।\n\nএকটি ব্যবহারযোগ্য লাইভিং স্পেসে ফোকাস থাকে কী ব্যবহারকারী দেখতে পায় এবং সিস্টেম কী প্রতিশ্রুতি দেয়। এটি অন্তর্ভুক্ত করা উচিত:\n\n- ব্যবহারকারী-দৃশ্যমান আচরণ (ক্লিক করলে, সাবমিট করলে, সাইন ইন করলে কী হয়)\n- নিয়ম এবং সীমাবদ্ধতা (প্রয়োজনীয় ফিল্ড, লিমিট, হিসাব করার নিয়ম)\n- এজ কেস (খালি অবস্থান, এরর, রিট্রাই, টাইমআউট)\n- অনুমতিসমূহ (কে দেখা, তৈরি, সম্পাদনা, মুছতে পারে)\n- গুরুত্বপূর্ণ আউটপুট (ইমেল পাঠানো, রেকর্ড তৈরি, স্ট্যাটাস পরিবর্তন)\n\nকী না ঢুকবে: কোড কিভাবে সংগঠিত তা। ফাইলের নাম এবং রিফ্যাক্টর প্ল্যান লেখা মানে আপনি ইমপ্লিমেন্টেশন ডিটেলে ঢুকছেন। এভাবে বিরত থাকুন:

এই মার্কগুলো দ্রুত টিম প্রশ্নে পরিণত হয় নিরীক্ষিত অনুমানের বদলে।\n\n## গ্যাপস লিস্ট তৈরি করে কিন্তু সেটাকে ব্যাকলগে না পরিণত করা\n\nগ্যাপস লিস্টটি দ্বিতীয় জিরো নয়। এটা সংক্ষিপ্ত, প্রমাণভিত্তিক রেকর্ড যেখানে কোড ও ইচ্ছিত আচরণ মিলে না, বা যেখানে কেউ স্পষ্টভাবে ব্যাখ্যা করতে পারে না "সঠিক" কী। ভালভাবে করলে এটাচুক্তির টুল হয়, পরিকল্পনার লড়াই নয়।\n\nকি গণ্য হবে সেটায় কড়া হওয়া দরকার:

অস্পষ্ট আচরণ: অ্যাপ কিছু করে কিন্তু নিয়ম কোথাও লেখা নেই।
অসঙ্গতি: দুই জায়গায় একই কেসে ভিন্ন আচরণ।
অনুপস্থিত নিয়ম: একটি এজ কেস আছে কিন্তু সিদ্ধান্ত কোড বা ডকসে নেই।\n\nগ্যাপ লগ করলে প্রতিটি আইটেমে তিনটি অংশ রাখুন যাতে তা প্রমাণভিত্তিক থাকে:
Type: bug (কোড মনে হয় ভুল) বা missing decision (ইচ্ছা অস্পষ্ট)

প্রমাণ তালিকাটাকে মতামত থেকে রক্ষা করে। উদাহরণ: "POST /checkout/apply-coupon মেয়াদোত্তীর্ণ কুপন গ্রহণ করে, কিন্তু CouponBanner.tsx UI তে সেগুলো ব্লক করা হয়। প্রভাব: রাজস্ব ও ব্যবহারকারী বিভ্রান্তি। টাইপ: বাগ বা সিদ্ধান্ত অনুপস্থিত (ইচ্ছে স্থির করতে)।"\n\nসংক্ষিপ্ত রাখুন। প্রথম পাসে একটি কঠোর সীমা দিন, যেমন 10 আইটেম। যদি আপনি 40 সমস্যা পান, সেগুলো প্যাটার্নে গ্রুপ করে শীর্ষ উদাহরণগুলো রাখুন (ভ্যালিডেশন অসঙ্গতি, অনুমতি চেক, খালি স্টেট) এবং বাকিগুলো সারাংশে রাখুন।\n\nগ্যাপস লিস্টে ডেডলাইন বা নির্ধারণ এড়িয়ে চলুন। যদি মালিকানা দরকার হয়, হালকা রেখে দিন: সিদ্ধান্ত কারা নেবেন (product) বা কে যাচাই করবেন (engineering), তারপর প্রকৃত পরিকল্পনা আপনার ব্যাকলগে নিয়ে যান।\n\n## উদাহরণ: কোড থেকে একটি বাস্তব ফিচার ডকুমেন্ট করা\n\nএকটি ছোট, উচ্চ-ট্রাফিক স্কোপ নিন: প্রোমো কোড ও শিপিং অপশনসহ চেকআউট। লক্ষ্য হলো পুরো প্রোডাক্ট রিরাইট করা না—শুধু আজ অ্যাপ কী করে তা ধারণা করা।\n\nব্যাকএন্ড রুট দিয়ে শুরু করুন। সচরাচর নিয়মগুলো প্রথমে সেখানেই দেখা যায়। আপনি দেখতে পারেন , , এবং এর মতো রুট।\n\nওই হ্যান্ডলার থেকে আচরণ সাধারণ কথায় লিখুন:

অবশেষে, আপনার গ্যাপস লিস্ট সামনে রাখুন—প্রতিটি গ্যাপকে এই লেবেলগুলোর একটা দিন: "unknown, needs decision," "bug, fix," বা "missing feature, plan." যদি কিছু লেবেল না হয়, তালিকা আটকে পড়ে এবং স্পেস আর লাইভিং থাকে না।\n\n## স্পেস শেয়ার করার আগের দ্রুত চেকলিস্ট\n\nস্বচ্ছতা, কভারেজ, ও অ্যাকশনযোগ্যতার জন্য দ্রুত পাস করুন। যে কেউ লিখেনি সেই ব্যক্তি যদি এটি পড়ে বুঝতে পারে ফিচার আজ কী করে এবং কী অস্পষ্ট।\n\n### স্বচ্ছতা ও যৌথ বোঝাপড়া\n\nনতুন সহকর্মীর দৃষ্টিকোণ থেকে স্পেসটি পড়ুন। যদি তারা এক মিনিটে ফিচারটি সংক্ষেপে বলতে পারে, আপনি বেশ ভাল অবস্থায় আছেন। যদি বারবার প্রশ্ন আসে "কোথা থেকে শুরু?" বা "হ্যাপি পাথ কী?" তাহলে প্রথম অংশ চট করে শক্ত করুন।\n\nচেক করুন:

One-page test: শুরুর অংশে ব্যবহারকারীর লক্ষ্য, ফ্লো কোথায় শুরু ও শেষ হয় স্পষ্ট আছে কিনা।
Roles and access: কী রোল কী করতে পারে ও করতে পারে না।

সাধারণ প্রশ্ন

আমি বিদ্যমান কোড থেকে ফিচার স্পেস লিখতে চাইলে কোথা থেকে শুরু করব?

একটি ছোট, ব্যবহারকারীবোধ্য অংশ থেকে শুরু করুন (উদাহরণ: “পাসওয়ার্ড রিসেট” বা “টিমমেট আমন্ত্রণ”)। প্রথমে routes/handlers পড়ে নিয়ম ও আউটকাম ধরুন, তারপর UI ফ্লো পরীক্ষা করে দেখুন ব্যবহারকারী কী দেখে (disabled অবস্থান, ত্রুটি, redirect)। একটি নির্দিষ্ট টেমপ্লেট ব্যবহার করে লিখুন এবং অজানা বিষয়গুলো আলাদা gaps তালিকায় লগ করুন।

স্পেস কি প্রোডাক্টকে কী করা উচিত তা বর্ণনা করবে, নাকি বর্তমান কোড কী করছে তা?

প্রাথমিকভাবে: বর্তমান কোডের আচার-ব্যবহারের কথাই সত্য ধরে নিন এবং সেটি ডকুমেন্ট করুন.

যদি আচরণ অসম্প্রদায়িক বা অনিয়মিত মনে হয়, স্পেসে সেটাকে সরাসরি বদলানোর চেষ্টা করবেন না—প্রমাণসহ একটি gap হিসেবে মার্ক করুন (কোথায় দেখা গেছে এবং কী করছে), তারপর সিদ্ধান্ত নিন কোড বদলাবেন নাকি স্পেস আপডেট করবেন।

কোন সিম্পল স্পেস ফরম্যাট অ্যাপ বড় হওয়ার সঙ্গে সঙ্গে পড়ার যোগ্য থাকে?

বোঝার সুবিধার জন্য নিয়মিত ও একরকম ফরম্যাট রাখুন। এক বাস্তব টেমপ্লেট:

Purpose
Entry points
Preconditions (auth/role/data)
Main flow (5–10 স্টেপ)
Data and side effects
Errors and edge cases
Open questions

এভাবে লেখা স্পেস পড়তে সহজ থাকে এবং অনিয়ম দ্রুত ধরা যায়।

কিভাবে হ্যান্ডলার ভ্যালিডেশন এবং auth চেকগুলোকে সোজাসাপ্টা ভাষায় লিখবো?

রুলগুলোকে ব্যবহারকারী-বর্নিত ভাষায় লিখুন, কোড নোটের মতো নয়.

উদাহরণ:

“ইমেল বৈধ হতে হবে”
“পরিমাণ কমপক্ষে 1 হতে হবে”
“শুধু অ্যাডমিনরা কোনো অর্ডার বাতিল করতে পারে; সাধারণ ব্যবহারকারী 10 মিনিটের মধ্যে নিজের অর্ডার বাতিল করতে পারে”

এবং এমন ঘটনা যেখানে ত্রুটি ট্রিগার হয় এবং ব্যবহারকারী কী দেখে তা ধরুন।

কোন আউটপুট এবং সাইড-এফেক্টগুলো স্পেসে থাকা উচিত?

দৃষ্টিগোচর জিনিসগুলোতে মনোযোগ দিন:

সফল ফলাফল (কোন পরিবর্তন হয়, ব্যবহারকারী কী দেখে)
সাধারণ ত্রুটির ধরন (সাইন ইন নেই, অনুমতি নেই, পাওয়া যায়নি, ভ্যালিডেশন ত্রুটি)
সাইড-এফেক্ট (রেকর্ড আপডেট, ইমেল/নোটিফিকেশন পাঠানো, ব্যাকগ্রাউন্ড জব কিউ করা)

সাইড-এফেক্ট গুরুত্বপূর্ণ কারণ সেগুলো অন্য ফিচার, সাপোর্ট ও অপস দলে প্রভাব ফেলে।

UI এবং ব্যাকএন্ড যদি ভিন্ন কথা বলে (যেমন ফাইল সাইজ সীমা) তাহলে কী করব?

UI যদি কিছু ব্লক করে কিন্তু API তা অনুমোদন করে (বা বিপরীতে), সেটাকে gap হিসেবে লগ করুন যতক্ষণ না সিদ্ধান্ত নেওয়া হয়।

লগ করুন:

UI কি বলছে/করে
ব্যাকএন্ড কী এনফোর্স করছে
প্রভাব (বিভ্রান্তি, নিরাপত্তা, ডেটা সমস্যা)

তারপর এক নিয়মে সম্মত হয়ে কোড এবং স্পেস দুইটাকেই আপডেট করুন।

কিভাবে gaps তালিকা তৈরি করব যাতে এটা প্ল্যানিং ফাইটে পরিণত না হয়?

gaps তালিকাকে ছোট এবং প্রমাণভিত্তিক রাখুন। প্রতিটি আইটেমে থাকতে হবে:

Type: bug বনাম missing decision
Impact: minor বনাম serious (বিভ্রান্তি, নিরাপত্তা, ডেটা লস)
Evidence: কোথায় দেখা গেছে (route/handler/component) এবং সঠিক আচরণ

পরিশেষে এটাকে নতুন জিরোর মতো করবে না—شوচ করে রাখুন কিন্তু বাস্তব পরিকল্পনা আলাদা জায়গায় রাখুন।

কোন এজ কেসগুলো লাইভিং স্পেসে সবচেয়ে জরুরি?

গোছালোভাবে স্পষ্টভাবে লিখুন:

Empty states (ফলাফল নেই, অনুমতি নেই)
Retries/timeouts এবং পরবর্তী করণীয়
Duplicate submissions (ডাবল-ক্লিক, রিফ্রেশ)
Concurrency (দুইজন একই রেকর্ড এডিট করলে)
Time-based rules (মেয়াদ উত্তীর্ণ, কুলডাউন)

এগুলোই সাধারণত আশ্চর্যের ও বাগের উত্স।

কিভাবে টিমের কাছে স্পেস যাচাই করে সবাইকে এটি বিশ্বাসযোগ্য করব?

সংক্ষিপ্ত রাখুন: এক ইঞ্জিনিয়ার ও এক প্রোডাক্টের সাথে 20–30 মিনিটের রিড-থ্রু করুন।

বিবৃতিগুলোকে হ্যাঁ/না প্রশ্নে রূপান্তর করুন (উদাহরণ: “টোকেন না থাকলে কি আমরা সবসময় 403 ফেরত দিই?”)। UI-তে ব্যবহার হওয়া শব্দভাণ্ডার নিয়ে একরকম কথা বলুন (বাটন লেবেল, পেজ শিরোনাম, এরর মেসেজ) যাতে সবাই একে বুঝে।

কিভাবে স্পেসকে 'লাইভিং' রাখা যায় যাতে সেটা আবার ড্রিফট না করে?

স্পেসকে কোডের কাছাকাছি রাখুন এবং শিপিং প্রসেসে আপডেটকে ডিফল্ট আচরণ বানান.

প্র্যাকটিক্যাল ডিফল্টঃ

স্পেসের একটি অনিবন্ধিত মালিক (feature owner/tech lead) যিনি স্পেস পরিবর্তন মর্মে মার্জ করেন
আপডেট ট্রিগার: কোনো আচরণ পরিবর্তন মার্স করা হলে অথবা প্রতি রিলিজ
PR টেমপ্লেটে একটি দ্রুত চেকবক্স: “Spec updated?”
gaps আলাদা রাখুন এবং নিয়মিত সংক্ষিপ্তভাবে রিভিউ করুন

লক্ষ্য: বড় রিরাইট নয়—ছোট, ঘন আপডেট।

আর্কিটেকচার বিতর্ক ও রিরাইট পরিকল্পনা\n\nগ্যাপস লিস্ট আলাদা। এটা ছোট হবে: আপনি স্পেস লেখার সময় দেখা অনৈক্য এবং অস্পষ্টতা।\n\n- বাগ: কোড বর্তমান আচরণ বা সম্মত নিয়ম লঙ্ঘন করে।\n- ফিচার অনুরোধ: আপনি নতুন আচরণ চান।\n- গ্যাপ: আপনি ঠিক জানেন না সঠিক আচরণ কী হওয়া উচিত, বা ভিন্ন স্ক্রিন/রোলে আচরণ অনিকছত্র।\n\nউদাহরণ: একটি রুট 10MB ওপরে ফাইল রিজেক্ট করে কিন্তু UI বলে 25MB। এটা গ্যাপ যতক্ষণ না টিম সিদ্ধান্ত নেয় কোন নিয়মই বাস্তব এবং কোড বা স্পেস আপডেট করে।\n\n## স্কোপ নির্ধারণ এবং সিম্পল স্পেস ফরম্যাট নেওয়া\n\nছোট থেকে শুরু করুন। পুরো অ্যাপ ডকুমেন্ট করার চেষ্টা করলে বিশ্বাসযোগ্য নোটের স্তূপ পেয়ে যাবেন। একটি বর্ণনায় বর্ণনা করা ব্যবহারকারীর এক স্লাইস বেছে নিন, যেমন “টিমমেট আমন্ত্রণ”, “চেকআউট” বা “পাসওয়ার্ড রিসেট”। ভাল স্কোপ হলো একটি ফিচার এলাকা, একটি মডিউল, বা একটি ব্যবহারকারী যাত্রা এন্ট্রি পয়েন্ট থেকে আউটকাম পর্যন্ত।\n\nএন্ট্রি পয়েন্ট বেছে নিন সেই স্থানের উপর ভিত্তি করে যেখানে সত্য থাকে:\n\n- যদি আপনি বাস্তব নিয়ম জানতে চান, রুট ও হ্যান্ডলার থেকে শুরু করুন।

Errors and edge cases: সমস্যা হলে কী হয়\n- Open questions: স্পষ্ট নয় এমন প্রশ্নগুলো\n\nএই স্ট্রাকচার বারবার ব্যবহার করুন—আপনার ফিচার স্পেসগুলো পড়তে সহজ, তুলনাযোগ্য এবং আপডেট করতে সুবিধাজনক থাকবে।\n\n## রুট ও হ্যান্ডলার থেকে আচরণ বের করা\n\nসার্ভার এন্ট্রি পয়েন্ট দিয়ে শুরু করুন। রুট ও হ্যান্ডলারগুলো দেখায় অ্যাপ "কি করে" সুনির্দিষ্টভাবে: কে কল করতে পারে, কী পাঠাতে হবে, কী ফেরত পায়, এবং সিস্টেমে কী বদলে যায়।\n\nস্কোপের রুটগুলো তালিকাভুক্ত করুন এবং প্রতিটিকে একটি ব্যবহারকারী উদ্দেশ্যের সাথে ম্যাপ করুন। লিখবেন না "POST /api/orders." লিখুন "Order স্থাপন করা" বা "Draft সংরক্ষণ করা।" যদি আপনি সাধারণ ভাষায় উদ্দেশ্য নামকরণ করতে না পারেন, সেটাই একটি স্পেস গ্যাপ।\n\nপ্রতিটি হ্যান্ডলার পড়ে ইনপুট ও ভ্যালিডেশন রুলগুলোকে ব্যবহারকারী-দৃশ্যমান প্রয়োজনীয়তা হিসেবে ধরুন। অন্তর্ভুক্ত করুন প্রয়োজনীয় ফিল্ড, অনুমোদিত ফরম্যাট এবং কোন নিয়মগুলো বাস্তব ত্রুটি ঘটায়। উদাহরণ: "ইমেল বৈধ হতে হবে", "পরিমাণ কমপক্ষে 1 হতে হবে", "শুরু তারিখ অতীতে হতে পারবে না।"\n\nAuth এবং রোল চেকগুলো একইভাবে নোট করুন। "middleware: requireAdmin" লেখার পরিবর্তে লিখুন: "শুধু অ্যাডমিনরা যেকোন অর্ডার বাতিল করতে পারবে। সাধারণ ব্যবহারকারী 10 মিনিটের মধ্যে কেবল নিজের অর্ডার বাতিল করতে পারবে।" যদি কোড ownership, ফিচার ফ্ল্যাগ, বা টেন্যান্সি বাউন্ডারি চেক করে, সেগুলোকেও অন্তর্ভুক্ত করুন।\n\nএরপরে আউটপুট ও আউটকাম নোট করুন। সফল হলে কী ফেরত দেয় (তৈরি করা ID, আপডেট করা অবজেক্ট)? সাধারণ ব্যর্থতাগুলো কেমন (401 না সাইন ইন, 403 অনুমতি নেই, 404 পাওয়া যায়নি, 409 কনফ্লিক্ট, 422 ভ্যালিডেশন ত্রুটি)?\n\nশেষে সাইড-এফেক্টগুলো রেকর্ড করুন কারণ সেগুলোও আচরণের অংশ: তৈরি/আপডেট হওয়া রেকর্ড, পাঠানো ইমেল/নোটিফিকেশন, পাবলিশ করা ইভেন্ট, ব্যাকগ্রাউন্ড জব কিউ, এবং যা অন্য ফ্লো ট্রিগার করে। এই বিবরণগুলো পরে টিম যখন স্পেসের ওপর নির্ভর করে তখন সারপ্রাইজ আটকায়।\n\n## কম্পোনেন্ট ও UI ফ্লো থেকে আচরণ উদ্ধার করা\n\nরুটগুলো বলে অ্যাপ কী করতে পারে। কম্পোনেন্টগুলো বলে ব্যবহারকারী বাস্তবে কী অভিজ্ঞতা পায়। UI-কে চুক্তির অংশ হিসেবে বিবেচনা করুন: কী দেখায়, কী ব্লক করে, এবং সমস্যা হলে কী হয়।\n\nফিচারের এন্ট্রি স্ক্রিনগুলো খুঁজে নিয়ে শুরু করুন। পেজ কম্পোনেন্ট, লেআউট র‍্যাপার, এবং কিছু "ডিসিশন" কম্পোনেন্ট যেগুলো ফেচিং, অনুমতি এবং ন্যাভিগেশন নিয়ন্ত্রণ করে—এখানেই সাধারণত বাস্তব আচরণ থাকে।\n\nকম্পোনেন্ট পড়ার সময় এমন নিয়মগুলো ধরুন যেগুলো ব্যবহারকারী অনুভব করে: কখন অ্যাকশন ডিসেবল থাকে, বাধ্যতামূলক ধাপ, শর্তাধীন ফিল্ড, লোডিং স্টেট, এবং ত্রুটি কিভাবে দেখায় (ইনলাইন ফিল্ড এরর বনাম টোস্ট, অটো-রিট্রাই, "Try again" বাটন)। স্টেট ও কেচিং আচরণও নোট করুন যেমন stale ডেটা প্রথমে দেখানো, optimistic আপডেটে কি ঘটে, বা "last saved" টাইমস্ট্যাম্প।\n\nগোপন ফ্লো খুঁজে দেখুন যা চুপচাপ ব্যবহারকারীর দেখা বদলে দেয়—ফিচার ফ্ল্যাগ, এক্সপেরিমেন্ট বকেট, এবং অ্যাডমিন-অনলি গেট। চুপচাপ রিডিরেক্টও নোট করুন, যেমন লগআউট ব্যবহারকারীকে সাইন-ইনে পাঠানো বা অ্যাক্সেস না থাকলে আপগ্রেড স্ক্রিনে পাঠানো।\n\nকনক্রিট উদাহরণ: "ইমেল পরিবর্তন" স্ক্রিনে ডকুমেন্ট করুন যে Save বাটনটি ইমেল বৈধ না হওয়া পর্যন্ত ডিসেবল থাকে, রিকুয়েস্ট চলাকালে স্পিনার দেখায়, সফল হলে কনফার্মেশন ব্যানার দেখায়, এবং ব্যাকএন্ড ভ্যালিডেশন এরর ইনপুটের নিচে রেন্ডার করে। যদি কোডে newEmailFlow এর মতো ফ্ল্যাগ থাকে, উভয় ভ্যারিয়েন্ট নোট করুন এবং পার্থক্য কী তা লিখুন।\n\nপ্রতিটি UI ফ্লোকে সংক্ষিপ্ত ধাপে লিখুন (ব্যবহারকারী কী করে, UI কীভাবে সাড়া দেয়) এবং শর্ত ও এররগুলো সেই ধাপের পাশেই রাখুন। এতে স্পেস পড়তে সহজ থাকে এবং গ্যাপ খুঁজতে সাহায্য করে।\n\n## পর্যবেক্ষণগুলোকে পাঠযোগ্য ফিচার স্পেসে রূপান্তর করা\n\nরুট ও কম্পোনেন্ট থেকে কাঁচা নোটগুলো কাজে লাগবে, কিন্তু আলোচনার জন্য কঠিন। আপনি যা পর্যবেক্ষণ করেছেন তাrewrite করে একটি স্পেস লিখুন যাতে PM, ডিজাইনার, QA, ও ইঞ্জিনিয়ার সবাই পড়ে সম্মত হতে পারে।\n\nএকটি ব্যবহারিক ধাঁচ হলো প্রতিটি রুট বা স্ক্রিনের জন্য একটি ইউজার স্টোরি। ছোট ও নির্দিষ্ট রাখুন। উদাহরণ: "As a signed-in user, I can reset my password so I can regain access." যদি কোড রোলে ভিন্ন আচরণ দেখায় (অ্যাডমিন বনাম ইউজার), আলাদা স্টোরিতে ভাগ করুন, না হলে নোটে লুকিয়ে রাখবেন।\n\nতারপর একসেপ্টেন্স ক্রাইটেরিয়া লিখুন যা বাস্তব কোড পাথ মিরর করে, না যে আদর্শ প্রোডাক্ট হবে। যদি হ্যান্ডলার টোকেন না থাকলে 401 ফেরত দেয়, সেটা একটি ক্রাইটেরিয়ম। UI সাবমিট ডিসেবল করে যদি ফিল্ড ভ্যালিড না হয়, সেটা ক্রাইটেরিয়া।\n\nডেটা রুলগুলো সোজা ভাষায় লিখুন—বিশেষ করে যা সারপ্রাইজ সৃষ্টি করে: সীমা, অর্ডারিং, ইউনিকনেস, প্রয়োজনীয় ফিল্ড। "Usernames must be unique (checked on save)" লেখাটা "unique index" লেখার চেয়ে পরিষ্কার।\n\nএজ কেসগুলো প্রায়ই ভালো ডকুমেন্ট এবং উপযোগী ডকুমেন্টের মধ্যে পার্থক্য গঠন করে। খালি স্টেট, null ভ্যালু, রিট্রাই, টাইমআউট, এবং API কল ব্যর্থ হলে ব্যবহারকারী কী দেখে—এসব আলাদা করে তুলে ধরুন।\n\nঅজানা বিষয়গুলোতে পৌঁছালে অনুমান না করে মার্ক করুন:

POST /checkout/apply-promo

GET /checkout/shipping-options

POST /checkout/confirm

ট্যাক্স শিপিং নির্বাচন করার পরে গণনা করা হয় (প্রোমো প্রয়োগের সময় নয়)।\n\nতারপর UI কম্পোনেন্টগুলো পরীক্ষা করুন। একটি PromoCodeInput হয়ত দেখায় টোটাল কেবল সফল রেসপন্সের পরে রিফ্রেশ হয় এবং এরর ইনপুটের নীচে ইনলাইন রেন্ডার করে। একটি ShippingOptions কম্পোনেন্ট প্রথম লোডে সস্তা অপশন অটোম্যাটিক সিলেক্ট করতে পারে এবং ব্যবহারকারী পরিবর্তন করলে পুরো প্রাইস ব্রেকডাউন রিফ্রেশ ট্রিগার করে।\n\nএখন আপনার কাছে পাঠযোগ্য স্পেস এবং একটি ছোট গ্যাপস লিস্ট আছে। উদাহরণ: প্রোমো রুট এবং UI মধ্যে এরর মেসেজ ভিন্ন ("Invalid code" বনাম "Not eligible"), এবং ট্যাক্স রাউন্ডিং নিয়ম স্পষ্ট নয় (লাইন-আইটেম স্তরে vs অর্ডার টোটালে)।\n\nপরিকল্পনায়, টিম প্রথমে বাস্তবতা নিয়ে একমত হয়, তারপর কি বদলাতে হবে তা ঠিক করে। মতামতের উপর বিতর্ক না করে, আপনি ডকুমেন্ট করা আচরণ পর্যালোচনা করবেন, একটি অসঙ্গতি ঠিক করার সিদ্ধান্ত নেবেন, এবং বাকিগুলোকে "নির্দিষ্ট বর্তমান আচরণ" হিসেবে রেখে দেবেন যতক্ষণ না তা মূল্যায়ন করা হবে।\n\n## টিমের সঙ্গে স্পেস যাচাই করুন এবং আপ-টু-ডেট রাখুন\n\nস্পেস তখনই কার্যকর যখন টিম একে বাস্তবতা বলেই মানে। এক ইঞ্জিনিয়ার এবং এক প্রোডাক্ট পার্সনের সাথে সংক্ষিপ্ত রিড-থ্রু করুন। সময় সীমিত রাখুন: 20–30 মিনিট, ফোকাস থাকবে ব্যবহারকারী কী করতে পারে এবং সিস্টেম কী করে সাড়া।\n\nরিড-থ্রুতে বিবৃতিগুলোকে হ্যাঁ/না প্রশ্নে রূপান্তর করুন। "এই রুটে হিট করলে কি আমরা সেশন ছাড়া সবসময় 403 ফেরত দিই?" "এই খালি স্টেট কি ইচ্ছাকৃত?" ইত্যাদি—এটি ইচ্ছাকৃত আচরণ এবং আকস্মিক আচরণ আলাদা করে।\n\nসম্পাদনার আগে শব্দভাণ্ডারে একমত হন। UI-তে দেখা শব্দ (বাটন লেবেল, পেজ টাইটেল, এরর মেসেজ) ব্যবহার করুন; ইনটার্নাল নাম যোগ করুন কেবল তখনই যখন তা ইঞ্জিনিয়ারদের কোড খুঁজে পেতে সাহায্য করে (রুট নাম, কম্পোনেন্ট নাম)। এতে প্রতিরোধ হয় যে প্রোডাক্ট বলছে "Workspace" কিন্তু স্পেসে লেখা আছে "Org"।\n\nএটি আপ-টু-ডেট রাখার জন্য মালিকানা ও ক্যাডেন্স কড়া করে বলুন:

Storage: কোডের নিকটেই রাখুন যাতে কোডের সঙ্গে পাল্টায়\n\nKoder.ai-এর মতো টুল ব্যবহার করলে স্ন্যাপশট ও রোলব্যাক আপনাকে সাহায্য করতে পারে "আগে" এবং "পরে" আচরণ তুলনা করতে যখন আপনি স্পেস আপডেট করেন, বিশেষত বড় রিফ্যাক্টরের পরে।\n\n## সাধারণ ভুল ও ফাঁদগুলো\n\nস্পেসের উপর বিশ্বাস হারানোর দ্রুততম উপায় হলো আপনি যে প্রোডাক্ট চান তা বর্ণনা করা, না যে প্রোডাক্ট আছে। একটি কঠোর নিয়ম রাখুন: প্রতিটি বিবৃতি এমন কোন কিছুর দ্বারা সমর্থিত হওয়া উচিত যা আপনি কোড বা বাস্তব স্ক্রিনে দেখাতে পারেন।\n\nআরেকটি সাধারণ ফাঁদ হলো কোডের আকৃতি ডকুমেন্টে কপি করা। একটি স্পেস যদি পড়ে "Controller -> Service -> Repository" সেটি স্পেস নয়—এটি ফোল্ডার ম্যাপ। ব্যবহারকারী-ফেসিং ভাষায় লিখুন: কী ট্রিগার করে, ব্যবহারকারী কী দেখে, কী সংরক্ষিত হয়, এবং ত্রুটিগুলো কেমন।\n\nঅনুমতি ও রোলগুলো প্রায়ই শেষে বাদ পড়ে, তারপর সবকিছু ভেঙে যায়। শুরুর দিকে অ্যাকসেস নিয়ম যোগ করুন, যদিও সেগুলো বাঁধাকপি মনে হয়। কোন রোল কি দেখতে পারে, তৈরি/সম্পাদনা/মুছতে পারে বা অনুমোদন করতে পারে তা উল্লেখ করুন এবং নিয়ম কোথায় এনফোর্স (UI-এ কেবল, API-এ কেবল, বা উভয়) তা লিখুন।\n\nনন-হ্যাপি পাথ বাদ দেবেন না। বাস্তব আচরণ রিট্রাই, আংশিক ব্যর্থতা, এবং সময়-ভিত্তিক নিয়ম যেমন মেয়াদ, কুলডাউন, শিডিউলড জব বা "প্রতি দিন একবার" সীমা ইত্যাদির মধ্যে লুকিয়ে থাকে। এগুলোকে প্রথম-শ্রেণীর আচরণ হিসেবে বিবেচনা করুন।\n\nগ্যাপনুমোদন সহজে শনাক্ত করতে দেখুন:

Language: ব্যবহারকারী-ফেসিং টার্ম প্রথমে ব্যবহার করুন; অবশ্যম্ভাবী জার্গন একবারে সংজ্ঞায়িত করুন।\n\n### সহায়ক গ্যাপস, নয় গড়আলোচনার পয়েন্টস \nপ্রতিটি গ্যাপ নির্দিষ্ট এবং টেস্টেবল হওয়া উচিত। সাধারণ "এরর হ্যান্ডলিং অস্পষ্ট" লেখার বদলে লিখুন: "Payment provider 402 রিটার্ন করলে UI-তে generic toast দেখায়; চায় কি আমরা একটি নির্দিষ্ট মেসেজ দেখাব ও রিট্রাই কিভাবে হবে—নিশ্চিত করুন এবং একশন দিন।" একটি একক পরবর্তী কাজ (প্রোডাক্টকে জিজ্ঞাসা, টেস্ট যোগ করা, লগ ইনস্পেক্ট করা) যোগ করুন এবং কে উত্তর দেবে তা নোট করুন।\n\n## এই সপ্তাহে শুরু করার পরবর্তী ধাপগুলো\n\nএকটি ফিচার এলাকা বেছে নিন এবং 60 মিনিট টাইমবক্স দিন। ছোট কিন্তু বাস্তব কিছু নিন (লগইন, চেকআউট, সার্চ, একটি অ্যাডমিন স্ক্রিন)। একটি বাক্যে স্কোপ লিখুন: কী অন্তর্ভুক্ত এবং কী বাইরে।\n\nওয়ার্কফ্লো একবার সম্পূর্ণ করুন: মূল routes/handlers স্কিম পড়ুন, প্রধান UI ফ্লো ট্রেস করুন, এবং পর্যবেক্ষণযোগ্য আচরণ লিখে ফেলুন (ইনপুট, আউটপুট, ভ্যালিডেশন, এরর স্টেট)। আটকে গেলে প্রশ্ন গ্যাপ হিসেবে লগ করুন এবং সামনে বাড়ুন।\n\nশেষ হলে স্পেসটি টিমে শেয়ার করুন যাতে মন্তব্য করা যায়, এবং একটি নিয়ম ঠিক করুন: যে কোনও শিপ করা আচরণ পরিবর্তন একই ডেলিভারি উইন্ডোতে স্পেস আপডেট করবে, এমনকি যদি সেটা পাঁচ লাইনের পরিবর্তনই হোক।\n\nগ্যাপস আলাদা রাখুন ব্যাকলগ থেকে। সেগুলোকে গ্রুপ করুন: "unknown behavior," "inconsistent behavior," এবং "missing tests," এবং সাপ্তাহিক হালকা রিভিউ করে সিদ্ধান্ত নিন যা এখনই জরুরি।\n\nযদি ড্রাফট ও ইটারেশন ধীর হয়, চ্যাট-ভিত্তিক বিল্ডার যেমন Koder.ai আপনাকে দ্রুত প্রথম ভার্সন বের করতে সাহায্য করতে পারে। ফিচার বর্ণনা করুন, প্রধান স্নিপেট বা রুট পেস্ট করুন, কথোপকথনে ভাষা পরিশোধন করুন, এবং দরকার হলে সোর্স এক্সপোর্ট করুন। মূল উদ্দেশ্য গতি এবং যৌথ স্পষ্টতা—বড় প্রসেস নয়।

Claude Code থেকে ফিচার স্পেস: একটি সহজ ওয়ার্কফ্লো | Koder.ai