Claude Code greenfield workflow: খালি রিপো থেকে প্রথম স্লাইস

একটি greenfield শুরুতে আপনি কোন সমস্যা এড়াতে চান

শূন্য রিপো থেকে শুরু করা স্বাধীনতার মতো লাগে, কিন্তু প্রায়ই এটা বিশৃঙ্খলা হয়ে যায়: অনেক জেনারেট করা ফাইল, আংশিক কাজ করা বিল্ড, এবং পরবর্তী পরিবর্তনের জন্য কোনো পরিষ্কার জায়গা নেই। Claude Code greenfield workflow-এর উদ্দেশ্য হল প্রথম সপ্তাহের এই বিশৃঙ্খলা এড়ানো।

কয়েকটি ব্যর্থতা বারবার দেখা যায়:

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

শুরুতেই সিদ্ধান্ত বদলানো কষ্টকর হয় কারণ সব কিছু তার ওপর স্তরভিত্তিকভাবে জমে। একটি বিভ্রান্তিকর স্ট্রাকচার বারবার শক্ত হয়ে যায়। ম্যানুয়াল বিল্ড দশ ধরনের সেটআপে পরিণত হয়। যদি আপনি সরল dev কমান্ড দ্রুত লক না করেন, তাহলে বুঝতে পারবেন না কোন পরিবর্তন অ্যাপ ভেঙেছে নাকি শুধু এনভায়রনমেন্ট ভেঙেছে।

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

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

একটি কমান্ডে অ্যাপ চালাতে পারলে এবং এক ভের্টিক্যাল স্লাইস শিপ করতে পারলে, আপনার কাছে এমন একটি ভিত্তি থাকবে যাকে অনুমান ছাড়া ইটারেট করা যাবে।

জেনারেট করার আগে প্রথম স্লাইস সিদ্ধান্ত নিন

একটি স্পষ্ট প্রথম স্লাইস আপনার রিপোকে পরিপাটি রাখে এবং আপনার প্রম্পটকে লক্ষ্যভিত্তিক করে। এই মুহূর্তে আপনাকে নির্ধারণ করতে হবে কি end-to-end ডেমো করবেন, পুরো প্রডাক্ট কিভাবে হবে তা নয়।

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

সপ্তাহ ১ এর জন্য একটি লক্ষ্য প্ল্যাটফর্ম বেছে নিন এবং তাতে টিকে থাকুন। ওয়েব থেকে শুরু করলে, কেবল ওয়েব করুন। "হয়তো মোবাইলও যোগ করব" বলবেন না। পরবর্তীতে Koder.ai মতো প্ল্যাটফর্ম ব্যবহার করার পরিকল্পনা থাকলেও, প্রথম স্লাইস একটি লাইনে থাকলে ফল ভাল হবে (React web, অথবা Go API, অথবা Flutter)।

"সপ্তাহ ১-এ ডান হওয়া" কি তা সাধারণ ভাষায় নির্ধারণ করুন:

• এক কমান্ডে ফ্রেশ ক্লোন থেকে লোকালি চলে
• এক কাজ করা ফিচার যাকে end-to-end ক্লিক করা যায়
• ত্রুটিতে ব্যবহারকারীর জন্য মানুষের মতো বার্তা আসে (স্ট্যাক ট্রেস নয়)
• ডেটা কোথাও সহজেই স্থায়ী হয় (এven একটি লোকাল ডেটাবেস)

তারপর তিনটি নন-গোল লিখে নিন যা স্কোপকে রক্ষা করবে। উদাহরণ: কোন auth নেই, কোন থিম সিস্টেম নেই, কোন ব্যাকগ্রাউন্ড জব নেই।

যখন এই সিদ্ধান্তগুলো লেখা থাকবে, আপনার জেনারেশন প্রম্পট গঠন করে বলুন: কেবল সেই জিনিসগুলো তৈরি কর যা স্লাইসকে সাপোর্ট করে, এবং বাকিটা TODO হিসেবে রেখে দিন।

অগ্রিম কয়েকটি সিদ্ধান্ত যা পুনরায় কাজ কমায়

Claude-কে কিছু জেনারেট করার আগে কয়েকটি ডিফল্ট লক করে দিন। এগুলো ছোট মনে হলেও পরে "সবকিছু রিনেম" করার ঝামেলা কমায়।

প্রথমে অ্যাপের আকার ঠিক করুন। যদি সত্যিই ব্রাউজার UI এবং ব্যাকএন্ড দরকার হয়, তাহলে শুরুতে দুইটি পরিষ্কার অংশ রাখুন (frontend + API) এবং কনট্রাক্টের জন্য একটি শেয়ার্ড জায়গা (API টাইপ বা একটি সিম্পল স্কিমা)। যদি অ্যাপ একটি সার্ভার-রেন্ডারড ওয়েব অ্যাপ হতে পারে, তাহলে এক কোডবেসেই রাখুন যাতে লোকাল ডেভ সহজ থাকে।

পরেরটি কনফিগারেশন নিয়ম ঠিক করা। একটি লোকাল env ফাইল ব্যবহার করুন, এটিকে git থেকে বাইরে রাখুন, এবং একটি টেমপ্লেট কমিট করুন (উদাহরণ হিসেবে .env.example) নিরাপদ প্লেসবোল্ডার এবং সংক্ষিপ্ত মন্তব্য সহ। এটি অনবোর্ডিং সহজ করে এবং সিক্রেট লিক কমায়।

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

একটি সরল শুরু-সেট সিদ্ধান্ত:

• App shape: single app অথবা frontend + API
• Config: লোকালি .env, কমিট করা .env.example
• Ports: web, API, DB (প্রয়োজনে) এর জন্য আলাদা পোর্ট
• Names: ফোল্ডারগুলোর জন্য এক ধাঁচের কেসিং, সার্ভিস নামের ধারাবাহিকতা
• Secrets: কখনও কমিট করবেন না, প্রকাশিত হলে রোটেট করুন

উদাহরণ: আপনি web পোর্ট 3000 এবং api পোর্ট 8080 বেছে নিলেন। আপনার env টেমপ্লেটে API_URL=http://localhost:8080 এবং DATABASE_URL=... থাকবে। যখন Claude পরে স্ক্রিপ্ট এবং ডক্স জেনারেট করবে, সবকিছু জায়গায় বসে যাবে এবং ভাসতে থাকবে না।

Claude Code কে কিভাবে প্রম্পট করবেন যাতে সেটি সংগঠিত থাকে

রানযোগ্য স্ক্যাফোল্ড চেয়ে শুরু করুন, "পুরো অ্যাপ" না চাইলে দ্রুতেই বিশৃঙ্খলা আসবে। সবচেয়ে দ্রুত পথMessy output-এর কারণ হল ফিচার চাইতে শুরু করা আগে জায়গা না থাকা।

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

নিয়মগুলো প্রম্পটে সেট করে রাখলে ডিসিপ্লিন বজায় থাকে:

• প্রথমে সবচেয়ে ছোট runnable skeleton জেনারেট করুন (hello page, health endpoint, অথবা একটি স্ক্রিন)
• একটি ফোল্ডার স্ট্রাকচার প্রস্তাব করুন এবং প্রতিটি ফোল্ডারে ১ বাক্যে ব্যাখ্যা দিন
• স্ক্রিপ্ট যোগ করুন যা ফ্রেশ মেশিনে কাজ করে (install, dev, test, build) এবং পূর্বপ্রয়োজনীয়তা লিখে বলুন
• পরিবর্তনগুলো একটি PR-সাইজ চাঙ্কে রাখুন এবং ঠিক কোন ফাইল তৈরি বা সম্পাদিত হবে তা তালিকা করুন
• স্ক্যাফোল্ডিং-এর পরে থামুন এবং আমাকে কীভাবে চালাতে হবে বলুন

একটি পুনরায় ব্যবহারযোগ্য প্রম্পট যা আপনি কাস্টমাইজ করে ব্যবহার করতে পারেন:

You are working in an empty repo. Create a minimal runnable skeleton.

Constraints:
- Keep it small: no real features yet.
- Propose a clear folder structure and add brief comments in each folder’s README.
- Add scripts for: setup, dev, test, build. They must work on a fresh machine.
- Tell me exactly how to run it, and what output I should see.
- After generating, stop and wait for my “ran it” confirmation.

Output:
1) File tree
2) Key files (only)
3) Run instructions

তারপর লুপ টাইট রাখুন। একবারে পাঁচটা পরিবর্তন চাইবেন না। এক ছোট পরিবর্তন জেনারেট করুন, চালান, সঠিক ত্রুটি (বা সাফল্য) পেস্ট করুন, তারপর একটি মিনিমাল ফিক্স চাইুন। এই জেনারেট-রান-অ্যাডজাস্ট রিদম প্রজেক্টটিকে পূর্বানুমানযোগ্য রাখে এবং স্ট্রাকচার ভাসা কঠিন করে।

ধাপে ধাপে: শূন্য রিপো থেকে runnable skeleton

একটি প্রতিশ্রুতি দিয়ে শুরু করুন: যে কেউ রিপো ক্লোন করে এক কমান্ডে কিছু কাজ করে দেখতে পারবে। এটি আপনাকে একটি স্থিতিশীল বেস দেবে, তারপরে AI-কে আসল ফিচার যোগ করতে বলুন।

রিপো তৈরি করে ছোট README লিখুন যখন সবকিছু নতুন। ব্যবহারিক রাখুন: প্রয়োজনীয়তা, এক dev কমান্ড, এবং কিভাবে টেস্ট চালাবেন (যদিও টেস্ট এখন খালি হতে পারে)।

এরপর টপ-লেভেল লেআউট বেছে নিন যা আপনার অরুক চেইপ রিফ্লেক্ট করে।

যদি আপনি বহু ডিপ্লয়যোগ্য অংশ তৈরি করেন (উদাহারণ: frontend + API), একটি ওয়ার্কস্পেস লেআউট সাহায্য করতে পারে:

/
  apps/
  packages/
  scripts/
  docs/
  README.md

যদি একটি একক অ্যাপ তৈরি করেন, তা সহজ রাখুন এবং অতিরিক্ত লেভেল এড়িয়ে চলুন যতক্ষণ না প্রয়োজন।

এখন ন্যূনতম গার্ডরেইল যোগ করুন যাতে কোড ধারাবাহিক থাকে। একটি ফরম্যাটার এবং একটি লিন্টার বেছে নিন, তাদের ডিফল্ট গ্রহণ করুন, এবং একটি কনফিগ ফাইল যোগ করুন। লক্ষ্য হলো পরিষ্কার ডিফ, দিনের একে-বার।

ডেভেলপার অভিজ্ঞতা voorspelbaar করতে একটি কমান্ড রাখুন যা রিপো রুট থেকে সবসময় কাজ করে। একটি সহজ রূপ:

{
  "scripts": {
    "dev": "echo \"start dev server here\"",
    "build": "echo \"build here\"",
    "test": "echo \"tests here\"",
    "lint": "echo \"lint here\""
  }
}

যেন স্কেলিংয়ের আগে dev কমান্ডটি চালান, নিশ্চিত করুন এটি ক্লিনলি exit করে (বা একটি প্লেসহোল্ডার সার্ভার চালু করে), তারপর কেবল scaffolding সহ প্রথম commit করুন। যদি একজন টিমমেট (বা ভবিষ্যৎ আপনি) সেটআপটি স্ক্র্যাচ থেকে পুনরায় করতে পারে, তাহলে আপনি প্রথম স্লাইস তৈরি করার জন্য প্রস্তুত।

এমন একটি ফোল্ডার স্ট্রাকচার যা অ্যাপ বাড়ার সঙ্গে সাথে টিকে থাকে

একটি ভাল greenfield স্ট্রাকচার দুইটি কাজ করে: কোড দ্রুত খুঁজে পেতে সাহায্য করে, এবং Claude-কে প্রতিবার নতুন পছন্দ বানানো থেকে রোধ করে। লক্ষ্য নিখুঁততা নয়—স্থিতিশীলতা।

আপনি যদি একক অ্যাপের ভিতরে কাজ করেন (বা apps/<name>/ ফোল্ডারের ভিতরে), একটি সাধারণ ইন্টারনাল লেআউট বেশ ভালো থাকে:

• src/ অ্যাপ কোড (ফিচার, শেয়ার্ড অংশ, এন্ট্রি পয়েন্ট)
• config/ নন-সিক্রেট কনফিগ
• tests/ উচ্চ-লেভেল টেস্ট যেগুলো ব্যবহারকারীর আচরণ মত পড়ে
• scripts/ হেল্পার স্ক্রিপ্ট (ডেভ সেটআপ, db reset, release টাস্ক)
• docs/ ছোট নোট এবং চেকলিস্ট যা আপনি বাস্তবে রক্ষা করবেন

src/ এর ভিতরে, ফিচার কোড এবং শেয়ার্ড কোড আলাদা রাখুন পরিবর্তনের প্যাটার্ন অনুসারে। ফিচার কোড প্রায়ই বদলায় এবং কাছাকাছি থাকা উচিত। শেয়ার্ড কোড সাধারণ এবং পুনঃব্যবহারযোগ্য হওয়া উচিত।

একটি ব্যবহারিক নিয়ম: UI স্ক্রীন, হ্যান্ডলার, এবং ফিচার-নির্দিষ্ট লজিক src/features/<featureName>/... এ রাখুন। লগিং, API ক্লায়েন্ট, ডিজাইন সিস্টেম কম্পোনেন্ট, এবং জেনেরিক ইউটিলিটি src/shared/... এ রাখুন। যদি একটি হেল্পার কেবল এক ফিচারের জন্য মানানসই হয়, তা সেই ফিচারের ভিতরে রাখুন—even যদি তা পুনঃব্যবহারযোগ্য মনে হয়। দ্বিতীয় বাস্তব ব্যবহার পাওয়ার পরে বার করুন।

ফোল্ডার নামগুলো প্রযুক্তিকে নয় উদ্দেশ্য বর্ণনা করবে। "features" এবং "shared" আপনার স্ট্যাক বদলালে অর্থবহ থাকবে। "misc" বা "new" মতো নাম এড়িয়ে চলুন।

docs/ ছোট রাখুন। একটি ভাল স্টার্টার হলো docs/checklists.md যেখানে কিছু লাইন: কিভাবে চালাবেন, কিভাবে টেস্ট করবেন, কিভাবে নতুন ফিচার ফোল্ডার যোগ করবেন, এবং "ডান" মানে কি।

প্রজেক্টকে পূর্বানুমানযোগ্য করে দেওয়ার বিল্ড স্ক্রিপ্ট

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

একটু কমান্ড দিয়ে শুরু করুন এবং সেগুলোকে সাধারণ রাখুন। নতুন কেউ যোগ হলে (বা আপনি দুই সপ্তাহ পরে ফিরে আসলে) তাদের বিশেষ ফ্ল্যাগ বা লুকানো ধাপ প্রয়োজন না হওয়া উচিত।

আপনি যে কোনো স্ট্যাকে মানানসই করতে পারেন এমন একটি বেসলাইন:

{
  "scripts": {
    "dev": "node ./scripts/dev.js",
    "build": "node ./scripts/build.js",
    "test": "node ./scripts/test.js",
    "test:quick": "node ./scripts/test.js --quick",
    "test:full": "node ./scripts/test.js --full",
    "format": "node ./scripts/format.js",
    "lint": "node ./scripts/lint.js",
    "smoke": "node ./scripts/smoke.js"
  }
}

ডেভ স্ক্রিপ্টটিকে হ্যাপি পাথ বানান। এটি অ্যাপ চালু করবে, কোথায় চলছে তা দেখাবে, এবং লগ পড়তে সহজ রাখবে। সার্ভার স্টার্ট করতে না পারলে দ্রুত ফেল করবে এবং একটি পরিষ্কার বার্তা দেখাবে (মিসিং env var, পোর্ট নেওয়া আছে, ডাটাবেস পৌঁছায় না)।

বিল্ড স্ক্রিপ্ট সবসময় একটি ক্লিন আউটপুট ডিরেক্টরি তৈরি করবে। পুরানো আউটপুট মুছে দিন, তারপর নতুন আর্টিফ্যাক্ট তৈরি করুন। এটি গতকালের ফাইলের কারণে অদ্ভুত বাগ এড়ায়।

টেস্টগুলোর জন্য দ্রুত চেক এবং ধীরে চলা ফোল্ডার আলাদা করুন। দ্রুত টেস্টগুলো প্রতিটি চেঞ্জে চালবে (ইউনিট টেস্ট, টাইপ চেক)। ফুল টেস্ট ইন্টিগ্রেশন চেক অন্তর্ভুক্ত করবে এবং মার্জের আগে চালবে।

স্টাইল কনসিস্টেন্ট রাখুন একটি কমান্ড দিয়ে। একটি সাধারণ নিয়ম: format সমস্যা ঠিক করে, lint সমস্যাগুলো সম্পর্কে অভিযোগ করে।

সর্বশেষে, একটি স্মোক চেক যোগ করুন যা ডিবাগে সময় নষ্ট করার আগে মৌলিক বিষয়গুলো যাচাই করে:

• রিকোয়ার্ড env ভ্যার সেট আছে এবং খালি নয়
• নির্বাচিত পোর্টগুলো ফ্রি আছে
• অ্যাপ শুরু করে এবং একটি সহজ অনুরোধে সাড়া দেয়
• ডাটাবেস কানেকশন কাজ করে (যদি ব্যবহৃত হয়)
• build করার পর আউটপুট আছে

প্রথম ভের্টিক্যাল স্লাইস ফিচার তৈরি করা

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

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

একটি ভালো স্লাইসে চারটি অংশ থাকে: একটি রাউট/স্ক্রীন, একটি ফর্ম, একটি সেভ অ্যাকশন, এবং একটি প্রদর্শন। উদাহরণ: "New Task" পেজ একটি টাইটেল ইনপুট, একটি Save বোতাম যা একটি ফাংশন কল করে, এবং একটি লিস্ট যা সেভ করা টাস্কগুলো দেখায়।

দ্রুত এগোবার জন্য একটি প্লেসহোল্ডার স্টোর ব্যবহার করুন। একটি ইন-মেমরি অ্যারে, লোকাল JSON ফাইল, অথবা একটি সিম্পল স্টাব ইন্টারফেস ঠিক আছে। মূল বিষয় হলো একটি বর্ডার তৈরি করা যা পরে বদলানো সহজ হবে। যদি আজ আপনার কোড taskRepository.save(task) কল করে, পরে বাস্তব ডাটাবেসে স্যুইচ করা ছোট পরিবর্তন হয়ে যাবে, পূর্ণ-রিরাইট নয়।

UI সাদামাটা রাখুন। ডিজাইন সিস্টেম বিতর্ক, খালি স্টেট, অথবা অ্যানিমেশন বাদ দিন।

২ মিনিটে করা যেসব গ্রহণযোগ্যতা চেক:

• পেজ ত্রুটি ছাড়া খুলে
• আপনি একটি মান টাইপ করে Save চাপলে
• নতুন আইটেম তাৎক্ষণিকভাবে দেখায়
• রিলোড করলে প্রত্যাশিত আচরণ দেখা যায় (যদি বাস্তব স্টোরেজ হয় তাহলে স্থায়ী; নাহলে রিসেট)
• খারাপ ইনপুট হ্যান্ডেল হয় (খালি টাইটেল করলে একটি বার্তা দেখায় এবং সেভ করে না)

ইটারেট করার জন্য পর্যাপ্ত স্থির করা

একটি runnable skeleton এবং একটি ভের্টিক্যাল স্লাইস থাকলে লক্ষ্য বদলে যায়: ভাঙা স্পষ্ট করা এবং ফিক্স দ্রুত করা। এখানে অনেক greenfield শুরুর ব্যর্থতা ঘটে, কারণ ছোট পরিবর্তনগুলো অপ্রত্যাশিত সমস্যা শুরু করে।

প্রতি বার একটি স্লাইস যোগ করার সময় একটি ছোট স্থিতিশীলতা বার সেট করুন:

• একটি স্মোক টেস্ট যা প্রমাণ করে অ্যাপ বুট করে এবং মেইন রুট/স্ক্রীন রেন্ডার হয়
• একটি স্মোক টেস্ট যা স্লাইসটিকে end-to-end হিট করে (পরীক্ষা ডাটাবেস ব্যবহার করলেও)
• স্পষ্ট ত্রুটি বার্তা যা সাধারণ ব্যবহারকারী বুঝতে পারে (স্ট্যাক ট্রেস নয়)
• ডেভ লগ যা কি ঘটেছে ব্যাখ্যা করে কিন্তু সিক্রেট প্রিন্ট করে না
• ন্যূনতম ডিপেন্ডেন্সি, ভার্সন পিন করা, আপগ্রেড উদ্দেশ্য নিয়ে করা

কনক্রিট উদাহরণ: প্রথম স্লাইস ইউজারকে একটি "Project" তৈরি করতে দেয় এবং তালিকায় দেখায়। একটি টেস্ট যোগ করুন যা সার্ভার স্টার্ট করে, create endpoint কল করে, তারপর লিস্ট ফেচ করে চেক করে যে নতুন আইটেমটি আছে। ব্যর্থ হলে একটি সাহায্যকারী বার্তা দেয় যেমন "Create Project endpoint returned 500"।

ত্রুটি হ্যান্ডলিংয়ের জন্য একটি ছোট সেট কনসিস্টেন্ট রেসপন্স রাখুন। ভ্যালিডেশন ত্রুটি একটি সংক্ষিপ্ত বার্তা ("Name is required") এবং একটি ফিল্ড নাম ফেরত দিক। অপ্রত্যাশিত ত্রুটি বলুক "কিছু ভুল হয়েছে। পুনঃপ্রচেষ্টা করুন।" বিস্তারিত লগে রাখুন।

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

একটি ছোট হেলথ চেক যোগ করুন। ওয়েবে এটি একটি /health এন্ডপয়েন্ট হতে পারে যা ok রিটার্ন করে। মোবাইলে এটি "Connected" স্টেট হতে পারে যা ব্যাকএন্ড পৌঁছাতে না পারলে "Offline" এ যায়। ডিবাগের আগে এটি একটি দ্রুত সিগন্যাল।

AI ব্যবহার করে greenfield প্রজেক্টে সাধারণ ফাঁদ

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

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

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

যেসব ভুল সবচেয়ে বেশি পুনরায় কাজ করায়:

• একবারে এক runnable path না করে একাধিক সার্ভিস, স্ক্রিন, এবং কনফিগ জেনারেট করা
• প্রথম ফিচার end-to-end কাজ করার আগে auth, payments, জটিল স্টাইলিং, এবং সম্পূর্ণ ডাটা মডেল টেনে আনা
• সেটআপ নির্দেশনা চ্যাটে রেখে দেওয়া পরিবর্তে স্ক্রিপ্ট বা README-তে না রাখা
• একটি ক্লিন env টেমপ্লেট ভুলে যাওয়া, ফলে পরের মেশিন স্টার্ট করতে নিশ্চিত না

একটি সহজ উদাহরণ: আপনি একটি "complete" অ্যাপ জেনারেট করেন লগইন, থেমিং, বিলিং সহ, কিন্তু প্রথম রান ব্যর্থ হয় কারণ একটি সিক্রেট কী মিসিং এবং .env.example নেই। তখন আপনি এক ঘন্টা সেটআপ ঠিক করতে ব্যয় করেন, ফিচারের উপযোগিতা শেখার বদলে।

সৎ থাকুন: এক runnable কমান্ড, এক ছোট ফিচার, এক env টেমপ্লেট, তারপর ফেলে দিন।

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

আরও একটি ফিচার যোগ করার আগে নিশ্চিত করুন প্রজেক্টটি আগামীকাল (অথবা অন্য কেউ) সহজে তুলে নিতে পারবে। গতি একমাত্র লক্ষ্য নয়—পূর্বরূপানীয়তা।

• এক-কমান্ডে চালান: একজন নতুন ডেভ env টেমপ্লেট কপি করে কয়েকটি প্রয়োজনীয় মান সেট করে এবং এক কমান্ডে অ্যাপ চালাতে পারবে। যদি অতিরিক্ত ধাপ লাগে (DB সেটআপ, মাইগ্রেশন, সিড ডাটা), সেগুলোকে স্ক্রিপ্টে ধরুন।
• স্ক্রিপ্ট কভার করে বেসিক: dev, test, build, এবং একটি দ্রুত smoke চেকের স্পষ্ট কমান্ড।
• স্পষ্ট স্ট্রাকচার: লেআউটটি একটি গল্প বলে (অ্যাপ কোড, কনফিগ, স্ক্রিপ্ট, টেস্ট) পুরো কোডবেস না দেখে।
• ভের্টিক্যাল স্লাইস ডেমো পথ: আপনি একটি বাক্যে ডেমো বর্ণনা করতে পারবেন, যেমন "একটি আইটেম তৈরি করুন, তালিকায় দেখুন, রিফ্রেশ করুন, তা থাকবে।"
• রোলব্যাক পয়েন্ট: বড় পরিবর্তনের আগে একটি সেফ পয়েন্ট আছে (একটি ক্লিন কমিট, ট্যাগ, বা স্ন্যাপশট/রোলব্যাক মেকানিজম)।

যদি কোনো আইটেম ব্যর্থ হয়, এখনই ঠিক করুন। রিপো ছোট থাকলে স্ক্রিপ্ট ও নামকরণ টাইট করা সস্তা।

পরবর্তী পদক্ষেপ: ওয়ার্কফ্লোকে বারবারযোগ্য অভ্যাসে পরিণত করা

একটি greenfield শুরু কেবল তখনই মূল্যবান যখন আপনি এটি বারবার করতে পারেন। আপনার প্রথম ভের্টিক্যাল স্লাইস যখন end-to-end চলে, ভাল অংশগুলোকে একটি ছোট টেমপ্লেটে ফ্রিজ করুন: একই ফোল্ডার প্যাটার্ন, একই স্ক্রিপ্ট নাম, এবং UI, API, এবং ডেটা এক করতে একই উপায়।

আপনার প্রথম স্লাইসকে রেফারেন্স ইমপ্লিমেন্টেশন হিসেবে বিবেচনা করুন। যখন স্লাইস #2 শুরু করবেন, আকারটি কপি করুন, কোড নয়। যদি স্লাইস #1 এ একটি রুট, একটি হ্যান্ডলার, একটি ডাটা অ্যাক্সেস লেয়ার, এবং একটি বেসিক টেস্ট থাকে, স্লাইস #2 একই পথ অনুসরণ করবে।

পরিকল্পনা লাইটওয়েট রাখুন। পরবর্তী 2-3 স্লাইসের জন্য একটি পেজ নোট যথেষ্ট: প্রতিটি স্লাইসের লক্ষ্য ও ব্যবহারকারী অ্যাকশন (এক বাক্যে), দরকারি ডাটা, "ডান" চেক, এবং কোনো ঝুঁকি যা দ্রুত টেস্ট করা উচিত।

তারপর রক্ষণাবেক্ষণকে অভ্যাস করুন। সাপ্তাহিকভাবে একটি ছোট ক্লিনআপ পাস করুন: স্ক্রিপ্ট টাইট করুন, README-এ নতুন সেটআপ ধাপ যোগ করুন, এবং আপনার env উদাহরণ আপডেট করুন যাতে অনবোর্ডিং সহজ থাকে।

যদি আপনি চ্যাট-ফার্স্ট বিল্ড লুপ পছন্দ করেন, Koder.ai (koder.ai) একটি অপশন যা পরিকল্পনা মোড, স্ন্যাপশট এবং রোলব্যাক সাপোর্ট করে, এবং চাইলে সোর্স কোড এক্সপোর্ট করতে দেয়।

লক্ষ্য হচ্ছে এমন একটি ওয়ার্কফ্লো যা আপনি চিন্তা না করেই চালাতে পারেন: 2-3 স্লাইস পরিকল্পনা করুন, একটি স্লাইস বানান, স্থিতিশীল করুন, পুনরাবৃত্তি করুন।