# 24. Постоянный рост архитектора

Как развивать архитектурное мышление через системное чтение, разбор инцидентов, writing, mentoring, design reviews и работу с реальными ограничениями.

- **Author:** Фёдор Чищин
- **Level:** advanced
- **Reading time:** ~25 минут чтения
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/ru/learn/software-architect-24-growth

---

## 1. Главная идея

Архитектурное мастерство появляется из повторяемой практики: читать системы, принимать решения, проверять последствия и улучшать модель мышления.

### Учиться нужно на реальных системах

> Шахматист растёт не от знания названий дебютов, а от анализа партий и ошибок.

Книги и статьи важны, но архитектор растёт быстрее, когда разбирает реальные decisions: почему система упала, почему миграция затянулась, почему команда выбрала этот API, почему модуль стал трудным для изменений.

Полезная привычка — вести decision journal: какое решение принято, какие assumptions, какие risks, какой expected outcome, когда проверить. Через несколько месяцев это становится материалом для калибровки мышления.

### Writing делает мышление проверяемым

> Пока мысль только в голове, она кажется ясной. На бумаге сразу видно, где пропущены связки.

Архитектор должен регулярно писать: ADR, design notes, migration plans, incident reviews, technical strategy. Письмо заставляет явно назвать context, constraints, alternatives и consequences.

Хороший текст не обязан быть длинным. Он должен позволять другому инженеру понять reasoning и продолжить работу.

## 2. Пример и антипример

Рост архитектора измеряется качеством решений команды, а не количеством известных технологий.

### Пример: разбор инцидента без поиска виноватых

> После аварии авиация изучает систему: процедуры, приборы, обучение, усталость, коммуникацию. Не только последнего человека у панели.

Команда проводит blameless postmortem: timeline, impact, detection, contributing factors, what went well, action items. Архитектор ищет системные улучшения: missing timeout, слабый runbook, отсутствие alert-а, опасный dependency chain.

Так инцидент становится материалом для роста architecture и operations.

### Антипример: собирать технологии вместо judgment

> Коллекция дорогих инструментов не делает человека хорошим мастером, если он не понимает материал.

Инженер изучает всё новое: очередной framework, database, broker, cloud service. Но не тренирует trade-off thinking, коммуникацию, ownership, reliability и data modeling. В результате словарь растёт, а качество решений нет.

Технологии нужны, но архитектор ценен judgment-ом: когда применять, когда не применять и какую цену решение создаёт.

#### Самопроверка

- Какие мои assumptions за последние полгода оказались неверными?
- Какие решения я пересмотрел после получения данных?
- Что я написал, чтобы команда стала самостоятельнее?
- Какой навык сейчас сильнее всего ограничивает мой архитектурный уровень?

  Вернуться к краткому курсу: [Software Architect: мышление, язык и практика](./software-architect).