单机游戏《戴森球计划》从立项一开始就将优化放在很高的位置，为什么没有「过早优化是万恶之源」的问题？ 第1页

个人理解，简单说，范畴不同。

成功的验证过程，并不代表着整个过程中不存在某个个体的过早优化。

而某个个体执行了一次过早优化，也并不影响整个项目有一个成功的验证过程。

以下详细展开分析过程：

词语是信息的凝聚和压缩，而同时也必然带来信息的损失。

“优化”这个词语在不同语境下含义未必一致。

要明确问题，我们最好回到各自的上下文。

先说，“过早优化是万恶之源”：

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

结合上下文看，这句话里“premature optimization ”的指向是非常明确的：

wrong place：典型如，这段代码并未出现在“热点地区”，针对每逻辑帧仅占0.0001ms的调用去优化半个月……还因此固化了一系列假设，因而影响了其它模块的设计自由度……

wrong times：典型如，兴高采烈优化完，做了个自己觉得完美到不能再完美的方案，提交甲方后，需求改了，整个模块废弃。

为什么会出现错误的地点、错误的时间呢？

比较直接的原因，个人感觉，很大的可能是对当前模块目标本身的不明确：不明确当前模块在整个系统中所处的地位、亦不明确当前开发过程的目标和路径，因而，也就无法明确当前模块的各种量化目标、甚至连接口都无法确定。（这种不确定，不是说是此开发者有责任，只是某种客观的状态，策划那边如果这个想试试、那个也想试试，同样会导致程序设计目标难以明确）

不确定，就有充分的空间去“赌”，赌系统接下来可能的要求，赌团队接下来可能的动向……因而也就基于这些——并不真实存在的——结构和量化指标，产生了“过度设计”和“过早的优化”。

在需求和方向混沌未明的情况下，采取保守一些的策略，比如最小化接口、保持简单、仅完成覆盖需求的最小功能集合，当然未必优雅、未必完美，但是，出了问题好调整，全模块废弃导致的损失也不大。

从减少资源浪费的角度来看，这种“放弃优化”的“保守”，自然也会是相对有利的策略。

再说戴森球的“优化”语境

个人对这个项目并不是很了解，也许会说错，容在下先行道歉。

戴森球前阵子粗略看了篇文档讲他们的开发过程，貌似提到了他们一开始就开展了针对性的技术验证。不知道这个是不是就是题主所说的“将优化放在高位”。

验证过程本身是一个循环迭代过程，当前的工作结果汇集起来，核心团队根据这些信息调整方案、固化框架，工程师再根据新的动向进行调整，如此往复多次。

如果这个过程名为“将优化摆在重要位置”，那么，这个的涵义显然不是过早优化的那个涵义。

举个例子就好理解了（这个例子完全是脑补的，只为解释问题）：

假如，球体的分割方案做过多个版本。

假如，第一个版本做的时候，要求是重点验证分割后球体的渲染性能，不存在对内存和io的需求，某位开发者却仍然给自己加了诸如内存优化、io优化等一系列工作量。

结果，第一版方案，由于性能就没达标，整体被推翻，此君的所有这些内存和io相关的工作都浪费了。

假如发生了这样的事情，那就是说，对于这位开发者而言，仍然进行了“过度优化”。

但是，整个验证过程却仍然达成了目标：即，第一版方案关键指标得到量化，并基于量化结果被淘汰。

因而，就有了一开始的结论：两个“优化”所述的语义，范畴不同。

验证阶段是完全可能对目标模块提出明确的量化指标要求的。比如单次执行在10ms内、同时内存占用在50MB以内。

模块设计过程中，考虑到这些指标做出的设计，也许可以被称为优化，但显然不是过早优化

——因为目标是明确的、已知的，而不是基于个人的主观想象。

也许，这就是语义发生混淆的地方吧？