Claude Code PR review: পূর্ব-রিভিউ ডিফস দ্রুত ও নিরাপদ

কেন PR রিভিউয়ের সময় বাড়ে

PR রিভিউ সাধারণত দীর্ঘ হয় কারণ কোড "কঠিন"—এমনটা নয়। এটি দীর্ঘ হয় কারণ রিভিউয়ারকে একটি ডিফ থেকে উদ্দেশ্য, ঝুঁকি এবং প্রভাব পুনর্নির্মাণ করতে হয়, এবং ডিফ সব গল্প বলে না।

একটি ছোটো সম্পাদনা লুকানো নির্ভরশীলতায় আঘাত করতে পারে: একটি ফিল্ডের নাম বদলালে রিপোর্ট ভেঙে যেতে পারে, ডিফল্ট মান বদলালে আচরণ সরে যেতে পারে, একটি কন্ডিশন বদলালে এরর হ্যান্ডলিং বদলে যেতে পারে। যখন রিভিউয়ার প্রসঙ্গ জানার জন্য ক্লিক করে ঘোরে, অ্যাপ লোকালি চালায়, এবং বুঝতে প্রশ্ন করে, তখন রিভিউ সময় বাড়ে।

একই সঙ্গে মানুষের পড়ার প্যাটার্নের সমস্যা থাকে। মানুষ ডিফগুলো টেনেভাগ ধারায় স্কিম করে: আমরা “প্রধান” পরিবর্তনে ফোকাস করি এবং সেই নীরস লাইনে চোখ রাখি না যেখানে বাগগুলো লুকায় (বাউন্ডারি চেক, নাল হ্যান্ডলিং, লগিং, ক্লিনআপ)। আমরা যা দেখতে আশা করি তাই পড়তে ঝোঁক রাখি, তাই কপি-পেস্ট ভুল এবং ইনভার্টেড কন্ডিশন খুঁজে বের করতে পারে।

ভাল একটি পূর্ব-রিভিউ কোনো সিধান্ত নয়। এটি একটি দ্রুত, কাঠামোবদ্ধ দ্বিতীয় দৃষ্টিভঙ্গি যা বলে দেয় কোথায় একজন মানুষের ধীরগতিতে পড়া উচিত। সর্বোত্তম আউটপুট হবে:

• কি বদলেছে তার সাধারণ-ইংরেজি সারাংশ
• নির্দিষ্ট ঝুঁকি পয়েন্ট (ফাইল, ফাংশন, অনুমান)
• পঠনযোগ্যতার নোট (নামকরণ, বিভ্রান্তিকর কন্ট্রোল ফ্লো)
• সঠিকতার উদ্বেগ (লজিক, এরর হ্যান্ডলিং, ডেটা কনসিস্টেন্সি)
• পরীক্ষার যোগ্য এজ-কেস (ইনপুট, সময়, অনুমতি, খালি অবস্থা)

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

AI সাহায্য সবচেয়ে শক্তিশালী মাঝারি-আকারের PR-এ যা ব্যবসায়িক লজিক বা রিফ্যাক্টরের স্পর্শে যেখানে মানে হারানো যায়। এটি অস্বচ্ছ যখন সঠিক উত্তর গভীর সংস্থাগত জ্ঞানের উপর নির্ভর করে (লেগাসি আচরণ, প্রোডাকশন পারফরম্যান্স কুইর্কস, অভ্যন্তরীণ সিকিউরিটি রুল)।

উদাহরণ: একটি PR যা "শুধু pagination আপডেট করে" প্রায়ই অফ-বাই-ওয়ান পেজ, খালি রেজাল্ট এবং API ও UI-র মধ্যে মিশ্রিত সর্টিং লুকায়। একটি পূর্ব-রিভিউ এই প্রশ্নগুলো মানুষ ৩০ মিনিট খরচ করার আগে সেগুলো উত্থাপন করা উচিত।

একটি পূর্ব-রিভিউতে Claude-কে কি জিজ্ঞাসা করবেন

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

একজন ন্যায্য মানব রিভিউয়ার যে তথ্য চাইবে তা দিন:

• PR-র লক্ষ্য (1 থেকে 3 বাক্য)
• কি ভাঙলে চলবে না (API আকার, ব্যাকওয়ার্ড সামর্থ্য, পারফরম্যান্স বাজেট, সিকিউরিটি রুল)
• কোনো বিশেষ সীমাবদ্ধতা বা ট্রেডঅফ (ডেডলাইন, পার্শিয়াল রোলআউট)
• প্রাসঙ্গিক ডিফ হাঙ্কস, যথেষ্ট চারপাশের কোডসহ যাতে উদ্দেশ্য বোঝা যায়

اگر PR একটি পরিচিত উচ্চ-ঝুঁকিপূর্ণ এলাকা স্পর্শ করে, তা আগে থেকেই বলুন (auth, billing, migrations, concurrency)।

তারপর এমন আউটপুট চান যা আপনি কাজে লাগাতে পারবেন। একটি শক্ত অনুরোধ দেখতে এরকম:

• কি বদলেছে সোজা ভাষায় সারসংক্ষেপ করুন।
• পঠনযোগ্যতার সমস্যা ফ্ল্যাগ করুন (নামকরণ, স্ট্রাকচার, অবাক করা জিনিস, অসঙ্গত প্যাটার্ন)।
• সঠিকতার ঝুঁকি চিহ্নিত করুন (নাল হ্যান্ডলিং, এরর পাথ, অফ-বাই-ওয়ান, ডেটা শেপ মিসম্যাচ)।
• টেস্ট করার জন্য এজ-কেস ও ফেলিওর মোডের তালিকা দিন (টাইমআউট, রিট্রাই, খালি ইনপুট ইত্যাদি)।
• অনুপস্থিত টেস্ট ও প্রতিটি টেস্ট কি প্রমাণ করে তা সুপারিশ করুন।
• একটি সংক্ষিপ্ত রিভিউয়ার চেকলিস্ট ও মার্জের আগে জিজ্ঞাস্য ৫-১০টি প্রশ্ন তৈরি করুন।

মানুষ নিয়ন্ত্রণে রাখুন অনিশ্চয়তার উপর স্পষ্টতা জোর দিয়ে। Claude-কে বলুন findings-কে "ডিফ থেকে নিশ্চিত" বনাম "নিশ্চিত করতে হবে" হিসেবে লেবেল করতে, এবং প্রতিটি উদ্বেগের জন্য যে সঠিক লাইনে টিগার হয়েছে তা উক্ত করতে।

প্রম্পট দেওয়ার আগে ডিফ ও প্রসঙ্গ প্রস্তুত করুন

Claude কেবল তাই ভালো যতটা আপনি তাকে দেখান। যদি আপনি একটি বিশাল ডিফ পেস্ট করেন কোন লক্ষ্য বা সীমাবদ্ধতা ছাড়া, আপনি সাধারণ পরামর্শ পাবেন এবং প্রকৃত ঝুঁকি মিস করবেন।

একটি কনক্রিট লক্ষ্য ও সাফল্য মানদণ্ড দিয়ে শুরু করুন। উদাহরণ: “এই PR লগইন এন্ডপয়েন্টে রেট লিমিট যোগ করে যাতে সদ্ব্যবহার কমে। এটি রেসপন্স শেপ পরিবর্তন করবে না। গড় ল্যাটেন্সি 50 ms-এর নিচে রাখতে হবে।”

পরের ধাপে, শুধুই গুরুত্বপূর্ণ অংশগুলো অন্তর্ভুক্ত করুন। যদি 20 ফাইল বদলেছে কিন্তু কেবল 3টিই লজিক ধরে, সেগুলোকেই ফোকাস করুন। যখন একটি স্নিপেট বিভ্রান্তিকর হবে, চারপাশের প্রসঙ্গ যেমন ফাংশন সিগনেচার, কী টাইপস বা কনফিগ উল্লেখ করুন।

শেষে, টেস্টিং প্রত্যাশা স্পষ্ট করুন। যদি আপনি এজ-কেসগুলোর জন্য ইউনিট টেস্ট চান, একটি ক্রিটিকাল পাথের জন্য ইন্টিগ্রেশন টেস্ট চান, বা ম্যানুয়াল UI রান-থ্রু চান—সব বলে দিন। যদি ইর্gরপস উদ্দেশ্যমূলকভাবে অনুপস্থিত থাকে, তার কারণ বলুন।

একটি সরল “কনটেক্সট প্যাক” যা ভালো কাজ করে:

• PR লক্ষ্য: কি বদলাচ্ছে, ব্যবহারকারী কি দেখবে, কি উন্নতি হবে
• প্রাসঙ্গিক ডিফ চাংকস: কেবল গুরুত্বপূর্ণ ফাইল, যথেষ্ট চারপাশের কোডসহ
• কঠিন সীমাবদ্ধতা: পারফর্ম্যান্স বাজেট, সামঞ্জস্যের শর্ত, সিকিউরিটি/প্রাইভেসি রুল
• টেস্ট প্রত্যাশা: কি কভার করা উচিত, কি যোগ করা হয়েছে, কিভাবে চালাবেন
• “ভাঙলে চলবে না” আইটেমস: পাবলিক API কনট্রাক্ট, ডাটাবেজ স্কিমা, UX আচরণ, লগিং/অডিট ফরম্যাট

ধাপে ধাপে: একটি পুনরাবৃত্তি যোগ্য পূর্ব-রিভিউ ফ্লো

একটি ভালো Claude Code PR রিভিউ একটি টাইট লুপ হিসেবে কাজ করে: যথেষ্ট প্রসঙ্গ দিন, কাঠামোবদ্ধ নোট নিন, তারপর সেগুলোকে অ্যাকশনে পরিণত করুন। এটি মানবকে প্রতিস্থাপন করে না। এটি সহজ মিসগুলো ধরবে মানুষ যখন দীর্ঘ সময় পড়বে তখন তাদের আগে।

৫-পর্বের ফ্লো

একই ধাপগুলো প্রতিবার ব্যবহার করুন যাতে ফলাফল পূর্বানুমানযোগ্য থাকে:

1. পরিবর্তনটি সাধারণ ভাষায় ব্যাখ্যা করুন। Claude-কে বলুন PR কি করে, কোন ফাইল বদলেছে, এবং সম্ভবত কেন বদলেছে তা সারসংক্ষেপ করতে। যদি এটি সহজভাবে ব্যাখ্যা করতে না পারে, PR-কে স্পষ্ট বর্ণনা বা ছোটো স্কোপ প্রয়োজন।
2. প্রথমে সঠিকতা চেক করুন। লজিক ত্রুটি, ভাঙা অনুমান, নীরব আচরণ পরিবর্তন (ডিফল্ট, এরর হ্যান্ডলিং, পারমিশন, টাইমজোন, অফ-বাই-ওয়ান) খুঁজুন।
3. মিসিং কেসগুলো স্ক্যান করুন। ব্যবহারকারীর মতই ভাবুন এবং প্রোডাকশনের মতই: খালি ইনপুট, নাল, রিট্রাই, আংশিক ফেলিওর, কনকারেন্সি, ব্যাকওয়ার্ড কম্প্যাটিবিলিটি।
4. পঠনযোগ্যতা ও রক্ষণাবেক্ষণ দেখুন। বিভ্রান্তিকর নাম, বড় ফাংশন, ডুপ্লিকেট লজিক, অস্পষ্ট মন্তব্য, এবং ছোট রিফ্যাক্টর যা ভবিষ্যত রিভিউ সময় কমায় চিহ্নিত করুন।
5. পয়ন্টারসহ রিভিউ কমেন্ট খসড়া করুন। ফাইল অনুসারে কমেন্ট গ্রুপ করুন এবং একটি ফাংশন নাম বা উদ্ধৃত স্নিপেট যোগ করুন যাতে মানুষ দ্রুত সেই জায়গা খুঁজে পায়।

নোট পেলে সেগুলোকে একটি সংক্ষিপ্ত মার্জ গেটে পরিণত করুন:

Merge checklist (সংক্ষিপ্ত রাখুন):

• টেস্টগুলো নতুন আচরণ এবং অন্তত একটি এজ-কেস কভার করে
• এররগুলো ধারাবাহিকভাবে হ্যান্ডেল করা হয়েছে (প্রয়োজনে লগ করা হয়েছে)
• স্পষ্ট মাইগ্রেশন প্ল্যান ছাড়া কোন ব্রেকিং চেঞ্জ নেই
• নামকরণ ও স্ট্রাকচার কাছাকাছি কোডের সাথে মিল আছে
• ঝুঁকিপূর্ণ অংশগুলোর রোলব্যাক প্ল্যান আছে

শেষে 3 থেকে 5টি প্রশ্ন চাইুন যা স্পষ্টতা জোর দেয়, যেমন “API যদি খালি তালিকা ফেরত দেয় কী হবে?” বা “এইটা concurrent অনুরোধে নিরাপদ কি?”

একটি সহজ রুব্রিক ব্যবহার করুন (পঠনযোগ্যতা, সঠিকতা, এজ-কেস)

Claude সবচেয়ে সাহায্য করে যখন আপনি তাকে একটি ফিক্সড লেন্স দেন। একটি রুব্রিক না দিলে এটি প্রায়ই প্রথম যা চোখে পরে সেটার ওপর মন্তব্য করে (সাধারণত স্টাইল), এবং হয়তো সবচেয়ে ঝুঁকিপূর্ণ বাউন্ডারি মিস করে।

একটি ব্যবহারিক রুব্রিক:

• পঠনযোগ্যতা: পরিষ্কার নাম, সরল প্রবাহ, ছোট ফাংশন, কেন লেখা হয়েছে তা ব্যাখ্যা করে এমন মন্তব্য, অপ্রয়োজনীয় কোড বা ডিবাগ আউটপুট নেই।
• সঠিকতা: মূল ইনভারিয়েন্টগুলো নিশ্চিত, এররগুলো ধারাবাহিকভাবে হ্যান্ডেল, নাল/খালি মান নিরাপদ, সীমা ঠিক (অফ-বাই-ওয়ান, রাউন্ডিং)।
• এজ-কেস: খালি/বৃহৎ ইনপুট, অনাবশ্যক ক্ষেত্রের অনুপস্থিতি, টাইমজোন ও ডেলাইট সেভিংস, রিট্রাই যা ডাবল-ওয়াইটের ঝুঁকি, কনকারেন্সি রেস।
• সিকিউরিটি ও প্রাইভেসি: যথাযথ স্থানে auth চেক, কোড/লগে সিক্রেট নেই, লগে টোকেন বা সংবেদনশীল পে-লোড ফাঁস নেই।
• কম্প্যাটিবিলিটি ও রোলআউট নিরাপত্তা: পুরোনো ক্লায়েন্ট বা স্টোর করা ডেটা ভাঙবে না, মাইগ্রেশন নিরাপদ, রোলব্যাক প্ল্যান আছে।

প্রম্পট দিলে প্রতিটি বিভাগের জন্য একটি সংক্ষিপ্ত প্যারাগ্রাফ এবং “সবচেয়ে ঝুঁকিপূর্ণ সমস্যা প্রথমে” অনুরোধ করুন। এই অর্ডার মানুষকে ফোকাস রাখতে সাহায্য করে।

ইউটিলিটি প্রম্পট টেমপ্লেট যা কার্যকর নোট দেয়

একটি পুনরায় ব্যবহারযোগ্য বেস প্রম্পট ব্যবহার করুন যাতে ফলাফল প্রতিটি PR-এ একই দেখায়। PR বর্ণনা পেস্ট করুন, তারপর ডিফ। যদি আচরণ ইউজার-ফেসিং হয়, 1-2 বাক্যে প্রত্যাশিত আচরণ যোগ করুন।

You are doing a pre-review of a pull request.

Context
- Repo/service: <name>
- Goal of change: <1-2 sentences>
- Constraints: <perf, security, backward compatibility, etc>

Input
- PR description:
<...>
- Diff (unified diff):
<...>

Output format
1) Summary (max 4 bullets)
2) Readability notes (nits + suggested rewrites)
3) Correctness risks (what could break, and why)
4) Edge cases to test (specific scenarios)
5) Reviewer checklist (5-10 checkboxes)
6) Questions to ask the author before merge (3-7)

Rules
- Cite evidence by quoting the relevant diff lines and naming file + function/class.
- If unsure, say what info you need.

সিকিউরিটি-এফেক্টেড রিভিউ (auth, payments, permissions, migrations) এর জন্য explicit ফোকাস যোগ করুন:

Extra focus for this review:
- Security/privacy risks, permission bypass, data leaks
- Money/credits/accounting correctness (double-charge, idempotency)
- Migration safety (locks, backfill, down path, runtime compatibility)
- Monitoring/alerts and rollback plan
Return a “stop-ship” section listing issues that should block merge.

রিফ্যাক্টরের ক্ষেত্রে, “কোনো আচরণ পরিবর্তন নয়” কে একটি কঠোর নিয়ম করুন:

This PR is a refactor. Assume behavior must be identical.
- Flag any behavior change, even if minor.
- List invariants that must remain true.
- Point to the exact diff hunks that could change behavior.
- Suggest a minimal test plan to confirm equivalence.

দ্রুত স্কিম চাইলে এমন লিমিট দিন: “200 শব্দের মধ্যে উত্তর দিন।” গভীরতা চান হলে বলুন: “10টি পর্যন্ত findings কারণসহ বলুন।”

Claude-র আউটপুটকে একটি রিভিউয়ার চেকলিস্টে পরিণত করুন

Claude-র নোটগুলো তখনই ব্যবহারযোগ্য যখন আপনি সেগুলোকে একটি সংক্ষিপ্ত চেকলিস্টে রূপান্তর করেন যা মানুষ বন্ধ করতে পারে। ডিফ পুনরাবৃত্তি করবেন না। ঝুঁকি ও সিদ্ধান্তগুলো ক্যাপচার করুন।

দুই বালকের মধ্যে আইটেম ভাগ করুন যাতে থ্রেড পছন্দ বা প্রাধান্য বিতর্কে বদলে না যায়:

Must-fix (block merge)

• সঠিকতা: প্রত্যাশিত আউটকাম এক বাক্যে লেখা আছে এবং টিকিটের সাথে মেলে
• এজ-কেস: নাল/খালি ইনপুট ও এরর পাথ হ্যান্ডেল করা হয়েছে (অথবা স্পষ্টভাবে প্রতাখ্যাত)
• ডেটা সেফটি: রাইটস ও মাইগ্রেশন পুরোনো ডেটা ও পুরোনো কোডের জন্য নিরাপদ
• টেস্ট: কমপক্ষে একটি টেস্ট মূল আচরণ কভার করে এবং একটি টেস্ট ঝুঁকিপূর্ণ ফেলিওর কভার করে
• অবজারভেবিলিটি: লগ/মেট্রিক্স ডিবাগিংয়ের জন্য যথেষ্ট (request id, user id, job id)

Nice-to-have (ফলোআপ)

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

রোলআউট রেডিনেসও ক্যাপচার করুন: সবচেয়ে নিরাপদ ডেপ্লয় অর্ডার, রিলিজের পরে কী দেখবেন, এবং কিভাবে আপনি পরিবর্তন উল্টাবেন।

মার্জের আগে জিজ্ঞাস্য প্রশ্নগুলো

একটি পূর্ব-রিভিউ কেবলই সাহায্য করে যদি এটি একটি ছোট প্রশ্ন সিরিজ দিয়ে শেষ হয় যা স্পষ্টতা জরুরি করে।

আচরণ ও সঠিকতা

• কোন ব্যবহারকারী-দৃষ্টিকোণ থেকে কী পরিবর্তন হচ্ছে, এবং কি অবশ্যই অপরিবর্তিত রাখতে হবে?
• যদি এটি "কোনো আচরণ পরিবর্তন নয়" হয়, কোন প্রমাণ দেখায় আউটপুটগুলো অভিন্ন?
• সম্ভাব্য প্রোডাকশন ফেলিওর সবচেয়ে বেশি কোথায় দেখা দেবে (UI, API, ডেটা)?
• কোড কি ইনপুট, অর্ডারিং, সময়, বা নেটওয়ার্ক কল সম্পর্কে কোনো অনুমান করে?
• কোনো এরর স্বল করে ফেলা হয়েছে বা নীরব ডিফল্টে পরিণত হয়েছে?

এজ-কেস, টেস্ট, অপারেশন

• সবচেয়ে খারাপ বাস্তব ইনপুটগুলো কী (খালি, বিশাল, ম্যালফর্মড, ডুপ্লিকেট), এবং কি হওয়া উচিত?
• কোন সাধারণ ফ্লো এটা দু’বার ট্রিগার করতে পারে (রিট্রাই, ডাবল-ক্লিক, ব্যাকগ্রাউন্ড জব), এবং সেটা নিরাপদ কি?
• কোন টেস্ট মূল আচরণ প্রমাণ করে, এবং কোন টেস্ট সবচেয়ে ঝুঁকিপূর্ণ এজ-কেস কভার করে?
• যদি একটি টেস্ট অনুপস্থিত, সেটা লেখাটা কি কঠিন নাকি কোড টেস্ট করা কঠিন?
• অপারেশন টীমের কি লাগবে: ব্যবহারযোগ্য লগ, মেট্রিক্স, অ্যালার্ট, কনফিগ ডিফল্ট, এবং রোলব্যাক ধাপ?

যদি আপনি এগুলো সাধারণ ভাষায় উত্তর দিতে না পারেন, মার্জ থামান এবং স্কোপ টাইট করুন বা প্রমাণ যোগ করুন।

সাধারণ ফাঁদ (এবং কীভাবে এড়াবেন)

অধিকাংশ ব্যর্থতা প্রক্রিয়াগত সমস্যা, মডেল সমস্যা নয়।

• বিনা ফোকাস বিশাল ডিফ পেস্ট করা। 1 থেকে 3 ঝুঁকিপূর্ণ এলাকায় রিভিউ চাইুন এবং কেবল সংশ্লিষ্ট হাঙ্কস ও তাদের নির্ভরশীল সিগনেচার পেস্ট করুন।
• উদ্দেশ্য ও প্রত্যাশিত আচরণ উপেক্ষা করা। একটি লক্ষ্য যোগ করুন: কি বদলেছে এবং কি অপরিবর্তিত থাকতে হবে।
• আত্মবিশ্বাসী অনুমান বিশ্বাস করা। ডিফে উদ্ধৃতি দাবি করুন। যদি এটি প্রমাণ করতে না পারে, হাইপোথিসিস হিসেবে বাছুন এবং টেস্ট করুন।
• স্টাইল নিয়ে বাইসশেড করানো। “Must-fix” বনাম “Nice-to-have” বলুন এবং স্টাইল নোট সীমাবদ্ধ করুন।
• টিম স্ট্যান্ডার্ড উপেক্ষা করা। আপনার টিম যদি নির্দিষ্ট কনভেনশন (early returns, error types, logging format) থাকে, সেগুলো অন্তর্ভুক্ত করুন।

যদি একটি PR নতুন চেকআউট এন্ডপয়েন্ট যোগ করে, পুরো সার্ভিস পেস্ট করবেন না—হ্যান্ডলার, ভ্যালিডেশন, DB রাইট এবং যেকোনো স্কিমা পরিবর্তন পেস্ট করুন এবং বলুন: “লক্ষ্য: ডাবল চার্জ প্রতিরোধ। নন-লক্ষ্য: নামকরণ রিফ্যাক্টর।” আপনি কম মন্তব্য পাবেন, এবং যেগুলো পাবেন সেগুলো যাচাই করা সহজ হবে।

বাস্তবসম্মত উদাহরণ: একটি ছোট PR-র পূর্ব-রিভিউ

একটি বাস্তবসম্মত ছোট PR: সেটিংস স্ক্রিনে একটি “display name” ফিল্ড যোগ করা। এটি সার্ভার-দিকের ভ্যালিডেশন এবং ক্লায়েন্ট-দিকের UI টেক্সট উভয়কে স্পর্শ করে। এটি পর্যাপ্তভাবে ছোট যাতে যুক্তিতে পৌঁছানো যায়, কিন্তু তবুও বাগ লুকাতে পারে।

আপনি যেসব ডিফ স্নিপেট পেস্ট করবেন তার ধরণ (পাশে 2-3 বাক্যের প্রাসঙ্গিক কন্টেক্সট সহ):

- if len(name) == 0 { return error("name required") }
+ if len(displayName) < 3 { return error("display name too short") }
+ if len(displayName) > 30 { return error("display name too long") }

- <TextInput label="Name" value={name} />
+ <TextInput label="Display name" value={displayName} helperText="Shown on your profile" />

উদাহরণে আপনি যে ধরনের findings চান:

• পঠনযোগ্যতা: বিভিন্ন ফাইলে “displayName” বনাম “name” মিশে গেছে। ভবিষ্যতে পরিবর্তনগুলোতে মানসিক অনুবাদ এড়াতে একটিই শব্দ ব্যবহার করুন।
• সঠিকতা: সার্ভার লেন্থ ভ্যালিডেট করে, কিন্তু ক্লায়েন্ট করে না। ব্যবহারকারী 1-2 ক্যারেক্টার টাইপ করতে পারবে এবং কেবল সাবমিট করার পরে এরর দেখবে।
• এজ-কেস: spaces-only স্ট্রিং len(displayName) পাস করে কিন্তু খাঁটা খালি দেখায়। ভ্যালিডেশনের আগে trim করুন।

এগুলোকে এমন একটি চেকলিস্টে পরিণত করুন:

• API, ডাটাবেস ফিল্ড এবং UI লেবেল জুড়ে নামকরণconsistent আছে
• ক্লায়েন্ট-সাইড চেক সার্ভারের নিয়ম (min/max, required) ম্যাচ করে
• ইনপুট trim করা হচ্ছে (এবং Unicode/emoji আচরণ গ্রহণযোগ্য)
• এরর মেসেজ সার্ভার ও UI-তে স্পষ্ট ও সঙ্গত

দ্রুত পরীক্ষা, মাপ, এবং পরবর্তী ধাপ

একটি Claude Code PR রিভিউ ভালভাবে কাজ করে যখন এটি কয়েকটি দ্রুত চেক দিয়ে শেষ হয়:

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

যাচাই করতে, 2 থেকে 4 সপ্তাহের জন্য দুটি সহজ মেট্রিক ট্র্যাক করুন: রিভিউ সময় (ওপেন থেকে প্রথম মানানসই রিভিউ এবং ওপেন থেকে মার্জ) এবং রিওয়ার্ক (রিভিউয়ের পরে ফলো-আপ কমিট সংখ্যা বা কতগুলো কমেন্ট কোড পরিবর্তন করেছে)।

মানসম্পন্ন প্রম্পট স্ট্যান্ডার্ডাইজেশনকে হারাতে দেবেন না। একটি টেমপ্লেট বেছে নিন, একটি সংক্ষিপ্ত কনটেক্সট ব্লক (কি বদলেছে, কেন, কিভাবে টেস্ট করবেন) বাধ্যতামূলক করুন, এবং “ডান” মানে কি তা সম্মত হন।

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