০২ ডিসে, ২০২৫·7 মিনিট
Claude Code থেকে ফিচার স্পেস: একটি সহজ ওয়ার্কফ্লো
রুট ও কম্পোনেন্ট থেকে বাস্তব অ্যাপ আচরণ বের করে একটি লাইভিং স্পেস ও গ্যাপস লিস্ট কীভাবে তৈরি করবেন—তায় কী দেখানো উচিত এবং টিম কীভাবে ঐক্যমত হবে তা শিখুন।
কেন আপনার কোডের সাথে মিল থাকা স্পেস দরকার\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 আলাদা রাখুন এবং নিয়মিত সংক্ষিপ্তভাবে রিভিউ করুন
লক্ষ্য: বড় রিরাইট নয়—ছোট, ঘন আপডেট।