Software Architect · 模块 24
架构师不是靠收集技术成长的。他靠的是看见决策的后果、向系统学习,以及提高自己推理的质量。
Practice · incidents · writing · mentoring · review
架构能力来自可重复的实践:读系统、做决策、检查后果、打磨思维模型。
向真实系统学习
棋手不是靠背开局的名字变强的。他靠的是复盘对局和错误。
书和文章重要,但架构师更快的成长来自剖析真实决策:系统为什么垮了、迁移为什么一拖再拖、团队为什么选了这个 API、这个模块为什么变得难改。
一个有用的习惯是 decision journal(决策日志):决定了什么、当时的假设是什么、风险是什么、预期结果是什么、什么时候回头检查。几个月之后,它就成了校准你思维的原材料。
写作让思维变得可验证
当一个想法还只在脑子里时,它感觉很清楚。一落到纸上,缺失的关节立刻就露出来。
架构师应该规律地写:ADR、design note、迁移计划、事故复盘、技术战略。写作逼着你把 context、约束、备选和后果都明确地说出口。
好的写作不必很长。它得让另一个工程师能接住这段推理,继续往下走。
架构师的成长,用团队决策的质量来衡量,而不是用他能叫出多少项技术的名字来衡量。
例子:一次不甩锅的事故复盘
事故之后,航空业看的是系统:流程、仪表、训练、疲劳、沟通。而不只是盯着最后站在操作台前的那个人。
团队做一次 blameless postmortem:时间线、影响、检测、contributing factor、做得好的地方、action item。架构师寻找的是系统性的改进:一个缺失的 timeout、一份薄弱的 runbook、一个不存在的告警、一条危险的依赖链。
这样,事故就成了架构和运维生长的材料。
反例:收集技术,而不是判断力
一柜子昂贵的工具,并不会让你成为好工匠,如果你不懂材料。
工程师学遍所有新东西:下一个 framework、数据库、broker、云服务。却从不训练 trade-off 思维、沟通、ownership、reliability 或数据建模。词汇量涨了,决策的质量没涨。
技术重要,但架构师值钱在判断力:什么时候该用、什么时候不该用,以及这个决策会造出多大的代价。
- 过去半年里,我的哪些假设被证明是错的? - 数据进来之后,我修正了哪些决策? - 为了让团队更能自给自足,我 写下了什么? - 当下,限制我架构水平最厉害的那项技能是什么?