ਤੁਸੀਂ ਮਹੱਤਵਪੂਰਣ ਤਕਨੀਕੀ ਫੈਸਲੇ ਕਿਵੇਂ ਲੈਂਦੇ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਕਰਦੇ ਹੋ?

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 ਨਾਲ ਰਿਕਾਰਡ ਕਰੋ

ਇੱਕ **ਆਰਕਿਟੈਕਚਰ ਡਿਸਿਜ਼ਨ ਰਿਕਾਰਡ** ਇੱਕ ਛੋਟੀ, ਟਿਕਾਊ ਨੋਟ ਹੈ:

```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).
```

## ਪ੍ਰਬੰਧ ਕਰਨ ਵਾਲਾ ਵਪਾਰ-ਆਫ

ਸਭ ਕੁਝ ਦਸਤਾਵੇਜ਼ ਕਰਨਾ ਓਵਰਹੈੱਡ ਹੈ; ਕੁਝ ਵੀ ਦਸਤਾਵੇਜ਼ ਨਾ ਕਰਨਾ ਸੰਸਥਾਗਤ ਮੈਮੋਰੀ ਨੂੰ ਗੁਆ ਦਿੰਦਾ ਹੈ। ADRਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਫੈਸਲਿਆਂ ਲਈ ਰਾਖਵਾਂ ਰੱਖੋ ਜੋ **ਪਲਟਾਉਣਾ ਮਹਿੰਗਾ** ਹਨ ਜਾਂ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਭਵਿੱਖ ਦੇ ਇੰਜੀਨੀਅਰ ਸਵਾਲ ਉੱਠਾਉਣਗੇ।

## ਇਹ ਮਹੱਤਵ ਕਿਉਂ ਹੈ

ਬਿਨਾ ਦਸਤਾਵੇਜ਼ਿਤ ਫੈਸਲੇ ਬੇਅੰਤ ਬਹਿਸ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਹਰੇਕ ਨਵਾਂ ਇੰਜੀਨੀਅਰ ਫਿਰ ਪੁੱਛਦਾ ਹੈ "ਅਸੀਂ ਇਹ ਕਿਉਂ ਚੁਣਿਆ?"

ਆਪਣੀ ਤਰਜੀਹ ਲਿਖਣਾ ਵੀ ਸਪੱਸ਼ਟਤਾ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ: ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਕਾਗਜ਼ 'ਤੇ ਸਮਰਥਿਤ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤੁਸੀਂ ਸ਼ਾਇਦ ਇਸ ਬਾਰੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੋਚਿਆ ਨਹੀਂ ਹੈ।