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

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

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

丑代码不等于坏代码

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

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

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

又一起线上事故。凌晨三点的告警，值班同学爬起来处理，应急响应、回滚、止血，一气呵成。第二天上午，事故复盘会准时召开。PPT做得很漂亮，时间线梳理得清清楚楚，根因分析写得明明白白，action items列了七八条。所有人都认真地点了点头，表示"以后一定注意"。

三个月后，同一个系统，同一类事故，再次发生。

这个场景太熟悉了。每个经历过线上事故的技术人，大概都对这种循环不陌生。复盘会开了一轮又一轮，文档写了一篇又一篇，"改进措施"列了一条又一条，但该来的事故还是会来，该踩的坑还是会踩。

问题到底出在哪？

复盘变成了一场仪式

大部分复盘会的真实目的，早就不是"从错误中学习"了。它承担的职能更接近一种组织仪式——事故发生了，总得有个交代。复盘会就是一种交代：你看，我们重视了，我们分析了，我们有改进计划了。

这种仪式感会带来一个隐蔽的副作用：它让所有人都觉得事情正在被处理。管理者觉得团队在反思，团队觉得管理者在推动改进，大家心里都松了一口气。但"感觉在改进"和"真实在改进"之间，隔着一道巨大的鸿沟。

团队里总有那么一两个人，什么活都能干，什么锅都能扛。需求来了找他，线上出问题找他，新技术调研找他，代码评审也想拉他。他的日历永远排得最满，他的PR永远是别人等Review最久的那个。

大家都觉得这是"能力强、受重视"的体现。管理者也觉得，把重要的活交给靠谱的人理所当然——毕竟谁能放心把核心模块交给新人？

但我要说一个可能得罪人的判断："能者多劳"不是在重用人才，是在消耗人才。而且这种消耗有一个特别迷惑人的地方——它看起来像是信任，感觉起来像是被需要，唯独结果不是被成全。

看起来是信任，实际上是惩罚

考虑一个很常见的场景。

项目要赶排期，核心功能必须本周上线。你会交给谁？当然是那个靠谱的资深工程师，因为交给别人你不放心，延期了你担不起。

线上出了Bug，排查要理解完整链路。你会交给谁？还是那个人，因为只有他能从数据库一路追到前端渲染。

新人入职需要导师，你会选谁？又是他，因为他技术好、有耐心、能讲清楚。

看起来这个人得到了最大的信任，承担了最重要的工作。但仔细想想，他得到了什么？更多的工作。更满的日历。更少的写代码时间。更晚的下班时间。而那些干得一般的人呢？他们的工作量反而更少，因为没人找他们。

每年Q1，技术团队都会经历一场庄严的仪式：写技术规划。

leader们关在小会议室里，对着白板画架构图，列痛点，排优先级，做资源估算。最后产出一个精美的PPT，把"技术债务治理""架构升级""效能提升"分门别类，附上里程碑和时间线。汇报的时候信心满满，老板点头通过，大家鼓掌散会。

然后呢？Q2还没结束，规划已经面目全非。Q3的时候，PPT里的那些项目，活着的大概只剩三分之一。到了Q4做复盘，大家心照不宣地跳过"规划完成率"这个话题，开始讨论明年的规划。

这个剧本，我见过太多次了。不是某一个团队的问题，几乎是一个行业现象。

规划是怎么死的

先说最常见的死法。

业务需求突然插队。 这个不用多解释，做过的都懂。理财业务突然要接一个新的资产类型，运营搞了个紧急活动，合规要求两周内整改——这些事情不会出现在你的规划PPT里，但它们会吃掉团队80%的产能。技术规划在业务需求面前，脆弱得像一张纸。

人力被抽调。 规划写的时候按10个人算的，Q1过完走了2个，Q2又借调1个去支援别的项目。你拿7个人去做10个人的规划，能完成就有鬼了。