软件设计方程 » 代码简洁性
管理同意
为了提供最佳体验，我们使用诸如Cookie等技术来存储和/或访问设备信息。同意这些技术将允许我们处理数据，例如在本网站上的浏览行为或唯一ID。不同意或撤回同意可能会对某些特性和功能产生不利影响。
功能性
始终活跃
技术存储或访问严格用于合法目的，即启用订阅者或用户明确请求的特定服务，或仅用于通过电子通信网络传输通信的唯一目的。
偏好
技术存储或访问对于存储订阅者或用户未请求的偏好是必要的合法目的。
统计
技术存储或访问专门用于统计目的。技术存储或访问专门用于匿名统计目的。没有传票、互联网服务提供商的自愿合规或来自第三方的额外记录，仅为此目的存储或检索的信息通常无法用于识别您。
营销
技术存储或访问需要创建用户配置文件以发送广告，或在网站或跨多个网站上跟踪用户以用于类似的营销目的。
管理选项 管理服务 管理{vendor_count}供应商 阅读更多关于这些目的 接受 拒绝 查看偏好 保存偏好 查看偏好 Cookie政策 {title} 法律声明
代码简洁性
软件设计方程
2010年1月6日 by Max Kanat-Alexander
今天我在玩一个小方程，它可能实际上解释了软件设计的几乎所有原则。我不知道它是否在数字上可数学求解，但它确实展示了软件开发决策中存在的因素以及它们如何相互关联。
在我深入方程之前，我必须定义设计师在决定是否实现某事或如何实现它时存在的因素：
实现潜在价值（简称Vi）：实现这个有多“有价值”？例如，如果我们向程序添加一些可以直接防止某人死亡的东西，那非常有价值。如果它只是可能防止未来单个错误消息中的拼写错误，那几乎毫无价值。
“价值”可以是针对最终用户或其他程序员的。当我们谈论仅影响代码而不影响最终用户的设计决策时，灵活性是主要价值之一——这种灵活性有多重要？
潜在价值与您需要它的情境发生的可能性是分开的。这是下一个问题。
价值概率（简称Pv）：这个价值实际上被最终用户（对于功能或功能更改）或另一个开发人员（对于某些设计决策）实现的机会有多大？如果我们添加代码灵活性以允许与外星猿潜在接触，那不是一个非常可能发生的事件。如果我们添加一个对每个用户立即有用的功能，那就是100%的概率。（一个功能将对多少用户有用也是价值概率的一部分。）
实现努力（简称Ei）：实现这个有多难？这是一次性成本——首次执行创建此事物所需工作的即时难度。这可能以人时来衡量。
维护努力（简称Em）：未来维护这个需要多少努力？（这包括通过实现此事物添加到维护整个程序的任何努力。）这会复杂化整个系统的维护吗？这是一个随时间增加的金额。与实现努力类似，这很可能以人时来衡量。
我们试图确定的是实现合意性（简称D）。这回答了“这是我们是否应该做的事情？”和“实现这个的优先级应该是什么？”的问题。
方程的最简单形式是： D = (Pv * Vi) / (Ei + Em)
或者，用英语说：实现合意性与价值概率和实现潜在价值成正比，与总努力成反比，总努力包括实现努力加上维护努力。
然而，这个简单形式的方程缺少一个关键因素：时间。我们实际想知道的是当时间接近无穷大时这个方程的极限，这给了我们真正的实现合意性。所以让我们从逻辑角度来看：
实现努力是一次性成本，从不改变，所以大多不受时间影响。
实现价值可能随时间增加或减少，取决于功能。这是不可预测的，所以为了这个方程，我们可以假设它是一个不随时间变化的静态值（尽管如果您的情况不是这样，请记住这个因素）。甚至可以认为维护努力实际上是“维持这个确切价值水平所需的努力”，这样价值确实会随时间保持完全固定。
价值概率，作为一个概率，随时间趋于无穷大而接近1（100%）。
维护努力，基于时间，随时间趋于无穷大而接近无穷大。
乍一看，这可能听起来好像设计是无望的，因为维护变得无限努力——一个没有潜在价值可以超越的金额——而且似乎必须考虑每一种可能性，因为给定无限时间，概率似乎表明每一种可能性都会发生。然而，这些不是真实的陈述，因为您必须考虑这两个项目增加的速率。如果维护的基本努力非常小，那么即使时间推移，它也会保持小。您可以说任何设计决策或功能上都有一个“维护系数”，这决定了维护努力随时间积累的速度。
就价值概率而言，如果它是一个非常小的数字，它可能保持小直到数千年或数百万年过去——所以如果维护努力以高速率增加，那么它将很容易超过价值概率，并且实现合意性将随时间趋于无穷大而接近零。
这个方程实际告诉我们的是，就时间而言，要平衡的最重要因素是价值概率与维护努力。如果价值概率高且维护努力低，那么合意性仅取决于实现潜在价值与实现努力——产品经理可以轻松做出的决定。如果价值概率低且维护努力高，实现的唯一理由将是近乎无限的实现潜在价值。
这有趣地表明了为什么编程语言和开发框架的小改进会导致最终产品的巨大变化——因为维护努力的微小减少可以对实现合意性产生巨大变化。否则会被产品经理扔掉的 impossible 功能成为基本设计计划的一部分。抛光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 pre-4、6-7 和 8-9、Mozilla Suite、Firefox、Thunderbird、SeaMonkey 等，都构成“一个产品”。当我们更近地看并更详细地看时，Netscape pre-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 的货币价值本身将是一整本书），但全球的总收益是我作为开源开发人员更经常考虑的事情，我认为，而不是我将价值放在投资回报率上。
-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 嗯。
嗯，我编程过，主要是为了我的系统模拟课程，并且做了足够多以无错误运行，但也花了很多时间。所有时间，我都在画流程图，并试图给我的“流动”想法赋予形状。
而那些在 half 我时间完成的人只是去了 Rambo。他们不断敲键盘并完成了。我 tempted 说关于 10000 头驴和莎士比亚作品的谚语，但我意识到我是那个打字 10000 年的人。
我讲述这个轶事是因为所有完成的人都吹嘘他们如何通过“本能”、艺术地等完成。您知道大学生如何吹嘘。但然后，大学编程一点也不像主要的软件开发活动。
嗯，我不再定期编程，但指挥一个卑贱的机器奴隶的魅力仍然吸引我。我浏览了您之前的帖子，您似乎说的正是我过去相信的反面。但嘿，您是真正的热门人物。
回复
Max的周末阅读材料 | PHP hates me - Der PHP Blog 说： 2010年5月14日下午8:58 […] HTML5 很好的摘要关于如何确定浏览器的某些功能（HTML5） 代码简洁性 » 软件设计方程 今天我在玩一个小方程，它可能实际上解释了软件设计的几乎所有原则。 […]
回复
Nick Barnes 说： 2010年12月13日上午7:18 您需要计入贴现率：今天$1M在2100年的成本远低于$1M。
回复 Max Kanat-Alexander 说： 2010年12月13日上午11:37 嗯，是的，通货膨胀发生，但我们主要谈论努力，而通货膨胀背后的一般思想是投入生产的努力量总是得到充分补偿。所以，无论现在一个月程序员时间成本多少，它在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 提供支持。 管理同意联系 关于 书：理解软件 书：代码简洁性 转到顶部