আপনি ডেভেলপমেন্ট থামিয়ে রাখতে পারবেন না। এটাই প্রথম বিষয় যা আপনাকে মেনে নিতে হবে। টিকিট আসতে থাকে, গ্রাহকরা শিপমেন্টের অপেক্ষায় থাকে, এবং আপনার বিদ্যমান কোড শুধু আপনি ডকুমেন্টেশন করার সিদ্ধান্ত নিয়েছেন বলে থেমে যায় না। কোনো ইঞ্জিনিয়ারিং ম্যানেজার এক মাসের জন্য কাজ বন্ধ করার অনুমতি দেবেন না যাতে টিম এমন একটি স্পেসিফিকেশন লিখতে পারে যা প্রথম দিন থেকেই থাকা উচিত ছিল। OpenSpec বাস্তবতার জন্য তৈরি করা হয়েছে, কোনো কাল্পনিক স্বপ্ন বা 'greenfield fantasies'-এর জন্য নয়। এটি তখনই সবচেয়ে ভালো কাজ করে যখন আপনি আপনার বর্তমান সিস্টেমের সাথে এটিকে যুক্ত করেন, গ্রাহকসহ সবকিছু নিয়ে।

এখানে লক্ষ্য কোনো রিরাইট (rewrite) করা নয়। এটি হলো একটি সততাপূর্ণ প্রত্নতাত্ত্বিক অনুসন্ধান (honest archaeology)। আপনি প্রোডাকশনে আসলে যা চলছে তা খুঁজে বের করবেন, সেটিকে সঠিকভাবে বর্ণনা করবেন এবং আপনার কোড পরিবর্তনের সাথে সাথে সেই বর্ণনাকেও বিবর্তিত হতে দেবেন। যখন আপনার স্পেসিফিকেশন আপনার সিস্টেমের সাথে মিলে যায়, তখন আপনি পরবর্তী কোয়ার্টারে আসা ইঞ্জিনিয়ারদের এবং আপনার IDE-তে থাকা AI টুলগুলোর কাজ সহজ করে দেন। একটি মাত্র রিলিজ মিস না করেই এটি করার উপায় নিচে দেওয়া হলো।

যা আপনি আসলে করেন তা দিয়ে শুরু করুন

আপনার রিপোজিটরি (repository) খুলুন এবং আপনি controllers, models, services, এবং utils নামে ফোল্ডার দেখতে পাবেন। এগুলো হলো টেকনিক্যাল লেয়ার, এবং এগুলো আপনাকে বিভ্রান্ত করতে পারে। এগুলো আপনার সিস্টেম ব্যবসার জন্য কী কাজ করে তা বর্ণনা করে না। জাভাস্ক্রিপ্ট (JavaScript) ফাইল দিয়ে ভরা একটি ফোল্ডার এটি ব্যাখ্যা করতে পারে না যে কীভাবে একটি অর্ডার শিপমেন্টে রূপান্তরিত হয়। OpenSpec-কে মানানসই করতে হলে আপনাকে 'ক্যাপাবিলিটি' বা সক্ষমতার কথা চিন্তা করতে হবে।

এমন স্থিতিশীল ব্যবসায়িক কার্যক্রম খুঁজুন যা আপনি যদি পুরো স্ট্যাকটি অন্য কোনো ভাষায় পুনরায় লিখেন তবুও টিকে থাকবে। বেশিরভাগ প্রোডাক্ট কোম্পানিতে এগুলো বারবার দেখা যায়: Orders, Billing, Inventory, Customers, এবং Notifications। এই মূল সক্ষমতাগুলোর মধ্যে থেকে পাঁচটি থেকে আটটি বেছে নিন।

প্রতিটি সক্ষমতার জন্য নিজেকে পাঁচটি নির্দিষ্ট প্রশ্নের উত্তর দিতে বাধ্য করুন। এই সক্ষমতাটি কোন বাস্তব সমস্যার সমাধান করে? কোডটি আসলে কোথায় থাকে—একটি সার্ভিস, তিনটি মাইক্রোসার্ভিস, নাকি একটি লিগ্যাসি মডিউল যা কেউ স্পর্শ করতে চায় না? এটি কী দিয়ে ট্রিগার হয়: ইউজারের ক্লিক, একটি শিডিউল করা ক্রন জব (cron job), নাকি একটি ইনবাউন্ড ওয়েবহুক (inbound webhook)? কী ডেটা ইনপুট হিসেবে যায় এবং কী ডেটা আউটপুট হিসেবে আসে? এবং সবশেষে, অন্য কোন সিস্টেমগুলো এর ওপর নির্ভরশীল, অর্থাৎ এই অংশটি কাজ করা বন্ধ করলে কী ভেঙে পড়বে?

কঠোরভাবে সত্য বলুন। যদি আপনার "Customers" সক্ষমতাটি একটি Rails monolith, একটি Node API এবং একটি এক্সটার্নাল CRM-এর মধ্যে ছড়িয়ে থাকে, তবে ঠিক সেভাবেই তা লিখে ফেলুন। আপনার ম্যাপ বা মানচিত্রটি বাস্তবের মতো হতে হবে, কোনো আর্কিটেক্টের স্বপ্নের মতো নয়।

সত্য লিখুন, ইচ্ছার তালিকা নয়

যেকোনো ডকুমেন্টেশন প্রচেষ্টায় সবচেয়ে বিপজ্জনক বাক্য হলো, "যেহেতু আমরা এটি লিখছি, তাই আমরা এটি ঠিকও করে ফেলতে পারি।" থামুন। আপনি চেকআউট ফ্লো (checkout flow) নতুন করে ডিজাইন করছেন না। আপনি সেই চেকআউট ফ্লো বর্ণনা করছেন যা বর্তমানে আসল ক্রেডিট কার্ড দিয়ে পেমেন্ট প্রসেস করছে।

যদি একটি অর্ডার প্লেস করা একটি তাৎক্ষণিক পেমেন্ট ক্যাপচার ট্রিগার করে এবং তারপর একটি ব্যাকগ্রাউন্ড ওয়ার্কারের মাধ্যমে ইমেল পাঠায়, তবে ঠিক সেই সিকোয়েন্সটিই ডকুমেন্ট করুন। আপনি পরবর্তী কোয়ার্টারে যোগ করার পরিকল্পনা করছেন এমন কোনো ইভেন্ট কিউ (event queue) এখানে ঢুকিয়ে দেবেন না। ভ্যালিডেশন যদি আসলে একটি সার্ভিস ক্লাসের গভীরে থাকে, তবে সেটি API এজ-এ হচ্ছে বলে ভান করবেন না। আকাঙ্ক্ষার চেয়ে নির্ভুলতা অনেক বেশি গুরুত্বপূর্ণ।

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

আপনার API থেকে কন্ট্রাক্ট বের করে আনুন

আপনার API এন্ডপয়েন্টগুলো ইতিমধ্যেই নিয়ম প্রয়োগ করে। তারা শুধু সেগুলো পরোক্ষভাবে (implicit) রাখে। OpenSpec-কে মানানসই করার অর্থ হলো সেই নিয়মগুলোকে প্রকাশ্য করা।

ইনপুট এবং ভ্যালিডেশন দিয়ে শুরু করুন। এন্ডপয়েন্টটি আসলে কী গ্রহণ করে? টাইপ, প্রয়োজনীয় ফিল্ড, সর্বোচ্চ দৈর্ঘ্য এবং ক্রস-ফিল্ড ডিপেন্ডেন্সিগুলো ডকুমেন্ট করুন। তারপর ব্যবসায়িক আচরণ বর্ণনা করুন। এই কলটি কি একটি রেকর্ড তৈরি করে, কোনো সাইড ইফেক্ট ট্রিগার করে, নাকি কেবল অন্য একটি সার্ভিসের বিপরীতে স্টেট ভ্যালিডেট করে? সুনির্দিষ্ট হোন।

সবশেষে, রেসপন্সগুলো তালিকাভুক্ত করুন। সফল হলে কী রিটার্ন করে? সঠিক এরর কোডগুলো কী এবং কোন পরিস্থিতিতে সেগুলো দেখা দেয়? শুধু "returns an error" লিখবেন না। লিখুন "returns 422 when the billing address is missing and 409 when the inventory was already reserved by another process।" এই পর্যায়ের নির্ভুলতা একটি অস্পষ্ট রুটকে এমন একটি কন্ট্রাক্টে পরিণত করে যা ফ্রন্টএন্ড টিম, QA ইঞ্জিনিয়ার এবং অটোমেটেড টুলিং বিশ্বাস করতে পারে।

লুকানো নিয়মগুলো খুঁজে বের করুন

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

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

যখন আপনি এই নিয়মগুলোকে কেন্দ্রীভূত করেন, তখন আপনি শুধু এগুলোকে ডকুমেন্ট করেন না, বরং আরও বেশি কিছু করেন। আপনি ডুপ্লিকেশনগুলো চিহ্নিত করেন। আপনি দ্বন্দ্বগুলো উন্মোচন করেন। এবং আপনি পুরো টিমকে একটি নির্দিষ্ট জায়গা প্রদান করেন যেখানে পলিসি নিয়ে বিতর্ক করা যায়—যাতে কেউ এমন একটি এক লাইনের পরিবর্তন কমিট না করে যা ভুলবশত এমন একটি কনস্ট্রেইন্ট লঙ্ঘন করে যা আপনি ভুলে গিয়েছিলেন।

সিস্টেমের অভ্যন্তরীণ সংযোগচিত্র ম্যাপ করুন

আধুনিক সিস্টেমগুলো ইভেন্টের ওপর ভিত্তি করে চলে। একটি সার্ভিসে করা একটি কাজ ব্যবহারকারীর কাছে দৃশ্যমান হওয়ার আগে আরও আধা ডজন সার্ভিসের ওপর প্রভাব ফেলে। আপনার সেই প্রভাবগুলো চিহ্নিত করা প্রয়োজন। আপনার কোর ওয়ার্কফ্লোগুলোর জন্য একটি ইভেন্ট থেকে পরবর্তী ইভেন্টের প্রবাহ ম্যাপ করুন। 'Order created' থেকে 'inventory reserved' এবং তারপর 'payment confirmed' হওয়ার অপেক্ষায় থাকা—পুরো চেইনটি আঁকুন, এমনকি যদি কিছু লিঙ্ক ভঙ্গুর মনে হয় বা ভিন্ন প্রোটোকল ব্যবহার করে তবুও।

শুধুমাত্র অভ্যন্তরীণ ট্রাফিকের মধ্যেই থেমে থাকবেন না। আপনি সেগুলোকে সেভাবে বিবেচনা করুন বা না করুন, এক্সটার্নাল সার্ভিসগুলো আপনার সিস্টেমের অংশ। প্রতিটি ইন্টিগ্রেশনের জন্য এর উদ্দেশ্য, আপনার অ্যাপ্লিকেশন কীভাবে অথেন্টিকেট করে এবং এটি কীভাবে ফেইল করে তা রেকর্ড করুন। পেমেন্ট গেটওয়ে কি ৩০ সেকেন্ড পর টাইমআউট হয়ে একটি সাধারণ ৫০০ এরর রিটার্ন করে? শিপিং API কি সপ্তাহান্তে ম্যালফর্মড JSON রিটার্ন করে? আইডেন্টিটি প্রোভাইডার কি তার নিজস্ব ডকুমেন্টেশনে দাবি করা সময়ের আগেই রিফ্রেশ টোকেন রিভোক করে? এই ডিটেইলগুলো তুচ্ছ মনে হতে পারে