এআই উন্নয়নে সময় বাঁচায় এমন মানব রিভিউ চেকপয়েন্ট

কেন ৫-মিনিট মানব রিভিউ এত সময় বাঁচায়

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

একটি চেকপয়েন্ট হলো আপনি কোনো পরিবর্তন গ্রহণ বা শিপ করার আগে সংক্ষিপ্ত মানব বিরতি। এটা কোনো মিটিং নয় এবং না কোনো দীর্ঘ QA সাইকেল। এটা একটি ইচ্ছাকৃত ৫-মিনিট স্ক্যান যেখানে আপনি জিজ্ঞেস করেন: যদি এটা ভুল হয়, সবচেয়ে কষ্টদায়ক কী ভেঙে পড়বে?

সবচেয়ে যন্ত্রণা দেয় এমন ক্লিনআপগুলো চারটি উচ্চ-আনুমানিক এলাকায় আসে:

• ডেটা স্কিমা: ভুল টাইপ, অনুপস্থিত কনস্ট্রেইন্ট, বিভ্রান্তিকর নাম, অনুপস্থিত ইনডেক্স।
• অথ এবং পারমিশন: ব্যবহারকারীরা যা করা উচিত নয় তা দেখতে বা সম্পাদনা করতে পারছে, অথবা অ্যাডমিনরা তাদের কাজ করতে পারছে না।
• বিনাশকারী অ্যাকশান: delete/overwrite/bulk update খুব সহজে চলে যাচ্ছে, ফেরত নেই।
• ডিপ্লয়মেন্ট সেটিংস: ভুল env vars, dev/prod ডেটা মিক্স, অসতর্ক সিক্রেট হ্যান্ডলিং, ডোমেইন কনফিগ ভুল।

একটি দ্রুত বিরতি সাহায্য করে কারণ এই সমস্যাগুলো ক্রস-কাটিং। একটি ছোট স্কিমা ভুল API, স্ক্রিন, রিপোর্ট এবং মাইগ্রেশনে ঢেউ তোলে। একটি পারমিশন ভুল সিকিউরিটি ইনসিডেন্টে পরিণত হতে পারে। একটি খারাপ ডিপ্লয় সেটিং ডাউনটাইম ঘটাতে পারে।

আপনি হাতে লিখে কোড করুন বা Koder.ai-এর মতো ভাইব-কোডিং টুল ব্যবহার করুন, নিয়ম একই: দ্রুত অগ্রসর হন, কিন্তু যেখানে ক্ষতি বড় সেখানে ছোট গার্ডরেইল যোগ করুন।

একটি সহজ ৫-মিনিট চেকপয়েন্ট রুটিন

চেকপয়েন্টগুলো সবচেয়ে ভাল কাজ করে যখন সেগুলো নিয়মিত। সবকিছু রিভিউ করবেন না। কেবল সেই জিনিসগুলো রিভিউ করুন যা উল্টো পাল্টা করা ব্যয়বহুল।

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

টাইমার ৫ মিনিট সেট করুন। সময় শেষ হলে থামুন। যদি আপনি বাস্তব ঝুঁকি পান, একটি বড়ো অনুসরণ সূচি নির্ধারণ করুন। না হলে আত্মবিশ্বাস নিয়ে শিপ করুন।

রুটিন

1. এক বাক্যে পরিবর্তনটি নাম করুন (এখন ব্যবহারকারী কী করতে পারবে)।
2. ব্লাস্ট রেডিয়াস চেক করুন (কোন ডেটা, রোল এবং পরিবেশ এতে স্পর্শ পায়)।
3. ঝুঁকিপূর্ণ প্রান্তগুলো স্ক্যান করুন (স্কিমা, অথ রুল, বিনাশকারী অ্যাকশন, ডিপ্লয় সেটিংস)।
4. একটি বাস্তবতা পরীক্ষা চালান (সর্বনিম্ন ফ্লো যা কাজ করে সেটি জুড়েই দেখান)।
5. ফয়সলা নিন: এগোনো, প্রম্পট ঠিক করে পুনরায় জেনারেট, অথবা রোলব্যাক।

একজন রিভিউয়ার ভূমিকা নিয়োগ করুন, এমনকি যদি সেটা "ভবিষ্যতের আপনি" হয়। এমন ভেবে কাজ করুন যেন আপনি এটি একটি সহকর্মীর কাছে অনুমোদন করছেন যাকে আপনি পরে বির্য করতে পারবেন না।

একটি ছোট টেমপ্লেট আপনাকে ধারাবাহিক থাকতে সাহায্য করবে:

Change:
Risky areas touched:
1 quick test to run:
Decision (proceed / adjust prompt / rollback):

আপনি যদি Koder.ai-এ নির্মাণ করছেন, উদ্দেশ্যটা শেষ ধাপে সহজ রাখুন। স্ন্যাপশট এবং রোলব্যাক "আমি নিশ্চিত নই" কে একটি নিরাপদ সিদ্ধান্তে পরিণত করে।

স্কিমা স্যানিটি: ডেটা সমস্যা আগেই ধরুন

দিন হারানোর দ্রুততম উপায় হলো এমন একটি ডাটাবেস স্কিমা মেনে নেওয়া যা কেবল "মোটামুটি" আপনার ইচ্ছে মত মেলে। ছোট ডেটা ভুলগুলো প্রতিটি স্ক্রীন, API এবং মাইগ্রেশনে ছড়িয়ে পড়ে।

শুরুতে দেখুন মূল এন্টিটিগুলো বাস্তব বিশ্বের সাথে মেলে কি না। একটি সাধারণ CRM সাধারণত Needs: Customers, Contacts, Deals, এবং Notes। যদি আপনি অস্পষ্ট নাম দেখেন যেমন "ClientItem" বা "Record", আপনি ইতোমধ্যেই ভ্রান্ত পথে যাচ্ছেন।

একটি পাঁচ-মিনিট স্কিমা স্ক্যান:

• নামগুলো বাস্তবতার সাথে মেলে: টেবিলগুলো সেই জিনিসগুলো প্রতিনিধিত্ব করে যেগুলো সম্পর্কে আপনি বাস্তবে কথা বলেন (users, invoices, subscriptions)।
• নামগুলো পাঠযোগ্য ও ধারাবাহিক: এক স্টাইল বেছে নিন এবং ঠিক রাখুন (created_at vs createdAt)।
• সম্পর্কগুলো সম্পূর্ণ: one-to-many যেখানে প্রযোজ্য এবং many-to-many যেখানে রোল বা মেম্বারশিপ গুরুত্বপূর্ণ।
• কনস্ট্রেইন্টগুলো ইচ্ছাকৃত: প্রয়োজনীয় ফিল্ডগুলো nullable নয়, যেখানে ডুপ্লিকেট ঠিকই লাগে সেখানে রোধ আছে (email, invoice_number), status ফিল্ডগুলোর একটি পরিচিত সেট আছে।
• বৃদ্ধি অ্যাপ ভেঙে দেবে না: সাধারণ লুকআপগুলোর ইনডেক্স আছে, এবং বড় ব্লবগুলো ভুল জায়গায় স্টোর করা হয়নি।

একটি ছোট উদাহরণ: একটি Invoices টেবিল যদি unique invoice_number ছাড়া থাকে ডেমোতে ঠিক মনে হতে পারে। এক মাস পরে ডুপ্লিকেট উঠবে, পেমেন্ট ভুল রেকর্ডে পড়বে, এবং আপনি ক্লিনআপ স্ক্রিপ্ট ও ক্ষমাসূচক ইমেল লিখতে বসবেন। রিভিউতে ধরলে এটা ৩০ সেকেন্ডেই ঠিক করা যায়।

যদি আপনি কেবল একটি প্রশ্ন জিজ্ঞেস করেন, এটি করুন: আপনি কি এই স্কিমা একটি নতুন সহকর্মীর সামনে দুই মিনিটে বুঝিয়ে দিতে পারবেন? যদি না পারেন, তার উপর নির্মাণ করার আগে সেটাকে শক্ত করুন।

অথ রুল: কে কী পারে এবং কীভাবে যাচাই করবেন

Auth বাগগুলো ব্যয়বহুল কারণ সুখপথ (happy-path) ডেমো সেগুলো লুকায়। দুটি সাধারণ ব্যর্থতা হলো "সবাই সব কিছুই করতে পারবে" এবং "কেউ কিছুই করতে পারবে না"।

রোলগুলো সহজ ভাষায় লিখুন: admin, staff, customer। অ্যাপ যদি টিম ধরে চলে, তাহলে workspace member এবং workspace owner যোগ করুন। যদি আপনি এক বাক্যে একটি রোল ব্যাখ্যা করতে না পারেন, নিয়মগুলো ছড়িয়ে যাবে।

তারপর একটি নিয়ম প্রয়োগ করুন: ডিফল্টভাবে কম অধিকার। নতুন রোলগুলো শুরু হোক কোনো এক্সেস ছাড়া বা কেবল readonly থেকে এবং ঠিক যা দরকার তা পেয়েই বাড়ুক। AI-জেনারেটেড কোড প্রায়ই পারমিশিভ শুরু করে কারণ তা টেস্ট পাস করায়।

দ্রুত যাচাই করতে একটি ছোট access matrix ব্যবহার করুন এবং UI ও API-তে সত্যিই চেষ্টা করে দেখুন:

• প্রতিটি রোলে প্রধান অবজেক্টগুলোর create/read/update/delete যাচাই করুন।
• ownership চেক করুন: ব্যবহারকারীরা শুধুই তাদের নিজের রেকর্ডই দেখুক যদি স্পষ্টভাবে শেয়ার করা না থাকে।
• একটি অনুমান-চেষ্টা করুন: অন্য একটি ব্যবহারকারীর আইটেম খুলতে ID বদলিয়ে দেখুন।
• নিশ্চিত করুন অ্যাডমিন-অনলি অ্যাকশানগুলো আসলেই অ্যাডমিন-অনলি (বিলিং, এক্সপোর্ট, ইউজার ম্যানেজমেন্ট)।
• "গোপন" অ্যাক্সেসগুলো মিস করবেন না: লিস্ট এন্ডপয়েন্ট, সার্চ, ডাউনলোড।

Ownership চেকগুলো বিশেষ নজর দাবি করে। "User can read Task" যথেষ্ট নয়। হওয়া উচিত: "user can read Task where task.ownerId == user.id" (বা ব্যবহারকারী ওয়ার্কস্পেসে আছে)।

এজ কেসগুলোই লিকের স্থান: আমন্ত্রিত কিন্তু গ্রহণ না করা ব্যবহারকারী, ডিলিট করা অ্যাকাউন্ট, পুরানো সেশন সহ সরানো ওয়ার্কস্পেস মেম্বার। একটি মিস হওয়া এজ কেসই এক সপ্তাহের ক্লিনআপে পরিণত হতে পারে।

আপনি যদি Koder.ai ব্যবহার করেন, অ্যাসিস্ট্যান্টকে রোলসমূহ এবং একটি access table আউটপুট করতে বলুন এবং তারপর প্রতিটি রোলের জন্য দুইটি টেস্ট অ্যাকাউন্ট দিয়ে যাচাই করুন।

বিনাশকারী অ্যাকশন: দুর্ঘটনাজনিত ডেটা লস প্রতিরোধ

বিনাশকারী অ্যাকশনগুলো ছোট ভুল থেকে কয়েক দিনের ক্লিনআপ পর্যন্ত যাওয়ার দ্রুততম পথ।

প্রথমে, এমন সবকিছু তালিকাভুক্ত করুন যা ডেটা মুছে বা ওভাররাইট করে। এটা কেবল delete বোতাম নয়। এটা reset, sync, import/replace, rebuild index, seed অ্যাকশন, এবং বিস্তৃত অ্যাডমিন টুলস।

কিছু স্পষ্ট সেফটি সিগন্যাল খুঁজুন:

• বিপজ্জনক অ্যাকশনের জন্য স্পষ্ট কনফার্মেশন (type-to-confirm সবচেয়ে ভালো)।
• স্কোপ সীমিত করা (এক রেকর্ড, এক ব্যবহারকারী, এক ওয়ার্কস্পেস), সহজ "all" নয়।
• কী করেছে এবং কে করেছে তা লগ করা।
• সেফ ডিফল্ট যেমন dry run, preview, বা delete-এর পরিবর্তে archive।

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

স্কিমা পরিবর্তনকেও সম্ভাব্য বিনাশকারী হিসেবে বিবেচনা করুন। কলাম ড্রপ করা, টাইপ বদলানো, এবং কনস্ট্রেইন্ট কষাকষি করা ডেটা হারিয়ে দিতে পারে এমনকি কেউ ডিলিট এন্ডপয়েন্ট কল না করলেও। যদি AI একটি মাইগ্রেশন প্রস্তাব করে, জিজ্ঞেস করুন: বিদ্যমান সারিগুলোর কি হবে, এবং কীভাবে আমরা তা পুনরুদ্ধার করব?

আপনি যদি রোলব্যাক প্ল্যান এক বাক্যে ব্যাখ্যা করতে না পারেন, তাহলে সেই বিনাশকারী পরিবর্তন শিপ করবেন না।

ডিপ্লয়মেন্ট সেটিংস: ছোট কনফিগ ভুল যা ব্যাথা দেয়

বেশিরভাগ ক্লিনআপ স্টোরি একইভাবে শুরু হয়: ডেভে অ্যাপ কাজ করেছে, তারপর প্রোডাকশন আলাদা আচরণ করল।

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

তারপর সিক্রেটগুলো দেখুন। যদি আপনি কনফিগ ফাইলে, প্রম্পটে, বা কমিট মেসেজে কী দেখেন, ধরে নিন তা লিক হবে। সিক্রেটগুলো ডেপ্লয় টাইমে ইনজেক্ট করা উচিত (env vars বা সিক্রেট ম্যানেজার)। প্রোডাকশনকে যদি প্রয়োজনীয় সিক্রেট মিস করে স্টার্ট না করতে পারে, তাহলে সেটা একটি খরচবহুল নীরব fallback-এর চেয়ে সস্তা ব্যর্থতা।

তারপর ব্রাউজার-ফেইসিং সেটিংস চেক করুন: allowed origins (CORS), redirect URLs, OAuth callback URLs। এগুলো প্রায়ই প্রায় সঠিক করা হয়, এবং এভাবেই আপনি কোড ঠিক থাকলেও "ব্রোকেন লগইন" ডিবাগ করতে বসেন।

একটি পাঁচ-মিনিট ডিপ্লয়মেন্ট চেক:

• ডেভ ও প্রোড আলাদা ডাটাবেস ও কী ব্যবহার করে।
• সিক্রেটগুলো হার্ডকোড নয়, ইনজেক্ট করা আছে।
• origins, redirects, এবং callbacks প্রকৃত ডোমেইনের সাথে মিলায়।
• কাস্টম ডোমেইন বেসিক ঠিক আছে (DNS সঠিক জায়গায় পয়েন্ট করছে, HTTPS প্রত্যাশিত)।
• প্রোডাকশন লগিং ও এরর রিপোর্টিং চালু আছে (কিন্তু সংবেদনশীল ডেটা লগ হচ্ছে না)।

আপনি যদি Koder.ai থেকে ডিপ্লয় করেন, এও নিশ্চিত করার সময় যে আপনি সঠিক পরিবেশ ডিপ্লয় করেছেন এবং রোলব্যাক উপলব্ধ আছে যদি কোনো কিছু ঠিক না লাগে।

মার্জের আগে ৬০-সেকেন্ড চেকলিস্ট

AI-জেনারেটেড পরিবর্তন গ্রহণ করে শিপ করার আগে এক মিনিট বিরতি নিন। আপনি স্টাইল রিভিউ করছেন না। আপনি তাদের ভুল খুঁজছেন যা বড় ক্লিনআপে পরিণত হয়।

• স্কিমা: এন্টিটিগুলো মানে কি? সম্পর্কগুলো সঠিক? কনস্ট্রেইন্ট আছে কি (unique, not null)? বৃদ্ধি কি কুয়েরি বা স্টোরেজ ভেঙে দেবে?
• অথ: কি এটা default-deny? আপনি কি প্রতিটি রিসোর্সের create/read/update/delete কে করতে পারে তা ব্যাখ্যা করতে পারবেন? ownership চেক সার্ভার-সাইডে আছে কি (শুধু UI তে নয়)?
• বিনাশকারী অ্যাকশন: অপরিবর্তনীয় অ্যাকশনের জন্য কনফার্মেশন আছে কি? যেখানে উচিত soft delete ব্যবহার করা হয়েছে কি? রোলব্যাক প্ল্যান আছে কি (স্ন্যাপশট, ব্যাকআপ, reversible migration)?
• ডিপ্লয়মেন্ট: ডেভ ও প্রোড আলাদা কি? সিক্রেটগুলো কোডে নেই? ডোমেইন ও রিডাইরেক্ট সঠিক?

একটি উদাহরণ: আপনি একটি "admin delete user" ফিচার মার্জ করেন। ৬০ সেকেন্ডে আপনি লক্ষ্য করবেন ব্যাকএন্ডে কোন রোল চেক নেই, কেবল একটি গোপন UI বাটন আছে। এক বাস্তব ব্যবহারকারী সরাসরি এন্ডপয়েন্ট কল করলেই এমনটি ঘটতে পারে। সেই এক টুকরা কেবল আপনার একটা ইনসিডেন্ট থেকে বাঁচায়।

একটি প্রশ্ন দিয়ে শেষ করুন যা বাস্তবতা জোর করে:

এখানে একটি বাস্তব ব্যবহারকারী খারাপভাবে কি করতে পারে, জানি বা ভুল করে?

যদি উত্তরটিতে থাকে “অন্যদের ডেটা মুছে ফেলা”, “প্রাইভেট রেকর্ড দেখা”, বা “প্রোডাকশন ভাঙা”, তাহলে থামুন এবং পরিবর্তনটা শক্ত করুন।

উদাহরণ: একটি ৫-মিনিট রিভিউ যা এক সপ্তাহের ক্লিনআপ প্রতিরোধ করেছে

আপনি একটি ছোট CRM নির্মাণ করছেন এবং AI টুলকে একটি "Delete customer" বাটন যোগ করতে বলেন। কয়েক মিনিটে এটা UI, একটি ব্যাকএন্ড এন্ডপয়েন্ট, এবং সম্পর্কিত রেকর্ড মুছে ফেলার জন্য একটি ডাটাবেস পরিবর্তন জেনারেট করে।

সবকিছু কাজ করছে মনে হয়: বাটন দেখা যায়, রিকোয়েস্ট 200 রিটার্ন করে, এবং কাস্টোমার লিস্ট থেকে মুছে যায়। অনেক দল এগিয়ে চলে।

একটি ৫-মিনিট রিভিউ দুইটি সমস্যা ধরেছে:

1. ডাটাবেস পরিবর্তনটি cascade delete ব্যবহার করে যা invoices এবং activity logs-ও মুছে দেয়। টেস্ট ডেটার জন্য ঠিক থাকতে পারে, কিন্তু বাস্তব CRM-এ এটি রিপোর্টিং, অডিট ও কাস্টমার ইতিহাস ভেঙে দেয়।
2. এন্ডপয়েন্ট কেবল চেক করে যে ব্যবহারকারী সাইন ইন আছে; অ্যাডমিন রোল চেক নেই। কোনো স্টাফ সদস্য যেকোন কাস্টোমার মুছে ফেলতে পারবে।

একটি দ্রুত রিভিউ বাস্তবে করায়:

• নন-অ্যাডমিন টেস্ট ইউজার হিসেবে বাটন ক্লিক করে দেখুন এটি ব্যর্থ করে কি না।
• এন্ডপয়েন্ট চেক করে নিশ্চিত করুন এটি অননুমোদিত ব্যবহারকারীকে রিজেক্ট করে।
• স্কিমা স্ক্যান করে দেখুন invoices, notes এবং logs-কে কি হবে।
• UI কনফার্মেশন করছে কি এবং কি মুছে যাবে তা দেখায় কি।
• যাচাই করুন আপনি সঠিক ডাটাবেসে টেস্ট করছেন কি না আগে চেষ্টা করার।

একটি প্রম্পট টুইক শিপ হওয়ার আগে এটা ঠিক করে দেয়:

“Make delete customer a soft delete. Keep invoices and logs. Only admins can delete. Add a confirmation step that requires typing DELETE. Return a clear error message when unauthorized.”

পুনরাবৃত্তি এড়াতে প্রকল্প নোটে তিনটি জিনিস ডকুমেন্ট করুন: delete নিয়ম (soft vs hard), permission requirement (who can delete), এবং প্রত্যাশিত সাইড ইফেক্টগুলো (কোন সম্পর্কিত ডেটা থাকে)।

পরিবর্তন গ্রহণের আগে স্পষ্টতা জোর করার জন্য প্রম্পট

AI আউটপুট আত্মবিশ্বাসী শোনায় কিন্তু অনুমান লুকিয়ে রাখতে পারে। লক্ষ্য হলো সেই অনুমানগুলো দৃশ্যমান করা।

যেসব শব্দগুলো ফলো-আপ প্রশ্ন ট্রিগার করা উচিত: “assume”, “default”, “simple”, “should”, “usually”. এগুলো প্রায়ই মানে “আমি কিছু বেছে নিয়েছি নিশ্চিত না হয়ে যে এটা আপনার অ্যাপের জন্য ঠিক আছে।”

উপযোগী প্রম্পট প্যাটার্ন:

“Rewrite your proposal as acceptance criteria. Include: required fields, error states, and 5 edge cases. If you made assumptions, list them and ask me to confirm.”

আর দুটি প্রম্পট যা ঝুঁকি দ্রুত উন্মোচন করে:

• “Show the data model changes as a before/after table. For each field: type, nullability, default, and migration risk.”
• “List all destructive operations you introduced (drop table/column, delete endpoints, cascade rules). For each, show how to undo it and what data is lost.”

Auth-এর জন্য:

“Show roles and permissions for each API route and UI action. For every role: allowed actions, denied actions, and one example request that should fail.”

নির্ধারণ করুন কী সবই মানব-ভেরিফাই করা উচিত, এবং তা সংক্ষিপ্ত রাখুন:

• Auth rules এবং অ্যাডমিন অ্যাকশন
• ডিলিট, cascade, অপরিবর্তনীয় মাইগ্রেশন
• এনভায়রনমেন্ট ও ডিপ্লয়মেন্ট সেটিংস (prod vs staging)
• পেমেন্ট, ইমেল এবং ইউজার-ডেটা ফ্লো
• রোলব্যাক প্ল্যান (স্ন্যাপশট বা রিলিজ পয়েন্ট)

যেসব সাধারণ ভুলগুলো কয়েক দিনের ক্লিনআপ বানায়

বেশিরভাগ দীর্ঘ ক্লিনআপ একই ছোট সিদ্ধান্ত থেকে শুরু হয়: আউটপুটকে বিশ্বাস করা কারণ এটা এখন কাজ করছে।

“It works on my machine” হলো ক্লাসিক ফাঁদ। একটি ফিচার লোকাল টেস্ট পাস করলেও বাস্তব ডেটা সাইজ, বাস্তব পারমিশন বা একটু আলাদা পরিবেশে ব্যর্থ হতে পারে। ফিক্সটি জরুরি প্যাচগুলোর গচ্ছে পরিণত হয়।

স্কিমা ড্রিফট আরেকটি চুম্বক। টেবিলগুলো নাম, কনস্ট্রেইন্ট এবং ডিফল্ট ছাড়া বিকশিত হলে এক-অফ মাইগ্রেশন ও অদ্ভুত ওয়ার্কঅ্যারাউন্ড তৈরি হয়। পরে কেউ জিজ্ঞেস করলে “status মানে কী?” আর কেউ উত্তর দিতে পারছে না।

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

বিনাশকারী অ্যাকশন সবচেয়ে বড় দূর্ঘটনা ঘটায়। “Delete project” বা “reset database” সহজে বাস্তবায়নযোগ্য এবং সহজে অনুতপ্ত হয়ে যায় যদি soft delete, স্ন্যাপশট বা রোলব্যাক প্ল্যান না থাকে।

কয়েকটি পুনরাবৃত্ত কারণ যা বহু-দিনের ক্লিনআপ দেয়:

• কনস্ট্রেইন্ট বিহীন স্কিমা পরিবর্তন (unique, not null, foreign keys)
• UI-শুধু পারমিশন নিয়মের বদলে সার্ভার-সাইড চেক না থাকা
• কনফার্মেশন ও রিকভারি ছাড়া delete এন্ডপয়েন্ট
• স্টেজিং ও প্রোডাকশনকে “প্রায় একই” মনে করা
• কে কি পরিবর্তন করেছে তার কোনো রেকর্ড না রাখা

পরবর্তী ধাপ: চেকপয়েন্টগুলোকে আপনার নির্মাণ প্রক্রিয়ার অংশ করুন

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

একটি হালকা রিদম:

• নির্মাণের আগে: ডেটা আকার (টেবিল, কী ফিল্ড) এবং রোলগুলো চূড়ান্ত করুন (কে read/create/update/delete করতে পারে)।
• মার্জের আগে: auth, বিনাশকারী অ্যাকশন, এবং প্রোডাকশন ডেটাকে স্পর্শ করা যেকোনো কিছুর জন্য ৬০-সেকেন্ড রিভিউ করুন।
• ডিপ্লয়ের আগে: পরিবেশ সেটিংস (ডোমেইন, সিক্রেট, ইমেইল, স্টোরেজ, রিজিয়ন) লক্ষ্য পরিবেশের সাথে মিলিয়ে নিন।
• ডিপ্লয়ের পরে: একটি বাস্তব ব্যবহারকারীর ফ্লো end-to-end চালান।

আপনি যদি Koder.ai-এ কাজ করেন, এর planning mode “নির্মাণের আগে” চেকপয়েন্ট হিসেবে কাজ করতে পারে: পরিবর্তন জেনারেট করার আগে সিদ্ধান্তগুলো লেখে রাখুন যেমন “orders শুধুমাত্র সাইন-ইন করা ব্যবহারকারী তৈরি করতে পারবে, কিন্তু status পরিবর্তন শুধুমাত্র অ্যাডমিনই করতে পারবে।” স্ন্যাপশট ও রোলব্যাকও নিশ্চিত করে যে “আমি নিশ্চিত নই” হওয়াই রিভার্ট করার কারণ হতে পারে, তারপর একটি পরিষ্কার প্রম্পট দিয়ে পুনরায় জেনারেট করুন।

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