# 23. 反模式

架构师常见的失败模式:cargo cult、ivory tower、distributed monolith、过早抽象、resume-driven development,以及 ownership 的缺失。

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

---

## 1. 核心观点

一个架构错误,在它被做出的那一刻通常看起来很聪明——半年后才显出昂贵。

### cargo cult 抄走了形,却抄不走原因

> 穿上飞行员制服,不等于你会降落一架飞机。

cargo cult 架构出现在这种时候:团队照搬大公司做出的决策,却没有它们的 context——microservices、service mesh、Kafka、Kubernetes、event sourcing、multi-region。问题不在工具,而在缺少"你自己用它的理由"。

专业的检查很简单:我们到底在买哪个具体的属性,以及为什么它现在重要?

### ivory tower 把架构和代码割裂开

> 一个从没去过工地的设计师,有可能画出一张漂亮却建不出来的图。

ivory tower(象牙塔)架构师产出图纸和标准,却看不见真实的约束:legacy、工具链、developer experience、事故、deadline、团队技能。结果是,那些决策要么没人采纳,要么只在纸面上被采纳。

架构师不必写每一行代码,但必须贴近交付:review、原型、迁移、事故,以及来自团队的反馈。

## 2. 例子与反例

一个反模式,只有在团队不再把它当成"正常"之后,才修得掉。

### 例子:叫停一次过早抽象

> 一把能开所有门的万能钥匙,通常把那扇具体的门开得很糟。

团队想为三个相似的审批 flow 造一个通用 workflow engine。架构师提议:先把其中两个 flow 显式地实现出来,比较它们的可变点,然后再抽出抽象。

这不是拒绝做架构。这是在防止一个"在你理解领域之前就到来"的抽象。

### 反例:resume-driven development

> 为了橱窗去买一件工具是冒险的——每天得跟它打交道的人是你。

工程师挑一项技术,是因为它写在简历上好看,或者在大会上很时髦。团队的技能盘、招聘市场、成熟度、工具链、运维和长期支持,统统没进入讨论。

架构师必须把"对技术的好奇心"和"对系统的价值"分开。

#### 自检

- 哪些决策是我们没有自己的理由就照抄来的?
- 图纸在哪里和真实代码对不上?
- 哪里在第三个具体案例出现之前 就冒出了抽象?
- 哪些技术是为团队选的,哪些是为时髦选的?

下一模块:[Continuous growth](./software-architect-24-growth)。