软件设计方程 » 代码简洁性
管理同意
为了提供最佳体验，我们使用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 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 的货币价值本身将是一整本书），但全球总利益是我作为开源开发人员更经常考虑的事情，我认为，而不是将价值放在投资回报率上。 -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 我的时间完成的人只是蛮干。他们不断敲键盘并完成了。我 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 […] 记住，在软件中，减少维护努力比减少创建努力更重要。所以您必须考虑您的工具的即时影响（和即时[…] 回复 留下回复取消回复
联系 关于 书：理解软件 书：代码简洁性 输入您的电子邮件… 订阅 Max Kanat-Alexander6天前 真的很兴奋地宣布我将在2025年开发者生产力工程峰会上发表主题演讲之一。我将谈论什么造就了伟大的开发者体验。我自1995年以来一直在技术领域工作，并且自2004年以来几乎全职从事开发者体验。关于如何使开发者体验伟大，有一些基本的、普遍的真理，我将尽力在有限的时间内覆盖尽可能多的内容。很希望在那里见到您。:) 阅读更多1177分享Max Kanat-Alexander6月27日 我目前认为AI代理可以成功生成的输出数量和质量取决于：
- 模型的质量。
- 代理的质量。
- 输入的质量（如提示或其他上下文）。
- 代理可以独立运行的确定性、客观验证的质量。
我目前认为，除非您是模型开发者，最重要的部分是“确定性、客观验证”。
简单来说，如果您告诉AI做某事，它需要某种方式能够自行验证它做了正确的事。在软件中，这通常意味着运行测试、linter等，如果系统做了错误的事就会失败。
这意味着您的测试和验证工具越好，您从模型得到的输出就越好。不仅仅是测试数量。它们必须是好的测试，有智能断言和好的错误消息。
这也意味着代理成功涉及思考如何将任务分解成可以各自通过自动化测试、linter等客观验证的单独部分。
作为说明，输入的质量也很重要并在我们的控制之下。如果我们编写更好的文档和更清晰的代码，代理会做得更好。令人惊讶的是，几乎一切帮助人类编写代码的东西也帮助代理。 阅读更多2510分享Max Kanat-Alexander6月