Claude Code কোডবেস অনবোর্ডিং: আপনার অ্যাপ ম্যাপ করার প্রম্পট

আপনি কী জানার চেষ্টা করছেন (এবং কী পরে করা যায়)

ফাইলগুলো এলোমেলোভাবে পড়া ধীর অনুভব হয় কারণ বেশিরভাগ কোডবেস গল্পের মতো সাজানো থাকে না। আপনি একটি ফোল্ডার খুলেন, দশটা নাম দেখতে পান যা গুরুত্বপূর্ণ মনে হয়, একটি ক্লিক করেন, এবং সাহায্যকারী, কনফিগ, ও এজ কেসে পৌঁছান। এক ঘন্টার পর, আপনার কাছে অনেক বিবরণ থাকে কিন্তু আপনি এখনও অ্যাপ কিভাবে কাজ করে সেটা ব্যাখ্যা করতে পারছেন না।

Claude Code দিয়ে অনবোর্ডিংয়ের জন্য একটি ভাল লক্ষ্য হল একটি সহজ মানসিক মানচিত্র তৈরি করা। সেই মানচিত্র তিনটি প্রশ্নের উত্তর দেয়া উচিত:

• প্রধান মডিউলগুলো কী?
• ব্যবহারকারীরা ট্রিগার করে এমন মূল ফ্লোগুলো কী কী?
• কোনগুলো ঝুঁকিপূর্ণ এলাকা যা প্রোডাকশন ভেঙে দিতে পারে বা বাগ ঘটাতে পারে?

1-2 দিনের মধ্যে "গুড এনাফ" অনবোর্ডিং মানে নয় "আমি প্রতিটি ক্লাস ব্যাখ্যা করতে পারি।" বরঞ্চ এর কাছাকাছি হওয়া উচিত:

• আপনি 5–8 টি গুরুত্বপূর্ণ মডিউলের নাম বলতে পারবেন এবং প্রতিটি কী পরিচালনা করে।
• আপনি 2–3 টি বাস্তব ইউজার ফ্লো এন্ড-টু-এন্ড ট্রেস করতে পারবেন (UI বা API এন্ট্রি থেকে DB এবং ফিরে)।
• আপনি শীর্ষ ঝুঁকি জানেন (payments, auth, data writes, background jobs) এবং তারা কোথায় আছে।
• আপনি নিরাপদে একটি ছোট পরিবর্তন করতে পারবেন কারণ আপনি জানেন কী পরীক্ষা করতে হবে এবং কাকে জিজ্ঞেস করতে হবে।

কিছু জিনিস পরে করা যায়। গভীর রিফ্যাক্টর, প্রতিটি অ্যাবস্ট্রাকশনের নিখুঁত বোঝাপড়া, এবং কেউ না পড়া পুরনো কোড আশা অনুযায়ী দ্রুত কাজ দেয় না।

অনবোর্ডিংকে একটি মানচিত্র তৈরি হিসেবে ভাবুন, রাস্তাগুলো মুখস্থ করার মতো নয়। আপনার প্রম্পটগুলোকে বারবার ফিরে আনতে হবে: "আমি সিস্টেমের কোথায় আছি, পরের কী হয়, এবং এখানে কী খারাপ হতে পারে?" একবার আপনার কাছে সেটা থাকলে, বিস্তারিত অন-ডিমান্ডে শেখা সহজ হয়ে যায়।

প্রস্তুতি: সমগ্রটা না করে প্রাসঙ্গিক প্রেক্ষাপট নিন

প্রশ্ন করা শুরু করার আগে, সাধারণত প্রথম দিনে যা যা দরকার তা সংগ্রহ করুন। Claude Code তখনই সবচেয়ে ভাল কাজ করে যখন এটি আসল ফাইল, আসল কনফিগ, এবং আপনি পুনরায় চালাতে পারা আচরণে প্রতিক্রিয়া দেখাতে পারে।

শুরু করুন অ্যাক্সেস এবং একটি কাজ করা রান দিয়ে। নিশ্চিত করুন আপনি রেপো ক্লোন করতে পারেন, ডিপেন্ডেন্সি ইনস্টল করতে পারেন, এবং লোকালি অ্যাপ চালাতে পারেন (বা অন্তত একটি ছোট অংশ)। লোকালি সেটআপ কঠিন হলে, স্টেজিং পরিবেশ এবং যেখানে লগ থাকে সেখানে অ্যাক্সেস নিন, যাতে আপনি যাচাই করতে পারেন কোড আসলে কী করে।

পরের ধাপে, "সোর্স অব ট্রুথ" ডকস খুঁজে বের করুন। আপনি যা খুঁজছেন তা হলো দল বদলালে যেটি তারা আসলেই আপডেট করে: README, সংক্ষিপ্ত আর্কিটেকচার নোট, ADR ফোল্ডার, runbook, বা deployment নোট। এগুলো ময়লা হলেও, তারা মডিউল ও ফ্লোদের নাম দেয়, যা Q&A-কে অনেক বেশি স্পষ্ট করে তোলে।

শুরুতে স্কোপ নির্ধারণ করুন। অনেক রেপোতে একাধিক অ্যাপ, সার্ভিস, এবং শেয়ার করা প্যাকেজ থাকে। সীমানা নির্ধারণ করুন যেমন "শুধু API এবং billing worker" বা "শুধু ওয়েব অ্যাপ এবং তার auth ফ্লো।" স্পষ্ট স্কোপ অনন্ত বিচ্যুতি রোধ করে।

অ্যাসিস্ট্যান্টকে যা অনুমান করতে দেবেন না সেই অনুমানগুলো লিখে রাখুন। এটা ছোট মনে হলেও পরে ভুল মানসিক মডেল থেকে ঘণ্টা পড়ে যাবে।

এখানে একটি সহজ প্রস্তুতি চেকলিস্ট:

• রেপো অ্যাক্সেস, প্রয়োজনীয় পারমিশন, এবং টেস্ট চালানোর উপায় নিশ্চিত করুন।
• এনভায়রনমেন্ট সেটআপ নোটসমূহ সংগ্রহ করুন (env vars, seeds, feature flags) এবং কোথায় লগ ও মেট্রিক্স দেখা হয় তা নোট করুন।
• বর্তমান ট্রুথ ফাইলগুলো চিহ্নিত করুন (README, আর্কিটেকচার নোট, ADRs, runbooks)।
• অনবোর্ডিং পাসের জন্য কী অন্তর্ভুক্ত এবং স্পষ্টভাবে আউট-অফ-স্কোপ তা নির্ধারণ করুন।
• সেফটি রুল সেট করুন: কখনোই সিক্রেট, API কী, টোকেন, প্রাইভেট ক্রেতার ডেটা, বা সংবেদনশীল ডিটেইল সহ প্রোডাকশন লগ পেস্ট করবেন না।

যদি কিছু অনুপস্থিত থাকে, সেটাকে টিমমেটের কাছে একটি প্রশ্ন হিসেবে ধরুন। অনুপস্থিত প্রেক্ষাপটকে অনুমান করে "ওয়ার্ক অ্যারাউন্ড" করবেন না।

মানসিক মানচিত্র: অনুসন্ধান করার সময় কী ধরা উচিত

একটি মানসিক মানচিত্র হলো এমন কিছু নোট যা উত্তর দেয়: এই অ্যাপের মূল অংশগুলো কী, তারা কিভাবে একে অপরের সাথে কথা বলে, এবং কোথায় সমস্যা হতে পারে। ভালভাবে করা হলে, অনবোর্ডিং ফাইল ব্রাউজ করা নয় বরং একটি পুনরায় ব্যবহারযোগ্য ছবি তৈরি করা হয়ে যায়।

শুরু করুন আপনার আউটপুট নির্ধারণ করে। আপনি একটি মডিউল তালিকা চাইবেন যা ব্যবহারিক, নিখুঁত নয়। প্রতিটি মডিউলের জন্য ধরুন এটি কী করে, কে এটাকে ধরে (টিম বা ব্যক্তি যদি জানেন), এবং এর মূল ডিপেন্ডেন্সি কী (অন্যান্য মডিউল, সার্ভিস, ডাটাবেস, এক্সটার্নাল APIs)। এছাড়া প্রধান এন্ট্রি পয়েন্টগুলো নোট করুন: UI routes, API endpoints, ব্যাকগ্রাউন্ড জব, এবং শিডিউলেড টাস্ক।

পরের ধাপে, কয়েকটি ইউজার জার্নি বেছে নিন যা গুরুত্বপূর্ণ। তিন থেকে পাঁচটি যথেষ্ট। এমন ফ্লো বেছে নিন যা অর্থ, পারমিশন, বা ডাটা পরিবর্তনকে স্পর্শ করে। উদাহরণ: সাইনআপ ও ইমেইল ভেরিফিকেশন, পেইড প্ল্যান বা পারচেজ তৈরি করা, এমন একটি অ্যাডমিন অ্যাকশন যা ইউজার এক্সেস বদলে দেয়, এবং একটি ক্রিটিকাল ডেইলি-ইউজ ফ্লো যা বেশিরভাগ ব্যবহারকারী নির্ভর করে।

শুরু করার আগে ঝুঁকি কীভাবে লেবেল করবেন তা নির্ধারণ করুন। ক্যাটাগরিগুলো সহজ রাখুন যাতে পরে স্ক্যান করা যায়। একটি উপযোগী সেট হলো security, data integrity, uptime, এবং cost। যখন আপনি কিছু ঝুঁকিপূর্ণ হিসাবে চিহ্নিত করবেন, এক বাক্যে লিখে রাখুন কেন, প্লাস কী প্রমাণ করবে সেটা নিরাপদ (একটি টেস্ট, একটি লগ, একটি পারমিশন চেক)।

নোটগুলো একটি সঙ্গত ফরম্যাটে রাখুন যাতে আপনি তা অনবোর্ডিং ডকে রূপান্তর করতে পারেন পুনরায় লেখার দরকার ছাড়াই:

• Modules: purpose, entry points, dependencies, owner
• Key flows: trigger, steps, data written, failure points
• Data: টেবিল বা কালেকশন টাচ করা হয়, গুরুত্বপূর্ণ ফিল্ড, কনস্ট্রেনট
• Risks: ক্যাটাগরি, খারাপ-কেস ইফেক্ট, কীভাবে মনিটর করবেন, কীভাবে রোলব্যাক করবেন
• Open questions: আপনি এখনও যা জানেন না, কাদের জিজ্ঞেস করবেন

উদাহরণ: যদি Checkout Billing কল করে যা payments এবং invoices-এ লেখে, সেটিকে data integrity এবং cost হিসেবে ট্যাগ করুন। তারপর নোট করুন কোথায় রিট্রাই ঘটে এবং কী ডাবল-চার্জিং রোধ করে।

ধাপে ধাপে Q&A প্রম্পটগুলো কোডবেস অন্বেষণের জন্য

আপনি যখন একটি নতুন রেপোতে যোগ দেন, দ্রুত অভিভাবন চাইবেন, নিখুঁত বোঝাপড়া নয়। এই প্রম্পটগুলো আপনাকে ছোট, নিরাপদ ধাপে মানসিক মানচিত্র তৈরি করতে সাহায্য করবে।

শুরুতে অ্যাসিস্ট্যান্টকে রেপো ট্রি দিন (অথবা পেস্ট করা একটি সাবসেট) এবং একটি ট্যুর চাইুন। প্রতিটি রাউন্ডকে ফোকাসড রাখুন, তারপর শেষ করুন একটি প্রশ্ন দিয়ে যা বলে যে আপনাকে পরের কোনটি পড়তে হবে।

1) Repo tour
"Here is the top-level folder list: <paste>. Explain what each folder likely contains and which ones matter for core product behavior."

2) Entry points
"Find the app entry points and boot process. What files start the app, set up routing, configure DI/env, and start background jobs? Name the exact files and what they do."

3) Module index
"Create a module index: module name, purpose, key files, and important external dependencies. Keep it to the modules that affect user-facing behavior."

4) Data model hints
"Based on migrations/models, list the key tables/entities, critical fields, and relationships. Call out fields that look security-sensitive or used for billing/permissions."

5) Flow trace
"Trace this flow end-to-end: <flow>. Where does the request/event start, where does it end, and what does it call in between? List the main functions/files in order."

6) Next inspection
"What should I inspect next and why? Give me 3 options: fastest clarity, riskiest area, and best long-term payoff."

একটি কংক্রিট উদাহরণ: যদি আপনি "user signs up and creates their first project" ম্যাপ করছেন, হ্যান্ডলার, ভ্যালিডেশন, DB write, এবং কোনো async জব যা ইমেইল পাঠায় বা রিসোর্স প্রোভিশন করে সেগুলো জিজ্ঞেস করুন। তারপর আবার সেই ফ্লো ট্রেস চালিয়ে "user deletes project" ম্যাপ করুন যাতে ক্লিনআপ গ্যাপ খুঁজে পাওয়া যায়।

উত্তরগুলো কার্যকর রাখার জন্য, নির্দিষ্ট আর্টিফ্যাক্ট চাইুন, কেবল সারাংশ নয়:

• ফাইল পাথ এবং ফাংশন নাম
• অনুমান এবং অজানা স্পষ্টভাবে উল্লেখ
• ডিপেন্ডেন্সিগুলো এমনভাবে বর্ণনা করুন: "If I change X, what breaks?"
• পরবর্তী 10 মিনিটে আপনি যা পড়তে পারেন সেই ছোট টাস্ক

উত্তরগুলো কিভাবে ধরে রাখবেন যাতে সেগুলো আবার কাজে লাগে

সবচেয়ে বড় অনবোর্ডিং জয় হলো ছড়িয়ে থাকা Q&A-কে এমন নোটে পরিণত করা যা অন্য ডেভেলপারও ব্যবহার করতে পারে। যদি নোটগুলো কেবল আপনার জন্য অর্থপূর্ণ হয়, আপনি পরে একই খোঁজ আবার করবেন।

একটি সহজ কাঠামো লম্বা পৃষ্ঠার চেয়ে ভাল। প্রতিটি এক্সপ্লোরেশন সেশনের পরে উত্তরগুলো পাঁচটি ছোট আর্টিফ্যাক্টে সেভ করুন (একটি ফাইল বা ডক হতে পারে): একটি মডিউল টেবিল, একটি গ্লসারি, কী ফ্লো, অজানাগুলো, এবং একটি রিস্ক রেজিস্টার।

এখানে একটি কম্প্যাক্ট টেমপ্লেট আছে যা আপনি আপনার নোটে পেস্ট করে ধাপে ধাপে পূরণ করতে পারেন:

Module table
- Module:
  Owns:
  Touches:
  Entry points:

Glossary
- Term:
  Meaning:
  Code name(s):

Key flow (name)
1.
2.
3.

Unknowns
- Question:
  Best person to ask:
  Where to look next:

Risk register
- Risk:
  Location:
  Why it matters:
  How to verify:

কী ফ্লোগুলো ইচ্ছাকৃতভাবে সংক্ষিপ্ত রাখুন। উদাহরণ: 1) user signs in, 2) backend creates a session, 3) client loads the dashboard, 4) API fetches data, 5) UI renders and handles errors. যদি আপনি কোনো ফ্লোকে পাঁচ ধাপে ফিট করতে না পারেন, সেটাকে ভাগ করে নিন (login বনাম dashboard load)।

Claude Code ব্যবহার করার সময় প্রতিটি উত্তরের শেষে একটি লাইন যোগ করুন: "How would I test this?" সেই এক লাইনে প্যাসিভ নোটগুলোকে একটি চালানোযোগ্য চেকলিস্টে পরিণত করে, বিশেষ করে যখন অজানা এবং ঝুঁকি ওভারল্যাপ করে।

আপনি যদি Koder.ai-এর মত vibe-coding প্ল্যাটফর্মে নির্মাণ করেন, এই ধরনের নোট-নেইকিং আপনাকে দেখতে সাহায্য করবে কোথায় জেনারেট করা পরিবর্তনগুলির সাইড-ইফেক্ট হতে পারে। প্রচুর টাচপয়েন্ট থাকা মডিউলগুলো সাধারণত পরিবর্তনের জন্য আকর্ষণীয় হয়।

ঝুঁকিপূর্ণ এলাকাগুলো দ্রুত খুঁজে পাওয়া (প্রতি ফাইল না পড়েই)

একটি কোডবেসে ঝুঁকি দুর্লভভাবে এলোমেলো নয়। এটি সেখানে গুচ্ছ হয় যেখানে অ্যাপ সিদ্ধান্ত নেয় কে তুমি, ডাটা পরিবর্তন করে, অন্যান্য সিস্টেমের সাথে কথা বলে, বা ব্যাকগ্রাউন্ডে কাজ চালায়। আপনি টার্গেটেড প্রশ্ন ও কয়েকটি ফোকাসড সার্চ দিয়ে এগুলো বেশিরভাগ পেয়ে যেতে পারেন।

পরিচয় (identity) থেকে শুরু করুন। জিজ্ঞেস করুন authentication কোথায় ঘটে (login, session, tokens) এবং authorization সিদ্ধান্ত কোথায় থাকে (role checks, feature flags, ownership rules)। একটি সাধারণ ফাঁদ হলো চেকগুলো UI, API হ্যান্ডলার, এবং ডাটাবেস কুয়েরিগুলোতে ছড়িয়ে থাকা যেখানে কোনো একক সোর্স অব ট্রুথ নেই।

পরেরটি, write paths মানচিত্র করুন। এন্ডপয়েন্ট বা ফাংশন খুঁজে বের করুন যা রেকর্ড তৈরি, আপডেট, বা ডিলিট করে, প্লাস সেই মাইগ্রেশনগুলো যা সময়ে সময়ে ডাটা রিফর্ম করে। ব্যাকগ্রাউন্ড জবগুলোও অন্তর্ভুক্ত করুন। অনেক রহস্যজনক বাগ আসে এসিঙ্ক ওয়ার্কারদের কারণে যারা অনুরোধ শেষ হওয়ার অনেক পরে অপ্রত্যাশিত মান লেখে।

তারপর ঝুঁকি দ্রুত উন্মোচনের জন্য প্রম্পটগুলোঃ

• "List every place that enforces permissions for [resource X]. Which one is the final gate?"
• "Show the full path for writing [table/entity X]: API handler -> service -> DB call. Where are validations?"
• "What external integrations exist (payments, email, webhooks, third-party APIs)? Where are retries and timeouts set?"
• "Where can work run twice (queues, goroutines, cron)? What makes it idempotent?"
• "What can break silently, and how would we notice (logs, metrics, alerts, dashboards)?"

তারপর কনফিগ ও সিক্রেট হ্যান্ডলিং চেক করুন। এনভায়রনমেন্ট ভ্যারিয়েবল, রানটাইম কনফিগ ফাইল, এবং ডিফল্ট ফ্যালব্যাক খুঁজুন। ডিফল্টগুলো কাজে লাগে, কিন্তু বিপজ্জনক যখন তারা কনফিগ মিসিং হলে ভুল কী ব্যবহার করে (উদাহরণ: প্রোডাকশনে dev key ব্যবহার করা)।

একটি দ্রুত উদাহরণ: একটি Go ব্যাকএন্ড যেখানে PostgreSQL আছে, আপনি একটি "send email" জব পেতে পারেন যা ব্যর্থ হলে রিট্রাই করে। যদি এটি idempotency key ছাড়া রিট্রাই করে, ব্যবহারকারীরা ডুপ্লিকেট ইমেইল পেতে পারে। যদি ব্যর্থতাগুলো কেবল একটি ওয়ার্নিং লগ করে এবং কোনো অ্যালার্ট না থাকে, তাহলে এটা চুপচাপ ভেঙে যায়। এটা একটি উচ্চ-ঝুঁকিপূর্ণ এলাকা যা প্রথমেই ডকুমেন্ট করা উচিত এবং পরীক্ষা করা দরকার।

উদাহরণ ওয়াকথ্রূ: একটি বাস্তব ইউজার ফ্লো ম্যাপ করা

একটি বাস্তব ফ্লো ব্যবহার করুন আপনার প্রথম এন্ড-টু-এন্ড থ্রেড তৈরি করতে। Login শুরু করার জন্য একটি ভাল স্টার্ট কারণ এটি routing, validation, sessions বা tokens, এবং ডাটাবেস রিড টাচ করে। আপনার লক্ষ্য প্রতিটি ফাইল বোঝা নয়। লক্ষ্য হলো: "যখন একটি ব্যবহারকারী Login ক্লিক করে, পরের কোন কোড চলে, কোন ডেটা চলে, এবং কী ভেঙে যেতে পারে?" এটা অনবোর্ডিংকে কংক্রিট রাখে।

ব্রাউজার থেকে ডাটাবেস পর্যন্ত ফ্লো ম্যাপ করুন

UI থেকে শুরু করে একটি হপ করে এগিয়ে যান। নির্দিষ্ট ফাইল নাম, ফাংশন, রিকোয়েস্ট ও রেসপন্স শেপ জিজ্ঞেস করুন।

• "Find the React route or page for the login screen. What component renders it, and what action fires on submit?"
• "Where is the API client call made (fetch/axios/etc.)? What exact URL path, method, headers, and body does it send?"
• "On the Go side, where is the handler for that path registered? Show the router setup and the handler function."
• "Inside the handler, where does input validation happen (frontend, backend, both)? What rules exist, and where do errors get formatted?"
• "What database query runs for login? Point to the repository/SQL file, list touched tables/columns, and note any transactions or locks."

প্রতিটি উত্তর পর আপনি আপনার মানসিক মানচিত্রে এক লাইন লিখুন: "UI component -> API endpoint -> handler -> service -> DB query -> response." নামগুলো অন্তর্ভুক্ত করুন, কেবল "কিছু ফাংশন" নয়।

দ্রুত রান করে নিশ্চিত করুন

একবার আপনার কাছে পাথ থাকলে, একটি ছোট টেস্ট রান করে যাচাই করুন। আপনি পরীক্ষা করবেন যে আপনি ম্যাপ করা কোড পাথই অ্যাপ আসলে ব্যবহার করে কিনা।

ব্রাউজারের dev tools-এ নেটওয়ার্ক অনুরোধ দেখুন (path, status code, response body)। হ্যান্ডলার ও DB কলের চারপাশে অস্থায়ী লগ যোগ করুন (request ID থাকলে)। PostgreSQL-এ প্রত্যাশিত পরিবর্তনগুলি কুয়েরি করুন (login-এর জন্য সম্ভবত last_login_at, sessions, বা audit rows)। একটি ব্যর্থতা জোর করে দেখান (ভুল পাসওয়ার্ড, অনুপস্থিত ফিল্ড) এবং নোট করুন যেখানে ত্রুটির বার্তা তৈরি হয় এবং কোথায় দেখানো হয়। সফল এবং ব্যর্থতার জন্য প্রত্যাশিত রেসপন্স (status codes এবং কী ফিল্ড) রেকর্ড করুন, যাতে পরবর্তী ডেভ দ্রুত স্যানিটি-চেক করতে পারে।

এই এক ফ্লো প্রায়শই ওয়েব মালিকানা সীমানা প্রকাশ করে: UI কী বিশ্বাস করে, API কী প্রয়োগ করে, এবং কোথায় ত্রুটি মুছে যায় বা ডবল-হ্যান্ডেল করা হয়।

মানসিক মানচিত্রকে একটি সংক্ষিপ্ত অনবোর্ডিং ডকে রূপান্তর করা

একবার আপনার কাছে একটি ভাল মানসিক মানচিত্র থাকলে, এটিকে 1-2 পৃষ্ঠার নোটে স্থির করুন। লক্ষ্য সম্পূর্ণ হওয়া নয়। লক্ষ্য হলো পরবর্তী ডেভেলপার জানতে পারেন: এই অ্যাপটি কী, প্রথমে কোথায় তাকাব, এবং সবচেয়ে সম্ভবত কী ভাঙবে।

আপনি যদি Claude Code ব্যবহার করেন, ডকটি আপনার Q&A-এর আউটপুট হিসেবে বিবেচনা করুন: পরিষ্কার, কংক্রিট, এবং দ্রুত স্ক্যানযোগ্য।

একটি সহজ 1-2 পৃষ্ঠা কাঠামো

ডকটি পূর্বানুমেয় রাখুন যাতে লোক দ্রুত খুঁজে পায়। একটি ভালো কাঠামো:

• Purpose: অ্যাপটি কী করে, কে এটি ব্যবহার করে, এবং "ডান" হওয়ার মানে কী
• Architecture summary: প্রধান সার্ভিস, ডাটা স্টোর, এবং কীভাবে অনুরোধ সিস্টেমের মধ্য দিয়ে যায়
• How to run: প্রাকশর্ত, একটি কমান্ডে শুরু করার উপায়, এবং একটি কমান্ডে টেস্ট চালানোর উপায়
• Where things live: যে ফোল্ডারগুলো গুরুত্বপূর্ণ, এবং 5–10 টি ফাইল যেগুলো এন্ট্রি পয়েন্ট হিসেবে কাজ করে
• Key flows and risks: গুরুত্বপূর্ণ জার্নিগুলোর সংক্ষিপ্ত ট্রেস এবং পরিবর্তনের পরে কী যাচাই করতে হবে

একশনেবল রাখুন, অ্যাকাডেমিক নয়

"Where things live"-এ দেখান যেমন "Auth শুরু হয় X-এ, session logic Y-তে, UI routes Z-এ।" পুরো ট্রি ডাম্প করবেন না। কেবল যে জিনিসগুলো মানুষ স্পর্শ করবে সেগুলো বেছে নিন।

"Key flows"-এর জন্য 4–7 ধাপ প্রতিটি লিখুন: ট্রিগার, কন্ট্রোলার বা হ্যান্ডলার, মূল মডিউল, ডাটাবেস কল, ও বাহ্যিক প্রভাব (ইমেইল পাঠানো, স্টেট আপডেট, জব কিউ করা)। প্রতিটি ধাপে ফাইল নাম যোগ করুন।

"Risky areas"-এ ব্যর্থতার মোড ও দ্রুত সেফটি চেক (একটি নির্দিষ্ট টেস্ট, একটি স্মোক রান, বা দেখা লোক) নাম দিন।

শেষে একটি ছোট ফার্স্ট-টাস্ক লিস্ট দিন যাতে কেউ নিরাপদে অবদান রাখতে পারে:

• একটি কপি টুইক বা ভ্যালিডেশন রুল আপডেট করুন একটি ভালোভাবে আলাদা করা স্ক্রিনে
• একটি জটিল হেল্পারের চারপাশে একটি ছোট ইউনিট টেস্ট যোগ করুন
• একটি নিম্ন-ঝুঁকিপূর্ণ বাগ ফিক্স করুন যার একটি পরিষ্কার রিপ্রো ও প্রত্যাশিত ফল আছে
• একটি গার্ড্রেইল যোগ করুন: উন্নত ত্রুটি বার্তা, ইনপুট চেক, বা টাইমআউট
• প্রোডাকশন ডেপ্লয়ের মালিক কে তা জিজ্ঞেস করুন এবং ডোমেইন প্রশ্নের জন্য কাকে পিং করতে হবে

সাধারণ ভুল এবং সেগুলো কিভাবে এড়াবেন

অ্যাসিস্ট্যান্টকে বেস্টভাবে ব্যবহার করার দ্রুত পথ নষ্ট করার দ্রুত উপায় হলো " পুরো রেপো ব্যাখ্যা করুন" ধাঁচে অনুরোধ করা। আপনি একটি দীর্ঘ সারাংশ পাবেন যা আত্মবিশ্বাসী শোনায় কিন্তু অস্পষ্ট থাকে। পরিবর্তে একটি ছোট স্লাইস বেছে নিন যা গুরুত্বপূর্ণ (একটি মডিউল + একটি ইউজার ফ্লো), তারপর বাইরে সম্প্রসারিত করুন।

দ্বিতীয় একটি ত্রুটি হলো কোন পথে আপনার আগ্রহ তা না বলা। যদি আপনি বলেন না "checkout," "login," বা "admin edit," উত্তরগুলো জেনেরিক আর্কিটেকচার কথায় ভেসে যাবে। প্রতিটি সেশনের শুরুতেই একটি কংক্রিট লক্ষ্য দিন: "Help me understand the signup flow end to end, including validation, error states, and where data is stored."

আরেকটি সাধারণ ফাঁদ হলো অ্যাসিস্ট্যান্টকে অনুমান করতে দেওয়া। যখন কিছু অস্পষ্ট থাকে, তাকে স্পষ্টভাবে অনিশ্চয়তা লেবেল করতে বলুন। কোড প্রমাণিত কি না এবং কী অনুমান সে আলাদা করে জানানো উচিত।

অজানাগুলো দৃশ্যমান রাখুন (যাতে আপনি সেগুলো সমাধান করতে পারেন)

নোটে একটি সহজ নিয়ম ব্যবহার করুন: প্রতিটি দাবিকে একটি এটার মধ্যে ট্যাগ দিন:

• Confirmed in code
• Confirmed by running the app
• Assumption (needs check)
• Unknown (missing context)

নোটগুলো তখনই ভেঙে যায় যখন সেগুলো বিন্যাসহীনভাবে সংগ্রহ করা হয়। একটি ধারাবাহিক টেমপ্লেট রাখুন: জড়িত মডিউল, এন্ট্রি পয়েন্ট, মূল ফাংশন ও ফাইল, টাচ করা ডাটা, সাইড-এফেক্ট, এরর পাথ, এবং চালাতে থাকা টেস্ট।

আউটপুটগুলোকে ফ্যাক্ট হিসেবে বিবেচনা করবেন না

Claude Code থাকলেও আউটপুটকে খসড়া মনে করুন। মূল ফ্লোগুলো চালিয়ে যাচাই করুন, বিশেষ করে সেই অংশগুলো যা প্রোডাকশন ভাঙতে পারে: auth, payments, permissions, background jobs, এবং migrations।

একটি বাস্তবিক উদাহরণ: যদি অ্যাসিস্ট্যান্ট বলে "password reset sends an email via X," সেটি ডেভ এনভায়রনমেন্টে ট্রিগার করে লগ বা ইমেইল স্যান্ডবক্স দেখে নিশ্চিত করুন। সেই বাস্তব-চেক আপনাকে এমন একটি গল্পে অনবোর্ড হওয়া থেকে রোধ করে যা সত্য নয়।

"আমি অনবোর্ডেড" বলার আগে একটি দ্রুত চেকলিস্ট

আপনাকে রেপো মুখস্থ করার দরকার নেই। আপনাকে যথেষ্ট আত্মবিশ্বাস দরকার যাতে আপনি একটি নিরাপদ পরিবর্তন করতে পারেন, একটি বাস্তব ইস্যু ডিবাগ করতে পারেন, এবং সিস্টেমটি পরবর্তী ব্যক্তিকে ব্যাখ্যা করতে পারেন।

নিজেকে অনবোর্ডেড বলতে পারার আগে নিশ্চিত করুন যে আপনি এগুলো অনুমান ছাড়া উত্তর দিতে পারেন:

• আপনি কি পাঁচটি সবচেয়ে গুরুত্বপূর্ণ কোড এরিয়া ও তাদের মালিকানা (উদাহরণ: UI, API লেয়ার, ব্যাকগ্রাউন্ড জব, ডাটা অ্যাকসেস, ইন্টিগ্রেশন) ব্যাখ্যা করতে পারেন?
• আপনি কি দুটি উচ্চ-মূল্যের ইউজার জার্নি এন্ড-টু-এন্ড চালিয়ে প্রথম ফাইল বা ফাংশন নির্দেশ করতে পারেন?
• আপনি কি বলতে পারেন কোথায় authentication প্রয়োগ হয়, এবং কোথায় roles বা permissions ডিফাইন ও চেক করা হয়?
• আপনি কি সবচেয়ে ঝুঁকিপূর্ণ ডাটাবেস রাইটগুলো (টাকা, permissions, deletion, state transitions) নাম দিতে পারবেন, এবং প্রতিটি পরিবর্তন কিভাবে নিরাপদে পরীক্ষা করবেন তা বর্ণনা করতে পারবেন?
• আপনি কি একটি নতুন ডেভেলপারকে একটি সংক্ষিপ্ত অনবোর্ডিং নোট দিতে পারবেন যা তারা 10 মিনিটে পড়ে কোথা থেকে শুরু করবে তা জানতে পারে?

যদি একটি আইটেম অনুপস্থিত থাকে, একটি ছোট ফোকাসড পাস করুন বদলে একটি বিস্তৃত সার্চ করার। একটি ফ্লো বেছে নিন, ডাটাবেস সীমানা পর্যন্ত অনুসরণ করুন, তারপর বন্ধ করুন এবং যা শিখলেন তা লিখে রাখুন। যখন কিছু অস্পষ্ট থাকে, সেটাকে একটি প্রশ্ন হিসেবে ধরুন, একটি অনুচ্ছেদ না। "Where is role X created?" বলা "auth is confusing" বলার চেয়ে বেশি কার্যকর।

একটি ভালো চূড়ান্ত পরীক্ষা: কল্পনা করুন আপনাকে একটি ছোট ফিচার একটি ফিচার-ফ্ল্যাগের পিছনে যোগ করতে বলা হলো। আপনি যদি ফাইলগুলো বলতে পারেন যেগুলো আপনি স্পর্শ করবেন, আপনি কোন টেস্ট চালাবেন, এবং কোন ব্যর্থতার মোডগুলো দেখবেন, আপনি যথেষ্ট অনবোর্ডেড যাতে দায়িত্বশীলভাবে অবদান রাখতে পারেন।

পরবর্তী পদক্ষেপ: মানচিত্রকে আপ টু ডেট রাখা এবং হ্যান্ডঅফ সহজ করা

একটি মানসিক মানচিত্র তখনই কাজে যায় যখন এটি বাস্তবতার সাথে মিলে। এটাকে এককালীন কাজ হিসাবে না দেখে একটি জীবন্ত আর্টিফ্যাক্ট হিসেবে দেখুন। বাস্তবতা মেলে রাখার সবচেয়ে সহজ উপায় হলো সংশ্লিষ্ট পরিবর্তনের পরে তা আপডেট করা।

একটি হালকা অনুশীলন বড় রিভাইটের চেয়ে কার্যকর। আপনার কাজের সঙ্গে আপডেটগুলো বেঁধে দিন:

• প্রতিটি ফিচারের পরে: মডিউল তালিকা এবং মূল ইউজার ফ্লোগুলো আপডেট করুন যেগুলো তা স্পর্শ করেছে
• প্রতিটি ইনসিডেন্টের পরে: ট্রিগার, প্রভাব, এবং সঠিক ফিক্স লোকেশন যোগ করুন
• প্রতিটি ঝুঁকিপূর্ণ রিফ্যাক্টরের পরে: কী বদলেছে এবং কী সামঞ্জস্যপূর্ণ আছে লিখে রাখুন
• রিলিজের আগে: শীর্ষ ৩টি ঝুঁকিপূর্ণ এলাকা পুনরায় চেক করুন এবং টেস্ট পথগুলো চালান
• মাসে একবার: পুরানো নোট মুছুন এবং গুরুত্বপূর্ণ মডিউলের মালিকদের নিশ্চিত করুন

অনবোর্ডিং ডক কোডের কাছাকাছি রাখুন এবং কোডবেসের মতো ভেরশন করুন। ছোট ডিফ পড়া হবে। বড় ডক রিভাইন্ডগুলি সাধারণত উপেক্ষা করা হয়।

যখন ডেপ্লয় ঝুঁকিপূর্ণ হয়, পরবর্তী ব্যক্তিকে দ্রুত পুনরুদ্ধার করতে কী সাহায্য করবে তা লিখে রাখুন: কী বদলেছে, কী দেখতে হবে, এবং কীভাবে রোলব্যাক করতে হবে। যদি আপনার প্ল্যাটফর্ম স্ন্যাপশট এবং রোলব্যাক সাপোর্ট করে, স্ন্যাপশটের নাম, কারণ, এবং ফিক্সের পরে কী "ভাল" দেখায় তা যোগ করুন।

আপনি যদি Koder.ai (koder.ai) ব্যবহার করে নির্মাণ করেন, planning mode আপনাকে আপনার Q&A থেকে একটি ধারাবাহিক মডিউল ম্যাপ ও অনবোর্ডিং নোট খসড়া করতে সাহায্য করবে, এবং source code export রিভিউয়ারদের একটি পরিষ্কার উপায় দেয় ফল যাচাই করার জন্য।

অবশেষে, পরবর্তী ডেভেলপারকে অনুমান ছাড়া অনুসরণ করার জন্য একটি হ্যান্ডঅফ চেকলিস্ট সংজ্ঞায়িত করুন:

• প্রথমে কী পড়বেন (2-3 ফাইল বা ডক) এবং কেন
• লোকালি কী চালাবেন (কমান্ড, env vars, seed data)
• কী যাচাই করবেন (একটি হ্যাপি পাথ এবং একটি ব্যর্থতার কেস)
• কোথায় তীক্ষ্ণ ধার রয়েছে (ঝুঁকিপূর্ণ মডিউল, ফ্ল্যাকি টেস্ট, জটিল কনফিগ)
• কাকে কোন বিষয়ে জিজ্ঞেস করবেন (কী ফ্লোদের মালিক)

ভালভাবে করা হলে, Claude Code কোডবেস অনবোর্ডিং একটি অভ্যাসে পরিণত হয়: প্রতিটি পরিবর্তন পরবর্তী ব্যক্তির জন্য একটি পরিষ্কার মানচিত্র রেখে যায়।