演化架构和紧急设计: 利用可重用代码，第 1 部分：代码与设计之间的关系

核心提示： Reeves 接下来的观点是关于制造成本的，制造成本通常不算工程的一部分，演化架构和紧急设计: 利用可重用代码，第 1 部分：代码与设计之间的关系(2)，但是是工件的总体成本估计的一部分，构建物理实体较为昂贵，或者您一开始并没有完全理解问题，越靠后做决定，这通常是整个生产流程中最昂贵的部分，相反

Reeves 接下来的观点是关于制造成本的，制造成本通常不算工程的一部分，但是是工件的总体成本估计的一部分。构建物理实体较为昂贵，这通常是整个生产流程中最昂贵的部分。相反，正如 Reeves 所说的：

“...软件构建起来很便宜。它廉价得简直就像是免费。”

记住，说这句话的时候，他正在经历 C++ 编译和链接阶段，这可是非常消耗时间的。现在，在 Java™ 领域，每时每刻都有团队冒出来实现您的设计！软件构建现在是如此的廉价，以至于几乎可以忽略。相对于传统的工程师，我们有着巨大的优势。传统工程师肯定也很希望能够免费地建造他们的设计，并进行假设分析的游戏。您能想象吗？如果桥梁工程师能够实时地试验他们的设计，而且还是免费，那么造出来的桥梁将会是多么的精致。

制造是如此容易，这就解释了为什么在软件开发中没有那么高的数学严密性。为了取得可预测性，传统工程师开发了一些数学模型和其他尖端技术。而软件开发人员不需要那种级别的严密分析。构建设计并对其进行测试，比为其行为构建形式化的证明要来得容易。测试就是软件开发的工程严谨度（engineering rigor）。这也导致了 Reeves 的论文中的一个最有趣的结论：

如果软件设计相当容易被证实，并且基本上可以免费构建，那么毫不奇怪，软件设计必将变得极其庞大而复杂。

实际上，我认为软件设计是人类有史以来尝试过的最复杂的事情，尤其是在我们所构建的软件的复杂性不断攀升的背景下。考虑到软件开发成为主流也才大约 50 年的光景，通常的企业软件的复杂性已经令人瞠目。

Reeves 的论文得出的另一个结论是，在目前，软件中的设计（也就是编写整个源代码）是最昂贵的活动。也就是说，在设计时所浪费的时间是最宝贵的资源。这将我们带回到紧急设计上来。如果在开始编写代码之前，花费大量的时间试图参与到所有的事情中来，那么您总会浪费一些时间，因为一开始有些事情是未知的。换句话说，在编写软件时，您总是陷入意想不到的时间黑洞，因为有些需求比您想象的更复杂，或者您一开始并没有完全理解问题。越靠后做决定，就越有把握作出更好的决定 — 因为您所获得的上下文和知识是与时俱增的，如 图 1 所示：