Software Architect · 模块 23
反模式不是用来甩锅的。它给你一套词汇,让你更早抓住系统性的思维错误。
Cargo cult · ivory tower · distributed monolith · premature abstraction
一个架构错误,在它被做出的那一刻通常看起来很聪明——半年后才显出昂贵。
cargo cult 抄走了形,却抄不走原因
穿上飞行员制服,不等于你会降落一架飞机。
cargo cult 架构出现在这种时候:团队照搬大公司做出的决策,却没有它们的 context——microservices、service mesh、Kafka、Kubernetes、event sourcing、multi-region。问题不在工具,而在缺少"你自己用它的理由"。
专业的检查很简单:我们到底在买哪个具体的属性,以及为什么它现在重要?
ivory tower 把架构和代码割裂开
一个从没去过工地的设计师,有可能画出一张漂亮却建不出来的图。
ivory tower(象牙塔)架构师产出图纸和标准,却看不见真实的约束:legacy、工具链、developer experience、事故、deadline、团队技能。结果是,那些决策要么没人采纳,要么只在纸面上被采纳。
架构师不必写每一行代码,但必须贴近交付:review、原型、迁移、事故,以及来自团队的反馈。
一个反模式,只有在团队不再把它当成"正常"之后,才修得掉。
例子:叫停一次过早抽象
一把能开所有门的万能钥匙,通常把那扇具体的门开得很糟。
团队想为三个相似的审批 flow 造一个通用 workflow engine。架构师提议:先把其中两个 flow 显式地实现出来,比较它们的可变点,然后再抽出抽象。
这不是拒绝做架构。这是在防止一个"在你理解领域之前就到来"的抽象。
反例:resume-driven development
为了橱窗去买一件工具是冒险的——每天得跟它打交道的人是你。
工程师挑一项技术,是因为它写在简历上好看,或者在大会上很时髦。团队的技能盘、招聘市场、成熟度、工具链、运维和长期支持,统统没进入讨论。
架构师必须把"对技术的好奇心"和"对系统的价值"分开。
- 哪些决策是我们没有自己的理由就照抄来的? - 图纸在哪里和真实代码对不上? - 哪里在第三个具体案例出现之前 就冒出了抽象? - 哪些技术是为团队选的,哪些是为时髦选的?