Software Architect · Модуль 24
Архитектор растёт не через список технологий, а через способность видеть последствия решений, учиться на системах и улучшать качество reasoning.
Practice · incidents · writing · mentoring · review
Архитектурное мастерство появляется из повторяемой практики: читать системы, принимать решения, проверять последствия и улучшать модель мышления.
Учиться нужно на реальных системах
Шахматист растёт не от знания названий дебютов, а от анализа партий и ошибок.
Книги и статьи важны, но архитектор растёт быстрее, когда разбирает реальные decisions: почему система упала, почему миграция затянулась, почему команда выбрала этот API, почему модуль стал трудным для изменений.
Полезная привычка — вести decision journal: какое решение принято, какие assumptions, какие risks, какой expected outcome, когда проверить. Через несколько месяцев это становится материалом для калибровки мышления.
Writing делает мышление проверяемым
Пока мысль только в голове, она кажется ясной. На бумаге сразу видно, где пропущены связки.
Архитектор должен регулярно писать: ADR, design notes, migration plans, incident reviews, technical strategy. Письмо заставляет явно назвать context, constraints, alternatives и consequences.
Хороший текст не обязан быть длинным. Он должен позволять другому инженеру понять reasoning и продолжить работу.
Рост архитектора измеряется качеством решений команды, а не количеством известных технологий.
Пример: разбор инцидента без поиска виноватых
После аварии авиация изучает систему: процедуры, приборы, обучение, усталость, коммуникацию. Не только последнего человека у панели.
Команда проводит 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 за последние полгода оказались неверными? - Какие решения я пересмотрел после получения данных? - Что я написал, чтобы команда стала самостоятельнее? - Какой навык сейчас сильнее всего ограничивает мой архитектурный уровень?