软件设计的方程 » 代码简洁性
代码简洁性
代码简洁性：软件设计的方程
2010年1月6日，作者：Max Kanat-Alexander
今天我在琢磨一个小方程，它或许能解释几乎所有软件设计原则。虽然我不知道它是否能用数字严格求解，但它确实展示了软件开发决策中的因素及其相互关系。不过在介绍方程之前，我必须先定义设计师在决定是否实现某个功能或如何实现时考虑的因素：
实现潜在价值（简称Vi）：实现这个功能有多“有价值”？例如，如果我们在程序中添加能直接防止用户死亡的功能，那就非常有价值。如果只是可能避免未来某个错误消息中的拼写错误，那就几乎没什么价值。
“价值”可以针对最终用户或其他程序员。当我们讨论仅影响代码而不影响最终用户的设计决策时，灵活性是主要价值之一——这种灵活性有多重要？
潜在价值与需要它的情境发生的可能性是分开的。这是下一个问题。
价值概率（简称Pv）：这个价值实际上被最终用户（针对功能或变更）或其他开发者（针对设计决策）实现的几率是多少？如果我们添加代码灵活性以允许与外星猿类接触，那概率非常低。如果我们添加一个对每个用户都有立即用处的功能，那概率就是100%。（功能对用户的有用程度也是价值概率的一部分。）
实现成本（简称Ei）：实现这个功能有多难？这是一次性成本——首次创建所需工作的即时难度。这可能以人时衡量。
维护成本（简称Em）：未来维护这个功能需要多少努力？（这包括因实现该功能而增加的整个程序的维护工作。）它会复杂化整个系统的维护吗？这是一个随时间增长的量。与实现成本类似，它很可能以人时衡量。
我们试图确定的是实现可取性（简称D）。这回答了“我们是否应该做这个？”和“实现它的优先级应该是什么？”的问题。
方程的最简形式是：
D = (Pv * Vi) / (Ei + Em)
或者用英语说：实现可取性与价值概率和实现潜在价值成正比，与总成本（实现成本加维护成本）成反比。
然而，这个简单方程缺少一个关键因素：时间。我们实际想知道的是当时间趋近于无穷时这个方程的极限，那会给出真正的实现可取性。让我们从逻辑角度看看：
- 实现成本是一次性成本，从不改变，因此基本不受时间影响。
- 实现价值可能随时间增加或减少，取决于功能。它不可预测，因此为了这个方程，我们可以假设它是一个不随时间变化的静态值（尽管如果你的情况不同，请记住这个因素）。甚至可以认为维护成本实际上是“维持这个价值水平所需的努力”，因此价值确实会随时间保持完全固定。
- 价值概率作为概率，随时间趋近于无穷而趋近于1（100%）。
- 维护成本基于时间，随时间趋近于无穷而趋近于无穷。
乍一看，这似乎意味着设计无望，因为维护变成无限努力——没有潜在价值能超越的量——而且似乎必须考虑所有可能性，因为给定无限时间，概率似乎表明每种可能性都会发生。但这些陈述并不真实，因为你必须考虑这两个项目增加的速率。如果维护的基本努力很小，那么即使时间推移，它也会保持很小。可以说任何设计决策或功能都有一个“维护系数”，它决定了维护努力随时间累积的速度。
就价值概率而言，如果它是一个非常小的数字，它可能保持很小直到数千年或数百万年过去——因此如果维护成本以高速率增加，那么它很容易超过价值概率，并且随着时间趋近于无穷，实现可取性将趋近于零。
这个方程实际告诉我们的是，在时间方面，要平衡的最重要因素是价值概率与维护成本。如果价值概率高而维护成本低，那么可取性仅取决于实现潜在价值与实现成本——产品经理可以轻松做出的决定。如果价值概率低而维护成本高，实现的唯一理由将是近乎无限的实现潜在价值。
这有趣地说明了为什么编程语言和开发框架的微小改进会导致最终产品的巨大变化——因为维护成本的微小降低可以极大改变实现可取性。否则会被产品经理视为不可能而丢弃的功能成为基本设计计划的一部分。打磨UI变得更具可取性，因为它需要更少的实现和维护努力。
最后，我认为这最准确和真实地传达了为什么简洁性如此重要——因为简洁性决定了上面讨论的“维护系数”。维护简单代码所涉及的努力随时间增加非常缓慢——有时如此缓慢，以至于在你的一生中都不必投入任何维护努力。
关于这个方程还有更多可说的。你有什么想法？有人对如何数值计算实现价值，或者它是否可能分解为一组其他可数值计算的因素有想法吗？无论你想说什么，我都很感兴趣。
-Max
分享 点击在Facebook上分享（在新窗口中打开） Facebook
点击在LinkedIn上分享（在新窗口中打开） LinkedIn
点击在Hacker News上分享（在新窗口中打开） Hacker News
点击在Reddit上分享（在新窗口中打开） Reddit
点击在Threads上分享（在新窗口中打开） Threads
点击在X上分享（在新窗口中打开） X
27条评论 留下回复
Havvy 说：2010年1月6日下午3:39
你的方程中有一个百分比和一个非百分比。如果你让两者都成为非百分比，维护似乎就不那么令人生畏了。应该查看该函数对时间的导数来回答此类问题。当然，要做到这一点，你必须正式将时间添加到方程中。
回复
Max Kanat-Alexander 说：2010年1月6日下午3:45
我不太明白你关于百分比的点。概率根据定义是百分比。
如果我们说 Em = C * t1，其中 C 是维护系数，t1 是时间，那么我们关心的是维护系数，尽管它本身可能是其他东西的导数。
-Max
回复
Max Kanat-Alexander 说：2010年1月6日下午3:47
更多是给自己笔记，可能 C 的最佳单位是“人时/小时”，其中 1 表示“这是全天24小时连续工作直到永远。”
回复
Mark Castillo 说：2010年1月6日下午4:40
时间 T 在哪里？
哦，糟糕……我应该进一步阅读..你提到了。哈哈……
“然而，这个简单方程缺少一个关键因素：时间”
回复
johnjbarton 说：2010年1月6日晚上8:48
这个方程还告诉我们“永远不要维护软件”。既然你无法控制 Pv，你应该让 Em 为零，并不断在不同的产品上投资 Ei，直到找到大的 Vi。然后将你的初创公司卖给某个处理 Em 的傻瓜，而你在海滩上喝玛格丽塔酒。哦，等等，它告诉我们更多：你应该支付大量其他人‘Ei’，然后将 Vi 赢家卖给傻瓜。然后你成为风投。
回复
Max Kanat-Alexander 说：2010年1月7日上午7:19
哈哈！！我喜欢。 🙂
（对于任何太认真对待的人——Em 当然是维护努力，无论你是否维护它；它只是变更将需要的固有维护努力。）
-Max
回复
Tony Mechelynck 说：2010年1月7日上午10:41
你的方程中有一些模糊定义的术语，也许应该如此，因为定义将取决于距离和视野的广度。让我解释。例如，什么是“一个产品”？在最远和最广的视野中，Netscape 4之前、6-7和8-9、Mozilla Suite、Firefox、Thunderbird、SeaMonkey等，都组成“一个产品”。当我们更近地看细节时，Netscape 4之前是一个产品，Netscape 6+是一个或两个，Firefox是一个，Thunderbird是一个，Mozilla Suite与SeaMonkey一起是一个、两个或三个（我不确定，如果是两个，边界应该放在Sm 1.x之前还是之后？），等等。从更近处看，每个主要版本（Fx1、Fx1.5、Fx2、Fx3.0等）本身就是“一个产品”。
我相信这些观点都是合理的，并且你的方程可以有效地应用于每个（当然要选择适当的系数）；但当从一个观点转到下一个时，每个“子产品”的部分或全部Ei（除了第一个）被纳入更大整体的Em中，或者在放大时反之亦然。
现在问题出现了：Netscape是否应该通过什么都不做来做得更好？到目前为止，已经投入了巨大人力和其他资源到前面提到的更大“产品”中。该投资是否“回报”将取决于如何衡量Vi，考虑是的，美元，还有选择自由、可定制性等。此外，Vi应该衡量为投资劳动和/或金钱的人和法律实体的“投资回报”，还是为全世界总利益？
回复
Max Kanat-Alexander 说：2010年1月7日上午11:34
这些都是非常好的问题。
我会说最终，人们可以衡量全世界的Em和Ei——一个人可能做出严重糟糕的API选择，会严重增加库用户的Em，这可能是要考虑的事情。不过通常，“单个项目”是明确定义的，而且我必须个人做出的大多数决策很容易通过限制自己手头的因素来判断，我用自己的判断为每个单独决策单独确定。
衡量Vi的方法目前确实未确定。我认为这在某种程度上取决于设计师及其目标。我认为金钱在某些情况下是衡量其中一些事物的完全有效方式（事实上，如果你愿意，你可以用金钱衡量Vi、Em和Ei，并得出一个可数值求解的方程，尽管它可能不是足够广泛的Vi衡量，并且确定Vi的货币价值本身就是一整本书），但作为开源开发者，我考虑全世界总利益比考虑ROI更多。
-Max
回复
Max Kanat-Alexander 说：2010年1月7日上午11:35
我会说最终，人们可以衡量全世界的Em和Ei——一个人可能做出严重糟糕的API选择，会严重增加库用户的Em，这可能是要考虑的事情。
尽管考虑那个，如果你是一个库，Vi可能是“减少其他项目的Em”，所以你甚至不必搞得太复杂。
-Max
回复
Alex Vincent 说：2010年1月8日上午12:26
你称那为简单英语？我必须承认我解析那个句子有些小麻烦。我想我更好地理解方程了。:-p
回复
Max Kanat-Alexander 说：2010年1月8日上午9:25
哈哈哈，那是足够公平的陈述。我从前面的句子中删除了“简单”这个词。 🙂
回复
Janson 说：2010年1月11日上午8:52
它假设编程是一门科学。我认为应该是艺术。它要么美丽，要么不美丽。考虑到通常进入编程的热门人才，如果你给他们任何超越指南的东西，那将是侮辱。这个方程无论如何在数学上不严谨，tjohnjbarton建议 你觉得这个“编程美学的一般原则——读者解释方程”怎么样？
回复
Max Kanat-Alexander 说：2010年1月11日下午1:23
嘿Janson。编程是一门科学。任何科学的应用都是一门艺术，但仅仅因为有人没有正确发展编程科学，并不意味着这样的科学不能或不应该存在。就像建桥一样——背后的数据是科学的，但工程师如何选择应用科学是优雅匹配约束等的艺术。
你知道，我认为你实际上可以对方程进行数学严谨的证明。我没有研究过，但我认为它是可能的。
-Max
回复
Janson 说：2010年1月12日上午1:43
嗯。
嗯，我编过程，主要是为我的系统模拟课程，做了足够多让它无错误运行，但也花了很多时间。所有时间，我都在画流程图，并试图给我的“流动”想法形状。
而那些用我一半时间完成的人只是兰博式。他们不断敲键盘就做到了。我 tempted 要说关于10000头驴和莎士比亚作品的谚语，但我意识到我是那个打字10000年的人。
我讲述这个轶事是因为所有做到的人都吹嘘他们如何凭“直觉”、艺术地等做到。你知道大学生如何吹嘘。但然后，大学编程一点也不像大型软件开发活动。
嗯，我不再定期编程，但命令一个卑微信徒机器的魅力仍然吸引我。我浏览了你之前的帖子，你似乎说的正好相反我过去相信的。但嘿，你是真正的热门人物。
回复
Max’ Lesestoff zum Wochenende | PHP hates me - Der PHP Blog 说：2010年5月14日晚上8:58
[…] HTML5 如何检测浏览器某些功能（HTML5）的很好总结
代码简洁性 » 软件设计的方程 今天我在琢磨一个小方程，它或许能解释几乎所有软件设计原则。 […]
回复
Nick Barnes 说：2010年12月13日上午7:18
你需要考虑贴现率：今天100万美元在2100年的成本远少于100万美元。
回复
Max Kanat-Alexander 说：2010年12月13日上午11:37
嗯，是的，通货膨胀发生，但我们主要讨论努力，通货膨胀背后的一般思想是投入生产的努力量总是得到 adequate 补偿。所以，无论现在一个月程序员时间成本多少，它在2100年将成本“相同”，即使那个“相同”量是更大的美元数字。所以最终，那个因素在功能开发可取性考虑中无关紧要。
-Max
回复
cazare bran 说：2011年1月13日上午7:15
维护成本..你应该总是维护它（在我看来）
回复
Jenny 说：2011年1月15日上午5:18
IMHO，通货膨胀只有当供应链的原始来源受到影响时才会发生。其次，像Max说的，某些xyz量的“价值”将总是与几十年甚至几百年后的“价值”直接成正比。那是因为努力相同！
和平，Jenny
回复
Locusto 说：2011年4月15日下午2:30
我想我正处于可以测试你方程有效性的项目中间。得检查我老板会怎么说。 🙂
回复
Max Kanat-Alexander 说：2011年4月15日下午5:30
酷！顺便说一下，我有一个更新版本的方程，我应该给你。基本上：
D = (Vn + Vf) / (Ei + Em)
Vn = 现在价值 Vf = 未来价值 Ei = 实现成本 Em = 维护成本
随时间减少到：
D = Vf / Em
-Max
回复
Mike Spooner 说：2011年7月21日上午2:12
关于“允许通货膨胀”话题，记住价值与价格之间有区别。价值可以恒定而价格变化。
回复
理解软件的价值 | Software Dev 2k 说：2011年10月25日上午2:53
[…] 最近发现了Max Kanat-Alexander的这篇文章，试图创建一个数学公式来确定是否[…]
回复
George Kalfopoulos 说：2011年10月25日上午2:57
相当迷人的阅读。
几天前我写了一篇关于软件价值的更通用文章（如果有人关心可以在这里找到 http://softwaredev2k.com/2011/10/understanding-the-value-of-software/），我今天更新了链接到这篇文章供更数学倾向的人。
确实很棒的工作！
回复
软件设计定律 « The Laughing Programmer 说：2013年5月3日上午6:52
[…]（公式在他的网站上已更改）。 […]
回复
代码简洁性书评 | Tipping Point Media Studios 说：2016年8月14日下午5:52
[…] 2. 软件设计的方程：（这里是一篇详细博客文章解释这个古怪方程-链接） […]
回复
什么造就了伟大的开发者体验？ » 代码简洁性 说：2025年4月15日上午3:03
[…] 记住，在软件中，减少维护成本比减少创建成本更重要。所以你必须考虑工具的直接影响（和直接[…]
回复
留下回复取消回复
联系 关于 书：理解软件 书：代码简洁性
输入你的邮箱… 订阅
© 2025 版权所有。由The Fox提供支持。
管理同意
为了提供最佳体验，我们使用像cookies这样的技术来存储和/或访问设备信息。同意这些技术将允许我们处理数据，如浏览行为或本网站上的唯一ID。不同意或撤回同意，可能会 adversely 影响某些特性和功能。
功能
功能
始终活动
技术存储或访问对于启用订阅者或用