这句话已经被引用了 年。

它依然有效，恰恰是因为它描述的那个陷阱。从来没有真正被解决过——开发者总是在不该调整的时候调整、不该抽象的时候抽象、不该重写的时候重写。

这篇文章不打算讲故事，也不堆砌名词。我们用软件工程史上几个被反复验证、有据可查的论断和案例。来客观地说清楚一件事：

为什么“过度调整”是一种程序性的反模式，还有业界沉淀出的应对方法。

一、它在工程界有名字

痛点：很多团队成员感到困惑，却找不到统一的术语来描述“总是想提前改进代码”的现象。

很多人陷在“调整怪圈”里却不自知，部分原因是它没有一个统一的中文叫法。说起来，但在英文工程语境里它的几种典型形态早已被命名、归类、写进经典著作。

. Premature Optimization

需要澄清的是 Knuth 的原意——他不反对调整他反对的是在测量之前的调整。他完整的论断是：% 的代码不值得被调整，但有 % 的关键方法必须被认真调整。判断该不该调整，要靠 profiling 数据，而不是直觉。

. Speculative Generality

这是 Fowler 在书中明确列出的“代码坏味”之一。再看典型表现，

• 只有一个实现的 interface
• 永远不会被传非默认值的“可配置参数”
• "为了未来 "预留的钩子函数

If you need it,do it;if you don't,don't.

. Gold Plating

指的是在已满足需求后继续添加使用者未要求的功能或细节。在项目管理领域，它被明确列为范围管理风险——因为它会消耗预算、延长周期。且不带来对应的客户价值，

. Bikeshedding

Poul-Henning Kamp 在 年 FreeBSD‑Hackers 邮件列表的著名邮件 "A bike shed on greener grass..." 将其引入软件工程。

Bikeshedding 描述的是注意力错配——团队倾向于在小事上花掉远超主要议题的讨论时间。

• 命名风格争论 → 分钟级讨论却毫无价值
• 缩进/格式占据 % 的评论量
• 真正的架构问题反而没人讨论

二、为什么过度调整是有害的

. 机会成本

Pain point：A 开发者常因追求完美而导致交付延期，客户抱怨“为什么还没上线”。每一小时投入到没有人要求的调整，都是从真正有价值的工作`偷走`时间。不过，

Demerco 和 Lister 在 P​eopleware​ 中指出：知识工作者产能差异不在编码能力。而在注意力如何分配.

. 边际效益递减

Pareto 原则在软件工程领域屡见不鲜。Knuth 那句 “%” 正是同义表达——性能瓶颈通常集中在极少数代码里. 对非热点方法做调整，投入与产出严重失衡。

. 复杂度成本

中 John Ousterhout 提出：

Larry Brooks 在《The Mythical Man‑Month》也强调：The conceptual integrity is most important consideration.

. 反馈延迟成本

把这一过程称为 Build‑Measure‑Learn 循环：未经行业市场验证的假设没有价值，在反馈到来之前所做的一切都可能因方向错误而归零。

Netscape 重写浏览器案例说明沉重代价：

三、为什么我们如此容易陷进去

Pain point：I.T. 团队经常收到 “代码太丑。我要改”，结果导致项目延期、质量下降。

• #1 调整是少数完全可控之事：a b c…在需求变动的大环境下“把这段代码改得更漂亮”成了唯一能掌控结果的任务。其实，
• #2 调整有即时反馈：IDEs 立刻变绿、测试立刻通过而业务价值往往要数周甚至数月才能显现。
• #3 完美主义防御机制："还有一点点可以再打磨"，让开发者逃避真实世界评估与批评。
• #4 与职业身份绑定："我是一名追求优雅代码的工程师" 成为自我认同，而非理性权衡的一部分。

四、领域沉淀的应对原则

. YAGNI

• You predict future needs with low accuracy.
• Even if prediction is correct,more information will be available when you actually implement . This leads to 娱乐ter solutions .
• Pre‑implemented code becomes resistance to future change .

p> Conclusion : Only write code for known and clear requirements . h4> Rule of Three p> Source : Don Roberts。quoted by Martin Fowler in Refactoring . ul> li> First occurrence – write it directly . li> Second occurrence – tolerate duplication . li> Third occurrence – now you really know what is common and what varies . /ul> p> Sandi Metz’s blog post “The Wrong Abstraction ” emphasizes : blockquote> p>Prefer duplication over wrong abstraction.

/blockqoute>

h4>KISS

p> Originated by Kelly Johnson at Lockheed,later adopted widely in software .
blockquote>
p>Simple solutions usually have lower total cost than complex ones.

/blockqoute

。

---