دانشمند ڈویلپر نئے پروجیکٹ پر کیسے کام کرتا ہے

ایک دانشمند ڈویلپر «کوڈنگ شروع کر کے امید» نہیں کرتا۔ وہ نئے پروجیکٹ کو 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 (پہلے اکیلے، پھر ساختہ)

کسی سے وقت مانگنے سے پہلے 30–90 منٹ اکیلے گزاریں:

• نتیجہ: ختم ہونے پر کون سا صارف/کاروباری تبدیل درست ہونا چاہیے؟
• پابندیاں: وقت، بجٹ، 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 (25–45 منٹ)۔ فیصلوں یا کھلے سوالات پر ختم کریں — vibes نہیں۔
• اختیارات پر اختلاف، لوگوں پر نہیں۔ «option A vs B vs defer» نافذ کریں۔
• ایک scribe مقرر کریں۔ نوٹ تجویز کا بیج بنتا ہے۔
• خاموش veto نہیں۔ اگر کوئی بے چین ہے، بعد میں ADR میں تشویش کو خطرہ لکھیں۔

Async بھی کام کرتا ہے: مختصر RFC کمنٹ تھریڈ اکثر میٹنگ سے بہتر — مگر کسی کو لوپ بند کرنا ہی ہوگا۔

4. پروٹوٹائپنگ (میعاد والے spikes)

غیر یقینی بلند ہو تو پروٹوٹائپ کریں: نیا API، ناواقف کلاؤڈ سروس، پرفارمنس سوال، یا AI/agent رویہ۔ دانشمندانہ قواعد:

1. ٹکٹ میں اسے spike نام دیں؛ کیلنڈر stop سیٹ کریں (عام طور پر 1–3 دن)۔
2. کوڈ throwaway برانچ یا spikes/ فولڈر میں رکھیں؛ polish نہ کریں۔
3. 10 بلیٹ میں سیکھا لکھیے — خاص طور پر جو ناکام رہا۔
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 <400 لائنیں؛ 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 کے لیے 1–2 ہفتے؛ GitOps promotion path اور dry-run rollback کے لیے +1–2 ہفتے۔ ثقافتی تبدیلی زیادہ لیتی ہے — 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
• انسان وہی formatter nits دہراتے ہیں جو bot پہلے پکڑ چکا

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. 30 منٹ rollback game day شیڈول کریں
8. پہلے مہینے coaching کے لیے FDE وقت بک کریں؛ لیڈز کے لیے Claude Architect Certification پر غور کریں

16. اختتام

ایک دانشمند ڈویلپر نئے پروجیکٹ کو سیکھنے کے artifacts کی تسلسل سمجھتا ہے — نوٹس، ڈایاگرام، تجاویز، ADR — پھر Review Bot کی نگرانی اور GitOps کی پروموشن کے ساتھ چھوٹے MR/PR سے ڈیلیور کرتا ہے۔ اسی طرح کوڈ معیار production grade کے لیے بہتر ہوتا ہے بغیر ٹیم کو لامتناہی nits پر جلائے۔ FDE کو ریلز لگانے دیں؛ تصدیق شدہ آرکیٹیکٹس نظام ایماندار رکھیں جب AI کوڈ لکھنے کی رفتار بڑھاتا ہے۔

شائع کردہ Workstation.