扁鹊悖论 受保护

我一直觉得,真正想清楚了再动手的0-1,应该比事后来收拾烂摊子的人值钱。但市场是反过来的。这件事困扰我很久。 很常见的一种情况是,一个项目交给一个一般的架构师,做了两年,系统能跑,但越改越重。后来公司请来一个很厉害的重构者,半年把它重新捋顺,拿到很高的报酬,所有人都觉得他救了项目。但很少有人会去想另一个问题:如果一开始就是那个厉害的人,会怎样。可能只要一年,系统更轻,后面也不需要重构。但这个反事实没法被算进账,因为它不存在。 好的0-1像运气,烂的0-1出英雄。英雄主义有两个时刻。一个在交付那一刻,快速上线、抢下窗口、赶在 deadline 之前把东西推出去,光鲜的只是速度,烂还没显形。一个在重构那一刻,前面的烂已经显形了,有人来收拾,救场。交付时的英雄卸任,新英雄上场。好的 0-1 两个时刻都不在场。它交付时不够快,因为想清楚要花时间;后期不需要救场,因为本来就不会出大事。所以它只能像运气。 这件事两千多年前就有名字——扁鹊三兄弟,大哥治未病,二哥治初病,扁鹊治大病,名气却倒过来。设计是一样的。被在架构阶段消灭掉的事故,不存在;不存在的事件不能被定价。能被定价的,只有可见的交付和发生过的事故。 当下定价的是速度和救场。好的设计要等很久才被看见,有时候一直不被看见。但它在那里。

2025年9月21日 · 1 分钟

凤凰架构

周志明《凤凰架构》。核心观点:架构不是炫技,不是堆名词,而是在约束条件下持续支持业务演进的系统设计。 核心观点 架构首先服务于演进。 一个系统最重要的能力,不是初版多优雅,而是变化来临时能否低成本调整。 分布式不是目标,只是代价高昂的手段。 很多问题在单体阶段并不存在,一旦走向分布式,复杂性、调用链、事务一致性、运维成本都会急剧上升。 架构决策必须对应具体问题。 如果没有明确的性能瓶颈、组织边界或交付约束,很多“先进架构”都只是过度设计。 印象较深的部分 技术选型背后总有交换。 性能、可维护性、可扩展性、团队认知成本,永远不可能同时最优。 架构能力的一部分是克制。 什么时候不拆、什么时候不分布式、什么时候保留简单方案,往往比“会多少框架”更重要。 读后感 这本书好在它不太谈抽象的“架构之美”,而是不断把问题拉回现实:业务规模、团队能力、系统约束、演进成本。 这本书最后落下来的判断很明确:好的架构师不只是会设计复杂系统,更重要的是知道复杂性应该从哪里开始,又该在哪停下来。

2025年8月3日 · 1 分钟