DRY——Don't Repeat Yourself。这四个字母可能是软件工程里被引用最多、被误解最深的原则。

每个程序员入行第一天就被告知：重复代码是邪恶的，看到重复就要提取，看到提取就要抽象，看到抽象就要泛化。于是我们疯狂地消灭重复——公共函数、工具类、基础库、共享模块......代码库越来越"干净"，重复率越来越低，CI里没有任何duplicate code的警告。

然后某一天，一个业务需求来了——需要改动某个"公共"逻辑。你打开那个被47个地方引用的utils函数，改了一行，跑了一下测试——绿了。上线，结果三个业务线同时报警。你突然发现，那三个业务线依赖的是同一个函数的三种不同行为，被那个"公共"函数强制统一了。

你消灭了重复代码，但你制造了耦合。而耦合，是比重复贵十倍的技术债。

重复代码不是问题，问题是不知道为什么重复

所有关于DRY的讨论，都默认了一个前提：重复等于坏。但这个前提本身就是幻觉。

重复代码至少有三种完全不同的面目。

第一种是意外重复——两个开发者不知道对方写了同样的功能，造了两个轮子。这种重复才是真正需要消灭的，因为它意味着信息浪费和潜在的不一致。

每次做技术选型的时候，我都会想起期权定价模型。不是因为我爱装，是因为这玩意儿真的解释了大部分技术决策为什么会翻车。

做金融业务的人应该对这个逻辑不陌生——一个期权的价值，不取决于标的资产今天的价格，而取决于它未来的波动率、到期时间和执行价格。

技术选型也一样。你选一个框架、一个架构、一个技术栈，本质上是在买入一个期权。而大部分团队在做这个决策的时候，只看了"执行价格"——也就是今天的采用成本，完全忽略了到期时间和隐含波动率。

执行价格：你以为的成本只是首付

选React还是Vue？选微服务还是单体？选自研还是开源？这些决策的讨论，90%都聚焦在"今天迁移要花多少人力"上。

这就是只看执行价格。

我见过一个团队花了三个月从Vue迁到React，理由是"React生态更丰富"。三个月后确实迁完了，但接下来的一年里，团队不断在解决React生态的碎片化问题——路由、状态管理、样式方案，每一个都要做一个子决策。而当初评估迁移成本的时候，这些子决策根本没算进去。

就像买房只算了首付，没算物业费、维修基金和房产税。

2018年前后，Serverless在国内技术圈火了一阵。各大云厂商轮番布道，"按需付费"、"零运维"、"自动扩缩容"——每个口号都精准戳中了团队的痛点。我当时也投入了不少精力研究，毕竟谁不想不用管服务器？

几年过去了，当初那些All in Serverless的团队，相当一部分已经在往回走。不是Serverless不好，而是很多人慢慢意识到：当初以为消灭的复杂度，其实只是搬了个家。

那些承诺里没写的小字

Serverless的核心承诺有三条，每一条都有对应的现实版本。

"不用管服务器"——开发者只需写业务逻辑，基础设施平台托管。这对前端团队尤其有吸引力，写完函数丢上去就能跑，不用折腾部署和运维。但现实是，你很快会发现自己需要关注函数的内存配置、超时时间、并发限制、冷启动策略、VPC配置、IAM权限……这些不叫"服务器运维"，但本质上还是在管基础设施，只是换了个仪表盘。

"按需付费"——代码不运行就不收钱，空转成本消失。但下一句没人告诉你的是：按需付费的反面是成本不可预测。一个函数死循环触发重试，一个爬虫突然疯爬你的API，一个配置错误导致无限调用——这些异常场景下的账单，会让你深切怀念固定成本的日子。

每个工程师都有过这种时刻——翻开一段半年前写的代码，眉头一皱，手指开始痒。"这什么写法？""这命名谁看得懂？""这段逻辑完全可以抽象成三个函数。"然后一个"重构"的念头冒出来，越来越强烈，像夏天傍晚的蚊子，赶不走。

这种冲动太普遍了，以至于我们很少质疑它。代码审查时建议重构，结对编程时讨论重构，技术债清单里排满了重构项，季度规划里少不了"代码优化"的工时。重构似乎天然正确，像一种工程美德。

但我的观察恰恰相反：大部分重构是错误的决定。不是重构这件事有问题，是驱动重构的动机和时机几乎总是错的。

丑代码不等于坏代码

先说一个多数人不愿意接受的事实：代码的审美和代码的质量，经常是两回事。

一段看起来笨拙的代码，可能在一个微妙的时间窗口里正确处理了并发竞争。一段到处是硬编码的代码，可能正是因为硬编码才避免了配置出错引发线上故障。一段三百行的函数，可能是经过六次需求变更后唯一还hold得住的逻辑形态——你把它拆成六个"优雅"的函数之后，任何一个需求的变更都会涉及三个函数的修改，追踪数据流变成了噩梦。

"丑"是主观判断，"坏"是客观后果。两者之间没有必然因果关系，但在重构决策里，它们经常被混为一谈。工程师看到不美的代码就判定它需要重构，这个推理本身就是逻辑谬误。