বিচক্ষণ ডেভেলপার নতুন প্রজেক্টে কীভাবে কাজ করে

একজন বিচক্ষণ ডেভেলপার «কোডিং শুরু করে আশা» করে না। তারা নতুন প্রজেক্টকে brainstorming, দলের আলোচনা, প্রোটোটাইপিং, ডায়াগ্রাম, প্রস্তাব, ADR, MR/PR এবং GitOps দিয়ে এগিয়ে নিয়ে যায় — Review Bot স্বয়ংক্রিয়ভাবে PR কমেন্ট তৈরি করে যাতে মানুষ গুরুত্বপূর্ণ বিষয়ে সময় দেয়। এটিই production-grade playbook। FDE সিস্টেম তুলতে পারে; Claude Architect Certification মূল্যবান যদি আপনি এটি ডিজাইন ও রক্ষা করতে চান।

1. নতুন প্রজেক্টে «বিচক্ষণ» মানে কী

বিচক্ষণতা আরও মিটিং নয়। এটি তাড়াতাড়ি সস্তা শেখা এবং দেরিতে ব্যয়বহুল ভুল দুর্লভ করা। নিচের ক্রম এমন যে প্রতি ধাপ পরের blast radius কমায়:

Brainstorm → Discuss → Prototype → Diagram → Propose → ADR
        → Implement in small slices → MR/PR + Review Bot → Merge
        → GitOps promote (dev → staging → prod) → Observe → Iterate

ধাপ শুধু ইচ্ছাকৃতভাবে এড়িয়ে যান (যেমন এক-লাইন config fix)। Production পৌঁছাতে পারে এমন যেকোনো কিছুতে Review Bot + CI কখনো এড়িয়ে যাবেন না।

2. Brainstorming (আগে একা, তারপর কাঠামোবদ্ধ)

কারও সময় চাওয়ার আগে ৩০–৯০ মিনিট একা ব্যয় করুন:

• ফলাফল: শেষ হলে কোন ব্যবহারকারী/ব্যবসা পরিবর্তন সত্য হতে হবে?
• সীমাবদ্ধতা: সময়, বাজেট, compliance, বিদ্যমান প্ল্যাটফর্ম, দলের দক্ষতা।
• অ-লক্ষ্য: v1-এ আমরা কী করব না (scope রক্ষা করে)।
• ঝুঁকি: ডেটা, নিরাপত্তা, পারফরম্যান্স, vendor lock-in, অপারেশনাল লোড।
• সাফল্য মেট্রিক্স: latency, error rate, adoption, cost — দুটি বেছে নিন যা গুরুত্বপূর্ণ।

এটি ছোট নোটে ধরুন (Notion/Confluence/রেপোতে docs/ideas/ markdown)। লিখিত artifact ছাড়া brainstorming শুধু বাষ্পীভূত কথোপকথন।

3. সহকর্মীদের সাথে আলোচনা

সবচেয়ে ছোট উপযোগী বৃত্ত আমন্ত্রণ করুন: একজন peer যিনি আপনার সাথে implement করবেন, সংলগ্ন সিস্টেমের মালিক, এবং (প্রয়োজনে) security বা SRE। বিচক্ষণ রাখার নিয়ম:

• Time-box (২৫–৪৫ মিনিট)। সিদ্ধান্ত বা খোলা প্রশ্নে শেষ করুন — vibes নয়।
• বিকল্পে মতবিরোধ, মানুষে নয়। «option A vs B vs defer» জোর করুন।
• একজন scribe নিয়োগ করুন। নোট প্রস্তাবের বীজ হয়ে ওঠে।
• নীরব veto নয়। কেউ অস্বস্তিতে থাকলে পরে ADR-এ উদ্বেগ ঝুঁকি হিসেবে লিখুন।

Asyncও কাজ করে: ছোট RFC কমেন্ট থ্রেড প্রায়ই মিটিংয়ের চেয়ে ভালো — কিন্তু কাউকে লুপ বন্ধ করতেই হবে।

4. প্রোটোটাইপিং (মেয়াদসহ spikes)

অনিশ্চয়তা বেশি হলে প্রোটোটাইপ করুন: নতুন API, অপরিচিত ক্লাউড সার্ভিস, পারফরম্যান্স প্রশ্ন, বা AI/agent আচরণ। বিচক্ষণ নিয়ম:

1. টিকেটে একে spike নাম দিন; ক্যালেন্ডার stop সেট করুন (সাধারণত ১–৩ দিন)।
2. কোড throwaway ব্রাঞ্চ বা spikes/ ফোল্ডারে রাখুন; polish করবেন না।
3. ১০ বুলেটে শেখা লিখুন — বিশেষত যা ব্যর্থ হয়েছে।
4. সিদ্ধান্ত: promote (পণ্যে refactor), rewrite, বা abandon।

ADR ছাড়া চুপচাপ production হওয়া প্রোটোটাইপ দিয়ে দল accidental architecture উত্তরাধিকার পায়।

5. ডায়াগ্রাম (তর্কের জন্য যথেষ্ট)

UML উপন্যাস লাগে না। তিনটি স্কেচ পছন্দ করুন যা প্রত্যেকটি এক স্ক্রিনে মাপে:

ডায়াগ্রাম	উত্তর দেয়
Context (C4 L1)	কে কীসের সাথে কথা বলে? Trust boundaries?
Sequence	Happy path + একটি failure path
Deployment	কোথায় চলে; config ও secrets কীভাবে প্রবাহিত হয়

Mermaid বা ছবি প্রস্তাবের পাশে রাখুন (docs/architecture/)। ADR বদলালে ডায়াগ্রাম আপডেট করুন — পুরনো ছবি না থাকার চেয়ে খারাপ।

6. প্রস্তাব (হালকা RFC)

ভালো প্রস্তাব এক থেকে তিন পৃষ্ঠা:

1. সমস্যা এবং কেন এখন
2. বিবেচিত বিকল্প (কমপক্ষে দুটি)
3. সুপারিশ এবং কেন
4. প্রভাব: নিরাপত্তা, খরচ, ops, migration
5. Rollout ও rollback
6. খোলা প্রশ্ন

স্পষ্ট deadline সহ review চান। অনুমোদন (বা সংশোধনসহ) পরে সিদ্ধান্তকে ADR করুন — «source of truth» চ্যাটে রাখবেন না।

7. ADR — Architecture Decision Records

ADR সিদ্ধান্তের ছোট, convention অনুযায়ী অপরিবর্তনীয় রেকর্ড। টেমপ্লেট:

# ADR-00XX: Title

Status: Proposed | Accepted | Superseded by ADR-00YY
Date: YYYY-MM-DD
Deciders: @alice @bob

## Context
What forces are in play?

## Decision
What we will do.

## Consequences
Positive, negative, and follow-ups.

## Alternatives considered
Option A — why not
Option B — why not

ADR git-এ রাখুন (docs/adr/)। PR থেকে লিঙ্ক করুন। ইতিহাস rewrite না করে supersede করুন — ভবিষ্যতের আপনার trail দরকার।

8. MR ও PR — delivery-এর একক

MR (Merge Request, GitLab) এবং PR (Pull Request, GitHub/Bitbucket) একই ধারণা: reviewable change set। বিচক্ষণ অভ্যাস:

• ছোট: আদর্শত meaningful diff <৪০০ লাইন; vertical slices-এ ভাগ করুন।
• এক intent: একটি feature, fix, বা chore — «misc» নয়।
• বিবরণ: কেন, কীভাবে পরীক্ষা, screenshots/logs, ঝুঁকি, rollback।
• লিঙ্ক: ticket + ADR + design diagram।
• আগে Draft যখন আগে ফিডব্যাক চান কিন্তু «ready to merge» বোঝাতে চান না।
• কখনো force-merge নয় লাল CI বা unresolved high-severity bot findings ঘিরে লিখিত exception ছাড়া।

উদাহরণ PR body checklist

## Summary
- …

## Test plan
- [ ] Unit tests
- [ ] Manual path …
- [ ] Feature flag / config …

## Risk & rollback
- Risk: …
- Rollback: revert this PR / GitOps revert commit …

## References
- ADR-00XX
- Ticket ABC-123

9. Review Bot ব্যবহার — স্বয়ংক্রিয় PR কমেন্ট

Review Bot স্বয়ংক্রিয় reviewer যা প্রতিটি MR/PR-এ inline কমেন্ট ও সারাংশ পোস্ট করে। এটি মানুষ প্রতিস্থাপন করে না; বিরক্তিকর ও বিপজ্জনককে আগে আনে।

9.1 Bot কীতে কমেন্ট করবে

• Security: injection, authz ফাঁক, secret leakage, অসুরক্ষিত defaults
• Correctness: null paths, race conditions, ভাঙা migrations
• Tests: নতুন ব্রাঞ্চে missing coverage, snapshot অপব্যবহার
• API/contract: version bump ছাড়া breaking changes
• Ops: missing timeouts, idempotency নেই, unbounded retries
• Style শুধু যখন formatter/linter এড়িয়ে গেছে (শব্দ এড়ান)

9.2 ডেভেলপার জীবন কীভাবে সহজ করে

1. লেখক PR খোলে → bot সেকেন্ড থেকে মিনিটে চলে।
2. লেখক মানুষ চাওয়ার আগে bot থ্রেড ঠিক করে বা জবাব দেয়।
3. মানব reviewer bot সারাংশ পড়ে + ডিজাইন ও পণ্য ঝুঁকিতে মনোযোগ দেয়।
4. কম «nit» রাউন্ড; দ্রুত merge; মিস করা footguns থেকে কম শুক্রবার-রাতের ঘটনা।

9.3 সাধারণ setup বিকল্প

পদ্ধতি	নোট
SaaS Review Bot (যেমন CodeRabbit, vendor bots)	দ্রুত চালু; severity ও path ফিল্টার টিউন করুন
Cursor Bugbot / IDE-লিঙ্কড review	Cursor-কেন্দ্রিক দলে PR diffs-এ শক্তিশালী
Custom GitHub Action + Claude / LLM	পূর্ণ নিয়ন্ত্রণ; prompt + policy + cost caps লাগে
স্তরীকৃত pipeline (lint → SAST → LLM)	সেরা production posture — AI code review pipeline গাইড দেখুন

9.4 নীতি যা botকে উপযোগী রাখে

• Severity লেবেল: blocker / should-fix / nit — nits merge আটকাবে না।
• Generated paths উপেক্ষা করুন (vendor/, lockfiles শব্দ, protobuf dumps)।
• Security-sensitive paths (auth/, infra/, IAM)-এ মানব approval চাই।
• False positives লগ করুন; মাসিক ignore নিয়মে ফিরিয়ে দিন।
• Production-critical সার্ভিসে botকে কখনো একমাত্র reviewer করবেন না।

9.5 ন্যূনতম GitHub Action স্কেচ

# .github/workflows/review-bot.yml
name: review-bot
on:
  pull_request:
    types: [opened, synchronize, reopened]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Run Review Bot
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
        run: |
          # Fetch diff, call your review CLI, post review comments via gh api
          ./scripts/review-bot.sh

review-bot.sh বাস্তবায়ন করুন: PR diff হিসাব, কঠোর system prompt (security + correctness আগে) দিয়ে মডেল কল, GitHub/GitLab API দিয়ে কমেন্ট পোস্ট। Token সীমিত করুন; খরচ চিন্তা হলে drafts এড়িয়ে যান।

10. Production-grade মানের জন্য GitOps সেরা অনুশীলন

GitOps মানে: desired state git-এ থাকে; reconciler (Argo CD, Flux ইত্যাদি) ক্লাস্টার মিল করায়; promotion একটি merge; rollback একটি revert।

• App code ও env config আলাদা করুন (বা স্পষ্ট ফোল্ডার: apps/ vs envs/dev|staging|prod)।
• Prod-এ kubectl apply নয় happy path হিসেবে — শুধু break-glass, audited।
• Progressive delivery: dev-এ auto-sync; prod-এর জন্য manual বা gated sync।
• Image digests prod manifests-এ mutable tags-এর চেয়ে ভালো।
• Policy as code: OPA/Kyverno অধিকার, registries, resource limits-এর জন্য।
• Signed commits / provenance যেখানে আপনার threat model চায়।
• Sync-এর পর observe করুন: health checks, error budgets, প্রস্তুত হলে automatic rollback hooks।

কোড মান শুধু «পরিষ্কার ফাংশন» নয়। এটিও পরিবর্তন কীভাবে production-এ প্রবেশ করে। GitOps সেই পথকে reviewable, reversible ও repeatable করে।

11. End-to-end quality gates (production-এর জন্য অপ্টিমাইজড)

Local:     pre-commit (fmt, lint, secrets) + unit tests
PR open:   CI (build, test, SAST) + Review Bot comments
PR merge:  human approve + branch protection + required checks
Main:      build immutable artifact (image digest)
GitOps:    update env repo / overlay → sync → verify
Prod:      SLOs + alerts + runbook linked from ADR/PR

12. FDE ভূমিকা — এই সিস্টেম কে সেট করে

Forward Deployed Engineer বাস্তব দলে বিচক্ষণ-ডেভেলপার সিস্টেম ইনস্টল করতে আদর্শ:

• Repo টেমপ্লেট: docs/adr/, PR টেমপ্লেট, CODEOWNERS, branch protection
• Review Bot + secrets + খরচ নিয়ন্ত্রণ
• CI required checks ও environment protections
• GitOps apps (dev/staging/prod) ও promotion docs
• দুই-সপ্তাহের coaching: প্রথম ADR, প্রথম bot-tuned PR, প্রথম GitOps rollback drill

একটি product repo-তে FDE-নেতৃত্বাধীন enablement-এর নির্দেশক ক্যালেন্ডার: scaffolding ও bot policy-এর জন্য ১–২ সপ্তাহ; GitOps promotion path ও dry-run rollback-এর জন্য +১–২ সপ্তাহ। সংস্কৃতি পরিবর্তন দীর্ঘ — merge time ও escaped defects মাপুন, tool installs নয়।

13. Claude Architect Certification — মূল্যবান

যদি আপনি এমন সিস্টেম ডিজাইন করেন যেখানে মানুষ ও AI এজেন্ট একসাথে কোড লেখে, Claude Architect Certification মূল্যবান। এটি সংকেত দেয় আপনি পারেন:

• মডেলকে অভ্রান্ত না ধরে AI-assisted delivery আর্কিটেক্ট করতে
• Agentic workflows-এর জন্য review নীতি, guardrails ও evaluation নির্দিষ্ট করতে
• Stakeholders-কে trade-offs (latency, cost, privacy, accuracy) বোঝাতে
• AI টুলের পাশাপাশি ADR, PR শৃঙ্খলা ও production gates-এ দলকে coach করতে

Credential-কে বাস্তব delivery-এর সাথে জোড়ুন: Review Bot তুলুন, তিনটি ADR লিখুন, GitOps rollback drill চালান। অনুশীলন ছাড়া কাগজ বিচক্ষণ করে না; অনুশীলন প্লাস ভাগ করা ভাষা করে।

14. Anti-patterns (অবিচক্ষণতা কেমন দেখায়)

• «WIP please approve ASAP» সহ বিশাল PR
• আর্কিটেকচার শুধু Slack-এ সিদ্ধান্ত, কখনো ADR-এ নয়
• টেস্ট ছাড়া প্রোটোটাইপ prod-এ merge
• Review Bot বন্ধ কারণ «এটা বিরক্ত করে»
• Revert পরিকল্পনা ছাড়া GitOps-এর বাইরে prod hotfix
• মানুষ bot ইতিমধ্যে ধরা formatter nits পুনরাবৃত্তি করে

15. নতুন প্রজেক্টের জন্য copy-paste starter checklist

1. docs/ideas/, docs/architecture/, docs/adr/ তৈরি করুন
2. PR/MR টেমপ্লেট + CODEOWNERS যোগ করুন
3. pre-commit + CI required checks চালু করুন
4. Review Bot ইনস্টল করুন; path ফিল্টার ও severities টিউন করুন
5. ADR-0001 লিখুন: «We use GitOps for deploy»
6. Environments ও promotion নিয়ম সংজ্ঞায়িত করুন
7. ৩০-মিনিটের rollback game day নির্ধারণ করুন
8. প্রথম মাসের coaching-এর জন্য FDE সময় বুক করুন; লিডদের জন্য Claude Architect Certification বিবেচনা করুন

16. সমাপ্তি

একজন বিচক্ষণ ডেভেলপার নতুন প্রজেক্টকে শেখার artifacts-এর ক্রম হিসেবে দেখে — নোট, ডায়াগ্রাম, প্রস্তাব, ADR — তারপর Review Bot-এর নজরে ও GitOps-এর প্রমোশনে ছোট MR/PR দিয়ে ডেলিভার করে। এভাবেই কোড মান production grade-এর জন্য অপ্টিমাইজ হয় দলকে অন্তহীন nits-এ পোড়ায় না। FDE-কে রেল বসাতে দিন; প্রত্যয়িত আর্কিটেক্ট সিস্টেম সৎ রাখুক যখন AI কোড লেখার গতি বাড়ায়।

প্রকাশিত Workstation.