先整理？

第 30 章 君士坦丁的等价性

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

我还记得，作为一名年轻的程序员，我曾听到过一些可怕的报告，称软件开发成本的 70% 都用于维护。70%！我们的工作该有多糟糕，以至于我们做了一个东西，却不得不花两倍的钱来维持它的运行？

事实证明，软件的心智模式，就像某种永动机一样，制造出来就应该永远运行下去，一成不变，这与实际情况恰恰相反，也与应该发生的情况恰恰相反。系统的未来价值体现在今天的现实中，而不是昨天的猜测。

有了耦合对软件开发的影响，我们就可以理解耦合的意义了。在关于耦合和内聚的原著《结构化设计》中，Ed Yourdon 和 Larry Constantine 假设软件设计的目标是最小化软件的成本（同时也是最大化价值，但我们将讨论这个问题）。但这些成本是什么呢？

事实证明，70% 的估算太低了。如果我们发挥创造力，就能在最终开发成本只占百分之几的情况下发布创造价值的软件。这样做符合每个人的最佳利益。我们越早从实际使用中获得反馈，就越少在无关紧要的行为上花费时间/金钱/机会。

我称之为 "君士坦丁等价关系 "的第一个术语是，软件的成本约等于改变软件的成本。是的，在我们 "改变 "软件之前有一段短暂的时间，但谁会在乎呢？这段时间在经济上是微不足道的。那么

成本（软件） ~= 成本（变化）

另一种思考问题的方法是图表。(以下内容并非实际数据，只是思考问题的另一种方法。请相应调整）。

如果我们将软件在其生命周期内的累计成本绘制成图，就会得到类似于逻辑曲线的结果（图 30-1）。发布前的时间只占总时间和总成本的一小部分。

图 30-1. 累计成本的对数曲线显示，变化是大部分费用的来源

我们如何看待变革的成本？所有变革都是平等的吗？当然不是。我们可以磕磕绊绊地对系统的行为做一些小的改变，所有这些改变的成本都差不多。然后有一天，我们做了一个表面上与之前所有改变相似的改变，但这个改变却让我们大吃一惊。代价不是一个单位，而是十个、一百个或一千个单位。

形象地说，每月成本（比如说）开始时很低，增长很快，然后随着其他机会变得更有利可图而缩减（图 30-2）。但为什么发布后成本增长的斜率会陡峭得多？我们真的做了更多的改动吗？是的，多了一些。但同时，现有系统也开始产生摩擦。我们不得不担心向后兼容性。我们不得不担心生产的稳定性。我们不得不担心任何一个改动都可能会破坏看似无关的功能。

图 30-2. 单位时间成本缓慢增长，然后迅速增长，最后缩小

如果你对幂律分布有所了解，，你就会知道这里发生了什么（如果你不了解幂律分布，请小心，因为我为它痴迷了 20 年）。幂律分布的一个特点是，少数几个大的 "离群 "事件非常重要。把它们加起来，就会超过数量更多的 "正常 "事件。五次最大的风暴造成的破坏比一万次小风暴造成的破坏还要大。

听起来是不是很熟悉？最昂贵的行为改变所花费的成本，远远超过所有最不昂贵的行为改变所花费的成本总和。换句话说，改变的成本约等于重大改变的成本：