有个代码库里的"发送邮件"功能，套了七层抽象壳子。邮件服务调用邮件供应商，供应商包装邮件客户端，客户端呼叫邮件适配器，适配器使用消息发送器，发送器触发传输层——层层剥完，才真正碰到邮件API。
每层都有正当理由：这里记日志，那里做容错，中间塞重试逻辑。按行业共识的标准，这几乎就是"整洁代码"的范本。问题是，团队里已经没人能完整搞懂这套东西了。
这就是没人敢说的真相——当有人在代码评审里跟你引用Bob大叔时。
Robert Martin的书出版于2008年，给了开发者一套词汇和规则：函数要短、命名要有意义、单一职责、不写注释因为代码应该自解释。好想法，确实是。但接下来发生的事才是问题。
开发者把一套特定场景下的实用建议，变成了放之四海皆准的通用标准。整洁代码从工具变成了身份标签。写整洁代码说明你是正经开发者，写别的就是偷懒、走捷径、不敬业。一旦某件事变成身份认同，它就不再被质疑。
于是开发者开始给不需要抽象的东西加抽象。给永远不会有第二个实现的类创建接口。把函数拆成子函数再拆成子子函数，直到原始逻辑分散在十二个文件里，想搞清楚代码到底在干什么得花四十分钟考古。
全都是为了"整洁"。没一件是为了真正解决问题。
2023年，程序员Casey Muratori发了条视频叫《整洁代码，糟糕性能》。他把Bob大叔的整洁代码示例拿出来，跟直来直去的实现做基准测试。整洁版本慢了最多23倍。
整洁代码社区的反应可想而知：性能对大多数应用不重要，瓶颈通常在数据库，你这是过早优化。有些话确实在理——现代软件大部分时间都在等用户输入，不是在执行业务逻辑。对很多应用来说，性能差距确实无关痛痒。
但这不是Muratori的核心论点。他的重点是：整洁代码规则被包装成放之四海皆准、脱离上下文的定律，但它们不是。它们是权衡。每加一层抽象，就多一层要理解的东西。每个小函数都是读者大脑里的上下文切换。每个接口都是一层掩盖实际发生什么的间接层。
整洁代码只是把复杂度挪了地方，并没有消除它。
诚实代码不是乱写代码，不是想怎么写就怎么写还美其名曰风格选择。诚实代码是承认代码首先是给人读的，而读代码的人通常时间紧迫、压力山大、更想搞懂业务逻辑而不是你的架构巧思。诚实代码问的是：下一个人打开这个文件时，能不能在五分钟内明白这里在发生什么？
有时候答案需要一层抽象。有时候答案就是直接调用邮件API，在旁边写行注释说明重试逻辑在哪处理。
2008年的那本书不是圣经，是特定时间特定背景下的建议。软件变了，硬件变了，团队结构变了，我们构建的东西也变了。规则本该跟着变。
整洁代码运动最大的讽刺在于：它本意是降低复杂度，却催生了一种文化——复杂度被重新包装成美德，而质疑它的人被当成不懂行。
七层抽象发一封邮件。没人能完全理解。但代码很"整洁"。
这真的值得吗？
热门跟贴