Software Architect · 模块 20
架构师很少能直接下命令。他的影响力建立在清晰、信任、reasoning 的质量，以及放大他人的能力之上。
Influence · alignment · mentoring · principles
技术领导力是提升团队决策的能力，不是亲自做出每一个决策。
原则比意见更能 scale
交通规则让成千上万的司机通过路口，而不必在每个路口都向调度员请示。
如果架构师手动回答每个问题，他就成了 bottleneck。如果他把 principles、quality gates 和 decision framework 表达清楚，团队就能自己行动。
举个 principle 的例子："Domain layer 不依赖 infrastructure"。这比在每个 PR 里争论能不能在 use case 里 import ORM 强得多。
Influence 需要信任
导航能稳定地带你到目的地，人们才会一直听它。一次自信但错误的路线，会让信任掉很久。
信任来自准确、敢于承认 uncertainty、对 trade-offs 的诚实描述，以及对团队上下文的尊重。一个总是"知道得比你多"的架构师，会迅速失去影响力。
强有力的表态听起来不像绝对真理："我觉得这套数据模型风险很高，因为迁移会牵动 external API 和 billing。我们检验一下替代方案。"
架构师离开时应该留下一个更强的团队，而不是一个对自己有依赖的团队。
例子：把 architecture review 当作教学
好教练不会替球队打比赛。他帮助球员看清整个场地。
review 里，架构师不下结论，而是提问：invariants 是什么、idempotency 放在哪、怎么迁移、partial failure 时会发生什么、哪些 metrics 能证明成功。团队自己锐化设计，并把结论写进 ADR。
下一次，团队会在没有架构师的房间里，自己问出其中的一部分问题。
反例：英雄架构师
如果一座桥只靠一个人每天手动拧螺丝才不塌，那就不是一座可靠的桥。
架构师亲自修所有难题、写最重要的几块代码、把所有决策装在自己脑子里、什么也不下放。外表看起来高效，内里却制造了 bus factor 和 learned helplessness。
真正的领导力，会降低对单个人的依赖。
- 哪些决策团队可以在没有我的情况下做出？ - 哪些 principle 替代了一再重复的争论？ - 最近一个月我把架构 reasoning 教给了谁？ - 我的参与在哪里变成了 bottleneck？