জেনারেটেড কোডকে রক্ষণযোগ্য রাখুন: বোরিং আর্কিটেকচার নিয়ম

জেনারেটেড কোডের রক্ষণাবেক্ষণ কেন কঠিন

জেনারেটেড কোড প্রতিদিনের কাজটা বদলে দেয়। আপনি শুধু ফিচার বানাচ্ছেন না, একটি সিস্টেম নির্দেশ দিচ্ছেন যা দ্রুত অনেক ফাইল তৈরি করতে পারে। গতি সুবিধাজনক, কিন্তু ছোট ছোট অসঙ্গতি দ্রুত বেড়ে ওঠে।

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

“চতুর” কাঠামো মহাব্যয়ী হয়ে ওঠে কারণ তা পূর্বানুমানযোগ্য নয়। কাস্টম প্যাটার্ন, গোপন ম্যাজিক, এবং জোরালো অ্যাবস্ট্র‍্যাকশন শুরুতে ঠিক মনে হতে পারে। ছয় সপ্তাহ পর, পরবর্তী পরিবর্তন ধীর হয় কারণ অপডেট করার আগে সেই কৌশল আবার শেখা লাগে। AI-সহায়তায় জেনারেশনে সেই চতুরতা ভবিষ্যত জেনারেশনের জন্য বিভ্রান্তিকর হতে পারে এবং যুক্তিযুক্ত লজিক ডুপ্লিকেট বা নতুন স্তর তৈরির দিকে নিয়ে যেতে পারে।

বোরিং আর্কিটেকচার বিপরীত: সাধারণ সীমা, সাধারণ নাম, স্পষ্ট ডিফল্ট। এটি পরিপূর্ণতার ব্যাপার নয়। এটি এমন একটি বিন্যাস বেছে নেওয়ার ব্যাপার যা ক্লান্ত সহকর্মী (বা ভবিষ্যতের আপনি) ৩০ সেকেন্ডে বুঝতে পারে।

সাধারণ লক্ষ্য: পরবর্তী পরিবর্তনকে সহজ করা, দারুণ দেখানো নয়। সাধারণত এর মানে প্রতিটি ধরনের কোডের জন্য একটিই পরিষ্কার জায়গা (UI, API, ডাটা, শেয়ার্ড ইউটিলিটি), ফাইলের কাজ অনুযায়ী অনুমানযোগ্য নাম, এবং অল্প “ম্যাজিক” যেমন অটো-ওয়্যারিং, গোপন গ্লোবাল বা মেটাপ্রোগ্রামিং এড়ানো।

উদাহরণ: যদি আপনি Koder.ai-কে “team invites” যোগ করতে বলেন, আপনি চান UI UI এলাকায় রাখুক, একটি API রুট API এলাকায় যোগ করুক, এবং ইনভাইট ডেটা ডাটা লেয়ারে রাখুক—নতুন ফোল্ডার বা প্যাটার্ন আবিষ্কার না করেই। সেই বোরিং কনসিস্টেন্সিই ভবিষ্যতের সম্পাদনাকে সস্তা রাখে।

বোরিং আর্কিটেকচার নিয়ম

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

আপনি দ্রুত এগুলো উত্তর দিতে সক্ষম হওয়া উচিত:

• এই ফিচারটা কোথায় থাকে?
• আমি নতুন ফাইল কোথায় রাখি?
• কী নামে রাখি?
• UI থেকে ডাটায় যাওয়ার সবচেয়ে সরল পথ কী?

নিয়ম

একটি সাধারণ স্ট্রাকচার বেছে নিন এবং প্রতিটি স্থানে তাতে লেগে থাকুন। যখন কোনো টুল (বা সহকর্মী) কোনো চতুর প্যাটার্ন সাজেস্ট করে, ডিফল্ট জবাব হোক “না” যদি না সেটা সত্যিই কোনো ব্যথা দূর করে।

টিকে রাখা বাস্তবসম্মত ডিফল্ট যা সময়ের সাথে টিকে থাকে:

• ফোল্ডার ও ফাইল প্রতি একটি দায়িত্ব। কোনো ফাইলের দুইটি পরিবর্তনের কারণ থাকলে সেটি ভাগ করে নিন।
• পূর্বানুমানযোগ্যতা নমনীয়তাকে হার মানায়। একই ধরনের জিনিস প্রতিবার একই জায়গায় রাখুন।
• আপনার স্ট্যাকের স্ট্যান্ডার্ড পদ্ধতিকে প্রাধান্য দিন কাস্টম মিনি-ফ্রেমওয়ার্কের ওপর।
• হ্যাপি পাথটি স্পষ্ট করুন। নতুন কনট্রিবিউটরকে সঠিক অবস্থান জিজ্ঞেস না করেই ধরে নেওয়া উচিত।
• “ম্যাজিক” প্রত্যাখ্যান করুন। লুকানো আচরণ, রিফ্লেকশন-ভারী কৌশল, এবং চতুর অ্যাবস্ট্র‍্যাকশন থেকে বিরত থাকুন।

একটি দ্রুত মানসিক পরীক্ষা

কল্পনা করুন একজন নতুন ডেভেলপার আপনার রিপো খুলে “Cancel subscription” বাটন যোগ করতে চায়। তাদের আগে কোনো কাস্টম আর্কিটেকচার শেখার দরকার হওয়া উচিত নয়। তাদের স্পষ্ট ফিচার অঞ্চল, একটি UI কম্পোনেন্ট, একটিমাত্র API ক্লায়েন্ট লোকেশন, এবং একটিমাত্র ডাটা অ্যাকসেস পথ খুঁজে পাওয়া উচিত।

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

এমন সরল ফোল্ডার সীমা যেগুলো স্কেল করে

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

একটি ছোট টপ-লেভেল লেআউট যা অনেক ওয়েব অ্যাপের জন্য মানায়:

• app/ স্ক্রিন, রাউটিং এবং পেজ-লেভেল স্টেট
• components/ পুনঃব্যবহারযোগ্য UI অংশগুলো
• features/ প্রতিটি ফিচারের জন্য একটি ফোল্ডার (billing, projects, settings)
• api/ API ক্লায়েন্ট কোড ও রিকোয়েস্ট হেল্পার
• server/ ব্যাকএন্ড হ্যান্ডলার, সার্ভিস এবং বিজনেস রুল

এটাতে সীমা স্পষ্ট: UI app/ ও components/-এ থাকে, API কল api/-এ যায়, এবং ব্যাকএন্ড লজিক server/-এ থাকে।

ডাটা অ্যাকসেসও বোরিং হওয়া উচিত। SQL কোয়েরি এবং রিপোজিটরি কোড ব্যাকএন্ডের কাছে রাখুন, UI ফাইল জুড়ে ছড়িয়ে না রাখুন। Go + PostgreSQL সেটআপে একটি সাধারণ নিয়ম: HTTP হ্যান্ডলার সার্ভিস কল করে, সার্ভিস রিপোজিটরি কল করে, রিপোজিটরি ডাটাবেসে কথা বলে।

শেয়ার্ড টাইপ এবং ইউটিলিটিজদের একটি পরিষ্কার ঘর প্রাপ্য, কিন্তু ছোট রাখুন। ক্রস-কাটিং টাইপ types/-এ রাখুন (DTOs, enums, shared interfaces) এবং ছোট হেল্পার utils/-এ (তারিখ ফরম্যাটিং, সহজ ভ্যালিডেটর)। যদি utils/ একটি দ্বিতীয় অ্যাপের মতো লাগতে শুরু করে, কোডটি সম্ভবত সংশ্লিষ্ট ফিচার ফোল্ডারে থাকা উচিত।

জেনারেটেড বনাম ম্যানুয়ালি লেখা কোড

জেনারেটেড ফোল্ডারগুলোকে প্রতিস্থাপনযোগ্য হিসেবে বিবেচনা করুন।

• জেনারেটেড আউটপুট generated/ (বা gen/)-এ রাখুন এবং সরাসরি এডিট করা এড়ান।
• কাস্টম লজিক features/ বা server/-এ রাখুন যাতে পুনঃজেনারেশন তা ওভাররাইট না করে।
• যদি জেনারেটেড আচরণ প্যাচ করতে হয়, সোর্স পরিবর্তনের বদলে সেটিকে র‍্যাপ (এডাপটার ফাইল) করুন।

উদাহরণ: যদি Koder.ai একটি API ক্লায়েন্ট জেনারেট করে, সেটি generated/api/-এ রাখুন, তারপর api/-তে পাতলা র‍্যাপার লিখুন যেখানে আপনি রিট্রাই, লগিং বা পরিষ্কার এরর মেসেজ যোগ করতে পারেন — জেনারেটেড ফাইল ছোঁয়াতে হবে না।

বিভ্রান্তি কমাতে নামকরণ কনভেনশন

জেনারেটেড কোড তৈরি করা সহজ এবং জমা হয় সহজে। নামকরণ এক মাস পরে পাঠযোগ্য রাখে।

একটি নামকরণ শৈলী বেছে নিন এবং মিশ্রিত করবেন না:

• ফোল্ডার ও ফাইল: kebab-case (user-profile-card.tsx, billing-settings)
• React কম্পোনেন্ট: PascalCase (UserProfileCard)
• ফাংশন ও ভেরিয়েবল: camelCase (getUserProfile)
• ধ্রুবক: SCREAMING_SNAKE_CASE (MAX_RETRY_COUNT)

রোলে করে নাম দিন, না যে এটা এখন কীভাবে কাজ করে তার উপর। user-repository.ts হলো একটি রোল। postgres-user-repository.ts হলো বাস্তবায়ন-বিশেষ যা পরিবর্তিত হতে পারে। শুধুমাত্র তখনই বাস্তবায়ন সাফিক্স ব্যবহার করুন যখন সত্যিই একাধিক বাস্তবায়ন থাকে।

misc, helpers বা বিশাল utils-এর মতো জাঙ্ক ড্রয়ার এড়িয়ে চলুন। যদি একটি ফাংশন এক ফিচারের জন্যই ব্যবহৃত হয়, সেটিকে ওই ফিচারের কাছে রাখুন। যদি শেয়ার্ড হয়, নামটাই ক্ষমতা বর্ণনা করুক (date-format.ts, money-format.ts, id-generator.ts) এবং মডিউল ছোট রাখুন।

নেভিগেশন দ্রুত করতে কনভেনশন

রুট, হ্যান্ডলার ও কম্পোনেন্ট একই প্যাটার্নে থাকলে সার্চ না করেই খুঁজে পাওয়া যায়:

• রুট: routes/users.ts পথগুলোর মতো /users/:userId
• হ্যান্ডলার (HTTP): handlers/users.get.ts, handlers/users.update.ts
• সার্ভিস (বিজনেস রুল): services/user-profile-service.ts
• ডাটা অ্যাকসেস: repositories/user-repository.ts
• UI কম্পোনেন্ট: components/user/UserProfileCard.tsx

আপনি যদি Koder.ai (বা কোনো জেনারেটর) ব্যবহার করেন, এই নিয়মগুলো প্রম্পটে দিন এবং সম্পাদনার সময় সঙ্গত রাখুন। উদ্দেশ্য হচ্ছে পূর্বানুমানযোগ্যতা: যদি আপনি ফাইল নাম অনুমান করতে পারেন, ভবিষ্যৎ পরিবর্তন সস্তা থাকবে।

চতুরতা-রহিত ডিফল্ট (বোধগম্য নীতিমালা)

জেনারেটেড কোড প্রথম দিনে দারুণ দেখাতে পারে এবং ত্রিশ দিনে কষ্ট দেয়। এমন ডিফল্ট বেছে নিন যা কোডটিকে স্পষ্ট করে, যদিও কিছুটা পুনরাবৃত্তিমূলক মনে হতে পারে।

ম্যাজিক কমানো দিয়ে শুরু করুন। ডাইনামিক লোডিং, রিফ্লেকশন-স্টাইল কৌশল, এবং অটো-ওয়্যারিং শুধু কারণ ১০ বা ২০ লাইন বাঁচবে তাই যোগ করবেন না। এই সব ফিচার আনার জায়গা লুকিয়ে রাখে এবং ডিবাগিং ও রিফ্যাক্টরিং ধীর করে।

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

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

দলের সামঞ্জস্য রাখতে কিছু নিয়ম:

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

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

যদি আপনি Koder.ai দিয়ে অ্যাপ জেনারেট করেন, শুরুতেই এই ডিফল্ট চাইতে বলুন: স্পষ্ট মডিউল ওয়্যারিং, কেন্দ্রীভূত কনফিগ, এবং এক রকম এরর প্যাটার্ন।

UI, API এবং ডাটার মধ্যে সীমারেখা

UI, API এবং ডাটার মধ্যে স্পষ্ট লাইন পরিবর্তনকে সীমাবদ্ধ রাখে। বেশিরভাগ রহস্যময় বাগ আসে যখন একটি লেয়ার অন্য লেয়ারের কাজ করতে শুরু করে।

UI: স্টেট দেখানো, ইনপুট সংগ্রহ করা

UI (প্রায়শই React) কে স্ক্রিন রেন্ডার ও UI-অনুকরণীয় স্টেট সীমাবদ্ধ রাখুন: কোন ট্যাব খোলা, ফর্ম এরর, লোডিং স্পিনার, এবং বেসিক ইনপুট হ্যান্ডলিং।

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

API: পাতলা, স্থিতিশীল শেপ

API লেয়ারটি পূর্বানুমানযোগ্য রাখুন। এটা HTTP অনুরোধকে বিজনেস কোডে অনুবাদ করে, তারপর ফলাফলকে স্থিতিশীল রিকোয়েস্ট/রেসপন্স শেপে রূপান্তর করে। ডাটাবেস মডেল সরাসরি ওয়্যার-এ পাঠাবেন না। স্থিতিশীল রেসপন্স আপনাকে অভ্যন্তরীণভাবে রিফ্যাক্টর করার সুযোগ দেয় UI ভাঙানো ছাড়া।

একটি সহজ পথ যা ভাল কাজ করে:

• UI টাইপ্ড রিকুয়েস্ট/রেসপন্স অবজেক্ট দিয়ে API ক্লায়েন্ট কল করে।
• API হ্যান্ডলার ইনপুট ভ্যালিডেট করে এবং একটি সার্ভিস মেথড কল করে।
• সার্ভিসগুলো বিজনেস রুল ও ওয়ার্কফ্লো ধরে রাখে।
• রিপোজিটরিজ ডাটাবেস কুয়েরি লুকায় ছোট মেথডের পেছনে।

ডাটা: কুয়ারিকে রিপোজিটরির পেছনে লুকান

SQL (বা ORM লজিক) একটি রিপোজিটরি সীমারেখার পেছনে রাখুন যাতে অ্যাপের বাকি অংশ ডাটার কীভাবে সংরক্ষিত হয় তা “জানে” না। Go + PostgreSQL-এ সাধারণত অর্থ UserRepo বা InvoiceRepo মতো রিপোজিটরি রাখুন ছোট, পরিষ্কার মেথড সহ (GetByID, ListByAccount, Save)।

কনক্রিট উদাহরণ: ডিসকাউন্ট কোড যোগ করা। UI একটি ফিল্ড রেন্ডার করে এবং আপডেট করা মূল্য দেখায়। API code নেয় এবং {total, discount} রিটার্ন করে। সার্ভিস সিদ্ধান্ত নেয় কোড বৈধ কিনা এবং কিভাবে ডিসকাউন্ট স্ট্যাক হবে। রিপোজিটরি প্রয়োজনীয় রো ফেচ ও পান।

ধাপে ধাপে: রক্ষণযোগ্য জেনারেটেড কোড সেটআপ করুন

জেনারেটেড অ্যাপ দ্রুত “সমাপ্ত” মনে হতে পারে, কিন্তু স্ট্রাকচারই ভবিষ্যতে পরিবর্তন সস্তা রাখে। আগে বোরিং নিয়ম ঠিক করুন, তারপর কেবল পর্যাপ্ত কোড জেনারেট করুন তা প্রমাণ করার জন্য।

একটি ব্যবহারিক সেটআপ ফ্লো

সংক্ষিপ্ত পরিকল্পনা দিয়ে শুরু করুন। যদি আপনি Koder.ai ব্যবহার করেন, Planning Mode-এ একটি ফোল্ডার মানচিত্র এবং কিছু নামকরণ নিয়ম লিখে নেওয়া ভাল।

তারপর এই ক্রম অনুসরণ করুন:

1. মানচিত্র ও নিয়ম লিখে নির্ধারণ করুন। সীমা বেছে নিন (উদাহরণ: ui/, api/, data/, features/) এবং কয়েকটি নামকরণ নিয়ম।
2. একটি পাতলা ভার্টিকাল স্লাইস জেনারেট করুন। একটি ছোট ফিচার নিন যা UI, API ও স্টোরেজকে স্পর্শ করে, যেমন “create a contact.” লক্ষ্য হলো অতি বিস্তৃত না হয়ে এন্ড-টু-এন্ড পথ তৈরি করা।
3. তারপরই রিফ্যাক্টর করুন যাতে সীমারেখাগুলোর সাথে মেলে। কোডগুলো পরিকল্পিত ফোল্ডারে সরান, অস্পষ্ট ফাইলের নাম বদলান, ও ডুপ্লিকেট মুছুন। সবকিছুকে UI, হ্যান্ডলার ও ডাটা অ্যাকসেসে ভাগ করুন।
4. আরেকটি ফিচার যোগ করে আকার পরীক্ষা করুন। অনুরূপ কিছু নিন, যেমন “list contacts.” যদি নিয়ম ভাঙতে চাপ পড়ে, সম্ভবত সীমারেখাগুলো ঠিক নয়।
5. শুরুতেই কনভেনশন লক করুন। একটি ছোট CONVENTIONS.md যোগ করুন এবং এটিকে একটি কনট্র্যাক্টের মতো বিবেচনা করুন। কোডবেস বড় হলে নাম এবং ফোল্ডার প্যাটার্ন বদলানো ব্যয়বহুল।

বাস্তবতা যাচাই: যদি নতুন মানুষ অনুমান না করে পারে “edit contact” কোথায় যোগ করতে হবে, তাহলে আর্কিটেকচার এখনও যথেষ্ট বোরিং নয়।

উদাহরণ পরিস্থিতি: কিচ্ছু না বাড়িয়ে ফিচার যোগ করা

ধরুন একটি সাধারণ CRM: контак্ট লিস্ট পেজ এবং একটি kontak্ট এডিট ফর্ম আছে। প্রথম ভার্সন দ্রুত বানানো হলো, তারপর এক সপ্তাহ পরে “tags” যোগ করতে হবে।

অ্যাপটিকে তিনটি বোরিং বক্স হিসেবে দেখুন: UI, API, ডাটা। প্রতিটি বক্স স্পষ্ট সীমা ও নাম পায় যাতে “tags” পরিবর্তন ছোট থাকে।

একটি পরিষ্কার লেআউট দেখতে এভাবে হতে পারে:

• web/src/pages/ContactsPage.tsx এবং web/src/components/ContactForm.tsx
• server/internal/http/contacts_handlers.go
• server/internal/service/contacts_service.go
• server/internal/repo/contacts_repo.go
• server/migrations/

এখন “tags” অনুমানযোগ্য। স্কিমা আপডেট করুন (নতুন contact_tags টেবিল বা tags কলাম), তারপর এক লেয়ার করে স্পর্শ করুন: repo ট্যাগ পড়া/লেখা করে, সার্ভিস ভ্যালিডেশন করে, হ্যান্ডলার ফিল্ড এক্সপোজ করে, UI রেন্ডার ও এডিট করে। হ্যান্ডলাই বা React কম্পোনেন্টে SQL ঢুকাবেন না।

টেস্ট ও ফিক্সচারগুলোর জন্য জিনিসগুলো ছোট ও কোডের কাছে রাখুন:

• server/internal/service/contacts_service_test.go যেমন নিয়মের জন্য “tag নাম প্রতিটি kontak্টে অনন্য হতে হবে”
• server/internal/repo/testdata/ ন্যূনতম ফিক্সচার জন্য
• web/src/components/__tests__/ContactForm.test.tsx ফর্ম আচরণের জন্য

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

সাধারণ ভুলভ্রান্তি যেগুলো ভবিষ্যৎ পরিবর্তন ব্যয়বহুল করে তোলে

জেনারেটেড কোড প্রথম দিনে পরিষ্কার দেখতে পারে, তবুও পরে ব্যয়বহুল হতে পারে। সাধারণ অপরাধী হচ্ছে অসামঞ্জস্যতা।

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

আরেকটি ফাঁদ হচ্ছে লেয়ার মিশ্রিত করা। যখন UI কম্পোনেন্ট ডাটাবেসে কথা বলে, অথবা API হ্যান্ডলার SQL বানায়, ছোট পরিবর্তনগুলো অ্যাপ জুড়ে ঝুঁকিপূর্ণ ইডিটে পরিণত হয়। সীমা রাখুন: UI API কল করে, API সার্ভিস কল করে, সার্ভিস ডাটা অ্যাকসেস কল করে।

প্রারম্ভিকভাবে অতিরিক্ত সার্বজনিক অ্যাবস্ট্র‍্যাকশনও খরচ বাড়ায়। একটি সার্বজনিক BaseService বা Repository ফ্রেমওয়ার্ক মজা করে, কিন্তু প্রথমের অ্যাবস্ট্র‍্যাকশনগুলো অনুমান। বাস্তবতা বদলালে আপনি নিজের ফ্রেমওয়ার্কের সঙ্গে লড়াই করবেন বুলেট-প্রমাণ সমাধান না দিয়ে কাজ শিপ করার বদলে।

নিয়মিত নাম পরিবর্তন ও পুনর্গঠন একটি শান্ত ঋণ সৃজন করে। যদি ফাইল প্রতি সপ্তাহে সরানো হয়, মানুষ আর লেআউটকে বিশ্বাস করে না এবং দ্রুত ফিক্সগুলো র‍্যান্ডম জায়গায় পড়ে। প্রথমে ফোল্ডার মানচিত্র স্থির করুন, তারপর পরিকল্পিতভাবে রিফ্যাক্টর করুন।

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

শিপ করার আগে একটি দ্রুত চেকলিস্ট

কেউ যদি নতুন করে রিপো খুলে, তাদের দ্রুত এক প্রশ্নের উত্তর দিতে হবে: “আমি এটা কোথায় যোগ করব?”

২-মিনিট নেভিগেশন টেস্ট

প্রজেক্টটি একটি সহকর্মী (বা ভবিষ্যতের আপনি) কে দিন এবং তাদের বলুন একটি ছোট ফিচার যোগ করতে, যেমন “signup form-এ একটি ফিল্ড যোগ করুন।” যদি তারা দ্রুত সঠিক জায়গা না পায়, তাহলে স্ট্রাকচার কাজ করছে না।

তিনটি পরিষ্কার হোম চেক করুন:

• UI পরিবর্তন একটির মতো স্পষ্ট স্থানে থাকে।
• UI থেকে API রুট/হ্যান্ডলার পাওয়া সহজ।
• ডাটা মডেল ও ডাটাবেস পরিবর্তনের একটি স্পষ্ট লোকেশন আছে।

রিভিউতে এনফোর্স করার মত নিয়ম

• UI, API, এবং ডাটা প্রত্যেকটিরই একটি বাড়ি আছে, এবং ব্যতিক্রম বিরল।
• নামগুলো লেবেলের মত পড়া যায়, ধাঁধার মতো নয়।
• লেয়ার ব্রেকগুলো ফ্ল্যাগ করা হয় (যেমন UI ডাটাবেসে পৌঁছে যাচ্ছে)।
• চতুর শর্টকাটগুলো ডিফল্টভাবে প্রত্যাখ্যাত হয়।

আপনার প্ল্যাটফর্ম যদি সমর্থন করে, রোলব্যাক পথ রাখুন। স্ট্রাকচারে পরীক্ষা করার সময় স্ন্যাপশট ও রোলব্যাক বিশেষভাবে উপকারী।

পরবর্তী পদক্ষেপ: বোরিং থাকুন, সস্তা থাকুন

রক্ষণযোগ্যতা দ্রুত উন্নত হয় যখন আপনি স্টাইল নিয়ে তর্ক বন্ধ করে কয়েকটি সিদ্ধান্ত নিয়ে ফেলেন যেগুলো অটল থাকবে।

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

তারপর একটি ক্লিনআপ পাস করে সেই নিয়মে মানানসই করুন এবং সাপ্তাহিকভাবে ক্রমবদল বন্ধ করুন। ঘন ঘন পুনরায় সংগঠন পরবর্তী পরিবর্তন ধীর করে, যদিও কোড সুন্দর দেখায়।

আপনি যদি Koder.ai (koder.ai) দিয়ে তৈরি করে থাকেন, এগুলো কনভেনশন হিসেবে স্টার্টিং প্রম্পটে সংরক্ষণ করে রাখলে প্রতিটি নতুন জেনারেশন একই স্ট্রাকচারে দাঁড়াবে। টুল দ্রুত হতে পারে, কিন্তু বোরিং সীমারেখাই কোডকে সহজে পরিবর্তনযোগ্য রাখে।