让我们一起终结复杂性商人（谢谢你，DHH）

摘要

文章以DHH的演讲为引子，批判软件行业普遍存在的过度复杂化问题。作者认为当前编程世界至少50%充斥着"随意的复杂性胡扯"，从苹果的代码签名系统、Xcode的糟糕体验，到企业项目中滥用微服务架构，都是典型案例。文章主张拥抱Web标准、Rails等开放简单的技术栈，用AI作为复杂性检测工具，呼吁开发者共同抵制封闭生态系统带来的不必要繁文缛节。

内容框架与概述

文章开篇由DHH在Rails World 2025的演讲切入，作者将DHH视为职业生涯中的"线上导师"，帮助自己识破技术世界的各种胡扯。他观察到90%的人拒绝简化方案，导致本可用一两百万完成的项目最终耗资2000万并失败。

中段作者列举大量具体案例论证复杂性问题的普遍性：苹果的代码签名与公证系统、iOS键盘扩展的人为限制、Kubernetes的过度使用，以及Xcode长期存在的构建故障。他提出用AI和快速原型验证作为"复杂性检测器"——如果MVP无法在一周内完成，往往意味着存在不必要的障碍。

文章后半部分提出解决方案：拥抱Web标准、Electron、Node.js、Ruby on Rails等真正开放的技术栈，抵制Swift等封闭生态。作者以接手的咨询项目为例，批评将2000行代码拆分成6个微服务的荒谬做法，引用Linus Torvalds的话强调过度复杂化对世界的危害。

核心概念及解读

复杂性商人（Merchants of Complexity）：指那些通过制造和推广不必要复杂性来获利的人或系统，包括过度设计的框架、繁琐的平台规则，以及盲目套用"最佳实践"的开发者。

复杂性胡扯检测器：作者提出的方法论，核心判断标准是项目能否快速达到可用状态。如果MVP需要超过一周时间，就应审视是否存在人为制造的复杂性障碍。

开放系统 vs 封闭生态：Web标准、Rails等开放技术栈代表简单高效，而苹果Swift/Xcode等封闭系统则通过垄断制造壁垒、扼杀创新，开发者应主动选择前者。

微服务滥用：企业开发中常见的过度工程化现象，将简单项目强行拆分为多个微服务，徒增复杂度而无实际收益，单体架构在多数场景下更为合适。

原文信息

此摘要卡片由 AI 自动生成