০৮ ডিসে, ২০২৫·8 মিনিট
Claude Code কোডবেস অনবোর্ডিং: আপনার অ্যাপ ম্যাপ করার প্রম্পট
Claude Code কোডবেস অনবোর্ডিংয়ের জন্য: Q&A প্রম্পট ব্যবহার করে মডিউল, মূল ফ্লো, ও ঝুঁকি ম্যাপ করুন, তারপর নোটগুলোকে একটি সংক্ষিপ্ত অনবোর্ডিং ডকে পরিণত করুন।
Claude Code কোডবেস অনবোর্ডিংয়ের জন্য: Q&A প্রম্পট ব্যবহার করে মডিউল, মূল ফ্লো, ও ঝুঁকি ম্যাপ করুন, তারপর নোটগুলোকে একটি সংক্ষিপ্ত অনবোর্ডিং ডকে পরিণত করুন।
ফাইলগুলো এলোমেলোভাবে পড়া ধীর অনুভব হয় কারণ বেশিরভাগ কোডবেস গল্পের মতো সাজানো থাকে না। আপনি একটি ফোল্ডার খুলেন, দশটা নাম দেখতে পান যা গুরুত্বপূর্ণ মনে হয়, একটি ক্লিক করেন, এবং সাহায্যকারী, কনফিগ, ও এজ কেসে পৌঁছান। এক ঘন্টার পর, আপনার কাছে অনেক বিবরণ থাকে কিন্তু আপনি এখনও অ্যাপ কিভাবে কাজ করে সেটা ব্যাখ্যা করতে পারছেন না।
Claude Code দিয়ে অনবোর্ডিংয়ের জন্য একটি ভাল লক্ষ্য হল একটি সহজ মানসিক মানচিত্র তৈরি করা। সেই মানচিত্র তিনটি প্রশ্নের উত্তর দেয়া উচিত:
1-2 দিনের মধ্যে "গুড এনাফ" অনবোর্ডিং মানে নয় "আমি প্রতিটি ক্লাস ব্যাখ্যা করতে পারি।" বরঞ্চ এর কাছাকাছি হওয়া উচিত:
কিছু জিনিস পরে করা যায়। গভীর রিফ্যাক্টর, প্রতিটি অ্যাবস্ট্রাকশনের নিখুঁত বোঝাপড়া, এবং কেউ না পড়া পুরনো কোড আশা অনুযায়ী দ্রুত কাজ দেয় না।
অনবোর্ডিংকে একটি মানচিত্র তৈরি হিসেবে ভাবুন, রাস্তাগুলো মুখস্থ করার মতো নয়। আপনার প্রম্পটগুলোকে বারবার ফিরে আনতে হবে: "আমি সিস্টেমের কোথায় আছি, পরের কী হয়, এবং এখানে কী খারাপ হতে পারে?" একবার আপনার কাছে সেটা থাকলে, বিস্তারিত অন-ডিমান্ডে শেখা সহজ হয়ে যায়।
প্রশ্ন করা শুরু করার আগে, সাধারণত প্রথম দিনে যা যা দরকার তা সংগ্রহ করুন। Claude Code তখনই সবচেয়ে ভাল কাজ করে যখন এটি আসল ফাইল, আসল কনফিগ, এবং আপনি পুনরায় চালাতে পারা আচরণে প্রতিক্রিয়া দেখাতে পারে।
শুরু করুন অ্যাক্সেস এবং একটি কাজ করা রান দিয়ে। নিশ্চিত করুন আপনি রেপো ক্লোন করতে পারেন, ডিপেন্ডেন্সি ইনস্টল করতে পারেন, এবং লোকালি অ্যাপ চালাতে পারেন (বা অন্তত একটি ছোট অংশ)। লোকালি সেটআপ কঠিন হলে, স্টেজিং পরিবেশ এবং যেখানে লগ থাকে সেখানে অ্যাক্সেস নিন, যাতে আপনি যাচাই করতে পারেন কোড আসলে কী করে।
পরের ধাপে, "সোর্স অব ট্রুথ" ডকস খুঁজে বের করুন। আপনি যা খুঁজছেন তা হলো দল বদলালে যেটি তারা আসলেই আপডেট করে: README, সংক্ষিপ্ত আর্কিটেকচার নোট, ADR ফোল্ডার, runbook, বা deployment নোট। এগুলো ময়লা হলেও, তারা মডিউল ও ফ্লোদের নাম দেয়, যা Q&A-কে অনেক বেশি স্পষ্ট করে তোলে।
শুরুতে স্কোপ নির্ধারণ করুন। অনেক রেপোতে একাধিক অ্যাপ, সার্ভিস, এবং শেয়ার করা প্যাকেজ থাকে। সীমানা নির্ধারণ করুন যেমন "শুধু API এবং billing worker" বা "শুধু ওয়েব অ্যাপ এবং তার auth ফ্লো।" স্পষ্ট স্কোপ অনন্ত বিচ্যুতি রোধ করে।
অ্যাসিস্ট্যান্টকে যা অনুমান করতে দেবেন না সেই অনুমানগুলো লিখে রাখুন। এটা ছোট মনে হলেও পরে ভুল মানসিক মডেল থেকে ঘণ্টা পড়ে যাবে।
এখানে একটি সহজ প্রস্তুতি চেকলিস্ট:
যদি কিছু অনুপস্থিত থাকে, সেটাকে টিমমেটের কাছে একটি প্রশ্ন হিসেবে ধরুন। অনুপস্থিত প্রেক্ষাপটকে অনুমান করে "ওয়ার্ক অ্যারাউন্ড" করবেন না।
একটি মানসিক মানচিত্র হলো এমন কিছু নোট যা উত্তর দেয়: এই অ্যাপের মূল অংশগুলো কী, তারা কিভাবে একে অপরের সাথে কথা বলে, এবং কোথায় সমস্যা হতে পারে। ভালভাবে করা হলে, অনবোর্ডিং ফাইল ব্রাউজ করা নয় বরং একটি পুনরায় ব্যবহারযোগ্য ছবি তৈরি করা হয়ে যায়।
শুরু করুন আপনার আউটপুট নির্ধারণ করে। আপনি একটি মডিউল তালিকা চাইবেন যা ব্যবহারিক, নিখুঁত নয়। প্রতিটি মডিউলের জন্য ধরুন এটি কী করে, কে এটাকে ধরে (টিম বা ব্যক্তি যদি জানেন), এবং এর মূল ডিপেন্ডেন্সি কী (অন্যান্য মডিউল, সার্ভিস, ডাটাবেস, এক্সটার্নাল APIs)। এছাড়া প্রধান এন্ট্রি পয়েন্টগুলো নোট করুন: UI routes, API endpoints, ব্যাকগ্রাউন্ড জব, এবং শিডিউলেড টাস্ক।
পরের ধাপে, কয়েকটি ইউজার জার্নি বেছে নিন যা গুরুত্বপূর্ণ। তিন থেকে পাঁচটি যথেষ্ট। এমন ফ্লো বেছে নিন যা অর্থ, পারমিশন, বা ডাটা পরিবর্তনকে স্পর্শ করে। উদাহরণ: সাইনআপ ও ইমেইল ভেরিফিকেশন, পেইড প্ল্যান বা পারচেজ তৈরি করা, এমন একটি অ্যাডমিন অ্যাকশন যা ইউজার এক্সেস বদলে দেয়, এবং একটি ক্রিটিকাল ডেইলি-ইউজ ফ্লো যা বেশিরভাগ ব্যবহারকারী নির্ভর করে।
শুরু করার আগে ঝুঁকি কীভাবে লেবেল করবেন তা নির্ধারণ করুন। ক্যাটাগরিগুলো সহজ রাখুন যাতে পরে স্ক্যান করা যায়। একটি উপযোগী সেট হলো security, data integrity, uptime, এবং cost। যখন আপনি কিছু ঝুঁকিপূর্ণ হিসাবে চিহ্নিত করবেন, এক বাক্যে লিখে রাখুন কেন, প্লাস কী প্রমাণ করবে সেটা নিরাপদ (একটি টেস্ট, একটি লগ, একটি পারমিশন চেক)।
নোটগুলো একটি সঙ্গত ফরম্যাটে রাখুন যাতে আপনি তা অনবোর্ডিং ডকে রূপান্তর করতে পারেন পুনরায় লেখার দরকার ছাড়াই:
উদাহরণ: যদি Checkout Billing কল করে যা payments এবং invoices-এ লেখে, সেটিকে data integrity এবং cost হিসেবে ট্যাগ করুন। তারপর নোট করুন কোথায় রিট্রাই ঘটে এবং কী ডাবল-চার্জিং রোধ করে।
আপনি যখন একটি নতুন রেপোতে যোগ দেন, দ্রুত অভিভাবন চাইবেন, নিখুঁত বোঝাপড়া নয়। এই প্রম্পটগুলো আপনাকে ছোট, নিরাপদ ধাপে মানসিক মানচিত্র তৈরি করতে সাহায্য করবে।
শুরুতে অ্যাসিস্ট্যান্টকে রেপো ট্রি দিন (অথবা পেস্ট করা একটি সাবসেট) এবং একটি ট্যুর চাইুন। প্রতিটি রাউন্ডকে ফোকাসড রাখুন, তারপর শেষ করুন একটি প্রশ্ন দিয়ে যা বলে যে আপনাকে পরের কোনটি পড়তে হবে।
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" ম্যাপ করুন যাতে ক্লিনআপ গ্যাপ খুঁজে পাওয়া যায়।
উত্তরগুলো কার্যকর রাখার জন্য, নির্দিষ্ট আর্টিফ্যাক্ট চাইুন, কেবল সারাংশ নয়:
সবচেয়ে বড় অনবোর্ডিং জয় হলো ছড়িয়ে থাকা 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 মানচিত্র করুন। এন্ডপয়েন্ট বা ফাংশন খুঁজে বের করুন যা রেকর্ড তৈরি, আপডেট, বা ডিলিট করে, প্লাস সেই মাইগ্রেশনগুলো যা সময়ে সময়ে ডাটা রিফর্ম করে। ব্যাকগ্রাউন্ড জবগুলোও অন্তর্ভুক্ত করুন। অনেক রহস্যজনক বাগ আসে এসিঙ্ক ওয়ার্কারদের কারণে যারা অনুরোধ শেষ হওয়ার অনেক পরে অপ্রত্যাশিত মান লেখে।
তারপর ঝুঁকি দ্রুত উন্মোচনের জন্য প্রম্পটগুলোঃ
তারপর কনফিগ ও সিক্রেট হ্যান্ডলিং চেক করুন। এনভায়রনমেন্ট ভ্যারিয়েবল, রানটাইম কনফিগ ফাইল, এবং ডিফল্ট ফ্যালব্যাক খুঁজুন। ডিফল্টগুলো কাজে লাগে, কিন্তু বিপজ্জনক যখন তারা কনফিগ মিসিং হলে ভুল কী ব্যবহার করে (উদাহরণ: প্রোডাকশনে dev key ব্যবহার করা)।
একটি দ্রুত উদাহরণ: একটি Go ব্যাকএন্ড যেখানে PostgreSQL আছে, আপনি একটি "send email" জব পেতে পারেন যা ব্যর্থ হলে রিট্রাই করে। যদি এটি idempotency key ছাড়া রিট্রাই করে, ব্যবহারকারীরা ডুপ্লিকেট ইমেইল পেতে পারে। যদি ব্যর্থতাগুলো কেবল একটি ওয়ার্নিং লগ করে এবং কোনো অ্যালার্ট না থাকে, তাহলে এটা চুপচাপ ভেঙে যায়। এটা একটি উচ্চ-ঝুঁকিপূর্ণ এলাকা যা প্রথমেই ডকুমেন্ট করা উচিত এবং পরীক্ষা করা দরকার।
একটি বাস্তব ফ্লো ব্যবহার করুন আপনার প্রথম এন্ড-টু-এন্ড থ্রেড তৈরি করতে। Login শুরু করার জন্য একটি ভাল স্টার্ট কারণ এটি routing, validation, sessions বা tokens, এবং ডাটাবেস রিড টাচ করে। আপনার লক্ষ্য প্রতিটি ফাইল বোঝা নয়। লক্ষ্য হলো: "যখন একটি ব্যবহারকারী Login ক্লিক করে, পরের কোন কোড চলে, কোন ডেটা চলে, এবং কী ভেঙে যেতে পারে?" এটা অনবোর্ডিংকে কংক্রিট রাখে।
UI থেকে শুরু করে একটি হপ করে এগিয়ে যান। নির্দিষ্ট ফাইল নাম, ফাংশন, রিকোয়েস্ট ও রেসপন্স শেপ জিজ্ঞেস করুন।
প্রতিটি উত্তর পর আপনি আপনার মানসিক মানচিত্রে এক লাইন লিখুন: "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-এর আউটপুট হিসেবে বিবেচনা করুন: পরিষ্কার, কংক্রিট, এবং দ্রুত স্ক্যানযোগ্য।
ডকটি পূর্বানুমেয় রাখুন যাতে লোক দ্রুত খুঁজে পায়। একটি ভালো কাঠামো:
"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."
আরেকটি সাধারণ ফাঁদ হলো অ্যাসিস্ট্যান্টকে অনুমান করতে দেওয়া। যখন কিছু অস্পষ্ট থাকে, তাকে স্পষ্টভাবে অনিশ্চয়তা লেবেল করতে বলুন। কোড প্রমাণিত কি না এবং কী অনুমান সে আলাদা করে জানানো উচিত।
নোটে একটি সহজ নিয়ম ব্যবহার করুন: প্রতিটি দাবিকে একটি এটার মধ্যে ট্যাগ দিন:
নোটগুলো তখনই ভেঙে যায় যখন সেগুলো বিন্যাসহীনভাবে সংগ্রহ করা হয়। একটি ধারাবাহিক টেমপ্লেট রাখুন: জড়িত মডিউল, এন্ট্রি পয়েন্ট, মূল ফাংশন ও ফাইল, টাচ করা ডাটা, সাইড-এফেক্ট, এরর পাথ, এবং চালাতে থাকা টেস্ট।
Claude Code থাকলেও আউটপুটকে খসড়া মনে করুন। মূল ফ্লোগুলো চালিয়ে যাচাই করুন, বিশেষ করে সেই অংশগুলো যা প্রোডাকশন ভাঙতে পারে: auth, payments, permissions, background jobs, এবং migrations।
একটি বাস্তবিক উদাহরণ: যদি অ্যাসিস্ট্যান্ট বলে "password reset sends an email via X," সেটি ডেভ এনভায়রনমেন্টে ট্রিগার করে লগ বা ইমেইল স্যান্ডবক্স দেখে নিশ্চিত করুন। সেই বাস্তব-চেক আপনাকে এমন একটি গল্পে অনবোর্ড হওয়া থেকে রোধ করে যা সত্য নয়।
আপনাকে রেপো মুখস্থ করার দরকার নেই। আপনাকে যথেষ্ট আত্মবিশ্বাস দরকার যাতে আপনি একটি নিরাপদ পরিবর্তন করতে পারেন, একটি বাস্তব ইস্যু ডিবাগ করতে পারেন, এবং সিস্টেমটি পরবর্তী ব্যক্তিকে ব্যাখ্যা করতে পারেন।
নিজেকে অনবোর্ডেড বলতে পারার আগে নিশ্চিত করুন যে আপনি এগুলো অনুমান ছাড়া উত্তর দিতে পারেন:
যদি একটি আইটেম অনুপস্থিত থাকে, একটি ছোট ফোকাসড পাস করুন বদলে একটি বিস্তৃত সার্চ করার। একটি ফ্লো বেছে নিন, ডাটাবেস সীমানা পর্যন্ত অনুসরণ করুন, তারপর বন্ধ করুন এবং যা শিখলেন তা লিখে রাখুন। যখন কিছু অস্পষ্ট থাকে, সেটাকে একটি প্রশ্ন হিসেবে ধরুন, একটি অনুচ্ছেদ না। "Where is role X created?" বলা "auth is confusing" বলার চেয়ে বেশি কার্যকর।
একটি ভালো চূড়ান্ত পরীক্ষা: কল্পনা করুন আপনাকে একটি ছোট ফিচার একটি ফিচার-ফ্ল্যাগের পিছনে যোগ করতে বলা হলো। আপনি যদি ফাইলগুলো বলতে পারেন যেগুলো আপনি স্পর্শ করবেন, আপনি কোন টেস্ট চালাবেন, এবং কোন ব্যর্থতার মোডগুলো দেখবেন, আপনি যথেষ্ট অনবোর্ডেড যাতে দায়িত্বশীলভাবে অবদান রাখতে পারেন।
একটি মানসিক মানচিত্র তখনই কাজে যায় যখন এটি বাস্তবতার সাথে মিলে। এটাকে এককালীন কাজ হিসাবে না দেখে একটি জীবন্ত আর্টিফ্যাক্ট হিসেবে দেখুন। বাস্তবতা মেলে রাখার সবচেয়ে সহজ উপায় হলো সংশ্লিষ্ট পরিবর্তনের পরে তা আপডেট করা।
একটি হালকা অনুশীলন বড় রিভাইটের চেয়ে কার্যকর। আপনার কাজের সঙ্গে আপডেটগুলো বেঁধে দিন:
অনবোর্ডিং ডক কোডের কাছাকাছি রাখুন এবং কোডবেসের মতো ভেরশন করুন। ছোট ডিফ পড়া হবে। বড় ডক রিভাইন্ডগুলি সাধারণত উপেক্ষা করা হয়।
যখন ডেপ্লয় ঝুঁকিপূর্ণ হয়, পরবর্তী ব্যক্তিকে দ্রুত পুনরুদ্ধার করতে কী সাহায্য করবে তা লিখে রাখুন: কী বদলেছে, কী দেখতে হবে, এবং কীভাবে রোলব্যাক করতে হবে। যদি আপনার প্ল্যাটফর্ম স্ন্যাপশট এবং রোলব্যাক সাপোর্ট করে, স্ন্যাপশটের নাম, কারণ, এবং ফিক্সের পরে কী "ভাল" দেখায় তা যোগ করুন।
আপনি যদি Koder.ai (koder.ai) ব্যবহার করে নির্মাণ করেন, planning mode আপনাকে আপনার Q&A থেকে একটি ধারাবাহিক মডিউল ম্যাপ ও অনবোর্ডিং নোট খসড়া করতে সাহায্য করবে, এবং source code export রিভিউয়ারদের একটি পরিষ্কার উপায় দেয় ফল যাচাই করার জন্য।
অবশেষে, পরবর্তী ডেভেলপারকে অনুমান ছাড়া অনুসরণ করার জন্য একটি হ্যান্ডঅফ চেকলিস্ট সংজ্ঞায়িত করুন:
ভালভাবে করা হলে, Claude Code কোডবেস অনবোর্ডিং একটি অভ্যাসে পরিণত হয়: প্রতিটি পরিবর্তন পরবর্তী ব্যক্তির জন্য একটি পরিষ্কার মানচিত্র রেখে যায়।
একটি ব্যবহারযোগ্য মানসিক মানচিত্র লক্ষ্য করুন, সম্পূর্ণ বোঝাপড়া নয়.
একটি শক্ত 1–2 দিন আউটকাম হলো:
এটি বাস্তব কোডে নির্দেশ দিতে পারে যাতে এটি কল্পনা না করে:
একটি সীমিত অংশ নির্ধারণ করে দিন যাতে অ্যাসিস্ট্যান্ট আপনাকে ভ্রান্ত পথে নিয়ে না যায়.
একটি ভাল ডিফল্ট স্কোপ:
স্পষ্টভাবে লিখে দিন কী অজানা বা আউট-অফ-স্কোপ (অন্যান্য সার্ভিস, লিগ্যাসি মডিউল, বিরল বৈশিষ্ট্য) যেন অ্যাসিস্ট্যান্ট ঘুরে বেড়ায় না।
জানতে পারা ট্রিগারগুলো থেকে শুরু করুন, তারপর এগিয়ে যান:
প্রশ্ন করুন ফাইল পাথ এবং ফাংশন নামগুলো ক্রমে এবং শেষ করুন: “How would I test this quickly?”
যেখানে সিস্টেম সিদ্ধান্ত নেয় বা স্টেট পরিবর্তন হয় সেখানে ঝুঁকি থাকে:
একটি সহজ লেবেল সিস্টেম ব্যবহার করুন এবং একটি প্রমাণধর্মী ধাপ যোগ করুন.
উদাহরণ ফরম্যাট:
অ্যাসিস্ট্যান্টকে প্রমাণ থেকে inference আলাদা করতে বলুন.
প্রতিটি দাবি এই ট্যাগগুলোর একটি হিসেবে চিহ্নিত করতে বলুন:
যখন কিছু unknown থাকে, সেটাকে একটি টিমমেটকে জিজ্ঞেস করার প্রশ্নে রূপান্তর করুন (“Where is role X defined?”) বরং শূন্যতা পূরণ করার অনিশ্চিত অনুমান না করে।
একটি হালকা ওজনের নোট ফাইল রাখুন পাঁচটি সেকশনে:
একটি দ্রুত, বাস্তব পরীক্ষা করুন:
এটি নিশ্চিত করে যে আপনি যে পথটি ম্যাপ করেছেন সেটিই অ্যাপ আসলে ব্যবহার করে।
প্ল্যাটফর্ম ফিচারগুলো ব্যবহার করে ঝুঁকি কমাতে এবং পরিবর্তনগুলো রিভিউযোগ্য রাখতে সাহায্য করে:
ব্যবহারিক ডিফল্ট:
তারপর জিজ্ঞেস করুন: “What breaks silently, and how would we notice?”
সংক্ষিপ্ত রাখুন যাতে আপনি শেখার সঙ্গে এটি আসল সময়ে আপডেট করেন।
প্রত্যেক ফ্লো-এ একটি লাইন যোগ করুন: “How would I test this?” যাতে এটি একটি চেকলিস্টে পরিণত হয়।
অনবোর্ডিং কাজ যেমন “add a guardrail,” “tighten validation,” বা “improve an error path”–এর জন্য এটি বিশেষত কার্যকর।