# 24. 持续成长

如何通过系统性阅读、事故复盘、写作、带人、design review,以及在真实约束下做事,来发展你的架构思维。

- **Author:** Fedor Chishchin
- **Level:** advanced
- **Reading time:** 约 25 分钟阅读
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/zh/learn/software-architect-24-growth

---

## 1. 核心观点

架构能力来自可重复的实践:读系统、做决策、检查后果、打磨思维模型。

### 向真实系统学习

> 棋手不是靠背开局的名字变强的。他靠的是复盘对局和错误。

书和文章重要,但架构师更快的成长来自剖析真实决策:系统为什么垮了、迁移为什么一拖再拖、团队为什么选了这个 API、这个模块为什么变得难改。

一个有用的习惯是 decision journal(决策日志):决定了什么、当时的假设是什么、风险是什么、预期结果是什么、什么时候回头检查。几个月之后,它就成了校准你思维的原材料。

### 写作让思维变得可验证

> 当一个想法还只在脑子里时,它感觉很清楚。一落到纸上,缺失的关节立刻就露出来。

架构师应该规律地写:ADR、design note、迁移计划、事故复盘、技术战略。写作逼着你把 context、约束、备选和后果都明确地说出口。

好的写作不必很长。它得让另一个工程师能接住这段推理,继续往下走。

## 2. 例子与反例

架构师的成长,用团队决策的质量来衡量,而不是用他能叫出多少项技术的名字来衡量。

### 例子:一次不甩锅的事故复盘

> 事故之后,航空业看的是系统:流程、仪表、训练、疲劳、沟通。而不只是盯着最后站在操作台前的那个人。

团队做一次 blameless postmortem:时间线、影响、检测、contributing factor、做得好的地方、action item。架构师寻找的是系统性的改进:一个缺失的 timeout、一份薄弱的 runbook、一个不存在的告警、一条危险的依赖链。

这样,事故就成了架构和运维生长的材料。

### 反例:收集技术,而不是判断力

> 一柜子昂贵的工具,并不会让你成为好工匠,如果你不懂材料。

工程师学遍所有新东西:下一个 framework、数据库、broker、云服务。却从不训练 trade-off 思维、沟通、ownership、reliability 或数据建模。词汇量涨了,决策的质量没涨。

技术重要,但架构师值钱在判断力:什么时候该用、什么时候不该用,以及这个决策会造出多大的代价。

#### 自检

- 过去半年里,我的哪些假设被证明是错的?
- 数据进来之后,我修正了哪些决策?
- 为了让团队更能自给自足,我 写下了什么?
- 当下,限制我架构水平最厉害的那项技能是什么?

回到速成课:[Software Architect:思维、语言与实践](./software-architect)。