समझदार डेवलपर नए प्रोजेक्ट पर कैसे काम करता है

एक समझदार डेवलपर «कोडिंग शुरू करके उम्मीद» नहीं करता। वे नए प्रोजेक्ट को 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 कमेंट थ्रेड अक्सर मीटिंग से बेहतर — लेकिन किसी को loop बंद करना ही होगा।

4. प्रोटोटाइपिंग (समाप्ति तिथि वाले spikes)

अनिश्चितता ऊँची हो तो प्रोटोटाइप करें: नया API, अपरिचित cloud सेवा, प्रदर्शन प्रश्न, या 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 से immutable रिकॉर्ड है। टेम्पलेट:

# 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 gaps, secret leakage, असुरक्षित defaults
• Correctness: null paths, race conditions, टूटे migrations
• Tests: नई शाखाओं पर missing coverage, snapshot abuse
• 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-linked 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 द्वारा promote किए गए छोटे MR/PR से डिलीवर करता है। इसी तरह कोड गुणवत्ता production grade के लिए अनुकूलित होती है बिना टीम को अंतहीन nits पर जलाने के। FDE को रेल लगाने दें; प्रमाणित आर्किटेक्ट सिस्टम को ईमानदार रखें जबकि AI कोड लिखने की गति बढ़ाता है।

प्रकाशित Workstation.