आप महत्वपूर्ण तांत्रिक निर्णय कैसे लेते हैं और दस्तावेज़ करते हैं?

Question

Accepted Answer

महत्वपूर्ण तांत्रिक निर्णय **जानबूझकर, पारदर्शी और दर्ज किए हुए** होने चाहिए, किसी के मन में लिए गए और भूले हुए नहीं। एक अच्छी प्रक्रिया ट्रेड-ऑफ को उजागर करती है, सहमति बनाती है, और एक पथ छोड़ती है ताकि भविष्य के इंजीनियर *क्यों* समझ सकें, केवल *क्या* नहीं।

## एक निर्णय ढांचा

```text
1. FRAME the problem and the constraints (cost, time, team skill, scale)
2. LIST the realistic options — usually 2-4, including "do nothing"
3. EVALUATE each against the constraints and trade-offs
4. DECIDE, and state the reasoning explicitly
5. RECORD it (ADR) and communicate it
6. REVISIT if assumptions change
```

## ADR के साथ रिकॉर्ड करें

एक **Architecture Decision Record** एक संक्षिप्त, टिकाऊ नोट है:

```markdown
# ADR 014: Use PostgreSQL for the new service

## Status: Accepted

## Context
We need a primary datastore. Team knows SQL; data is relational; scale is moderate.

## Decision
Use PostgreSQL.

## Consequences
+ Strong consistency, team familiarity, rich querying.
- Vertical scaling limits later; revisit if write volume 10x's.

## Alternatives considered
DynamoDB (rejected: relational data, team unfamiliar).
```

## प्रबंधित करने के लिए ट्रेड-ऑफ

सब कुछ दस्तावेज़ करना ओवरहेड है; कुछ न दस्तावेज़ करना संस्थागत स्मृति खो देता है। ADRs को उन निर्णयों के लिए सुरक्षित रखें जो **वापस लेना महंगा है** या जो भविष्य के इंजीनियर पूछेंगे।

## यह महत्वपूर्ण क्यों है

अदस्तावेज़ित निर्णय अंतहीन रूप से फिर से विवाद करते हैं, हर नया इंजीनियर फिर से पूछता है "हमने यह क्यों चुना?"

तर्क को लिखना भी स्पष्टता को मजबूर करता है: यदि आप इसे कागज पर सही नहीं ठहरा सकते हैं, तो आप संभवतः इसके बारे में पर्याप्त नहीं सोचा है।