Как вы принимаете и документируете значительные технические решения?

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 для решений, которые **дорого обращать вспять** или которые будущие инженеры будут оспаривать.

## Почему это важно

Недокументированные решения бесконечно пересматриваются, каждый новый инженер снова спрашивает "почему мы выбрали это?"

Записание обоснования также заставляет ясность: если вы не можете обосновать это на бумаге, вы, вероятно, не очень хорошо об этом подумали.