【真正的软件架构师，都在学着管理复杂性】

快速阅读：软件架构的核心不在于编写完美的逻辑，而在于管理复杂性与应对不可预见的变更。优秀的架构必须能够隔离风险、降低沟通成本，并承认设计最终会被社会组织结构（Conway's Law）所塑造。

架构师的工作，本质上是在信息不完全的情况下，利用经验法则去解决问题。

很多人觉得架构是关于如何构建一个拥有无数组件的复杂系统，但真正的专家是在思考：如何用最少的组件解决问题。设计好一个数据结构，对性能和维护性的贡献，远比挑选框架或语言要大。

要把状态（State）显式化。在大型系统中，状态是所有美好事物的敌人。如果一个变量可以被任何地方随意修改，那这套系统迟早会崩塌。尽量让状态拥有明确的归属，并确保信息的唯一事实来源。

命名不仅仅是给变量起个好听的名字，它是在建立一套“真理词汇”。如果团队成员对同一个概念有不同的称呼，那他们其实从未在同一个频道上交流过。

有观点认为，沟通是一种必须证明其价值的“税收”。不要为了所谓的“集体决策”而拉上六个人开会，这种沟通成本往往会拖慢所有人的进度。在扩大讨论范围之前，先在小范围内达成共识，这比盲目追求民主更高效。

有趣的是，代码的生命周期往往比预想的长，而人的记忆力却比预想的短。那些所谓的“临时代码”，最后往往成了系统的基石。

如果测试变得困难，通常意味着设计本身出了问题。

架构不是一种可以被“教”出来的技能，它更像是一种通过体验痛苦而获得的直觉。你无法在书本里学到如何处理混乱，你只能在维护那些让你彻夜难眠的遗留系统时，才真正明白什么是边界，什么是耦合。

既然设计永远无法逃避约束，那么保持灵活性，比追求正确更重要。

matklad.github.io/2026/05/12/software-architecture.html