软件设计方程 » 代码简洁性
2010年1月6日 by Max Kanat-Alexander
今天我在研究一个小方程，它可能实际上解释了几乎所有软件设计的原则。虽然我不知道它是否能在数学上用数字求解，但它确实展示了软件开发决策中存在的因素以及它们之间的关系。
在深入探讨这个方程之前，我必须定义设计师在决定是否实现某个功能或如何实现时所考虑的因素：
实现潜在价值（简称Vi）：实现这个功能有多“有价值”？例如，如果我们向程序添加一些可以直接防止某人死亡的功能，那将非常有价值。如果它只是可能防止单个错误消息中的未来拼写错误，那几乎毫无价值。
“价值”可以是针对最终用户或其他程序员的。当我们谈论仅影响代码而不影响最终用户的设计决策时，灵活性是主要价值之一——这种灵活性有多重要？
潜在价值与您需要它的情境发生的可能性是分开的。这是下一个问题。
价值概率（简称Pv）：这个价值实际上被最终用户（对于功能或功能变更）或另一个开发者（对于某些设计决策）实现的几率是多少？如果我们添加代码灵活性以允许与外星猿类潜在接触，那不是一个非常可能发生的情况。如果我们添加一个对每个用户都有立即用处的功能，那就是100%的概率。（一个功能对多少用户有用也是价值概率的一部分。）
实现努力（简称Ei）：实现这个功能有多难？这是一次性成本——首次创建这个东西所需工作的即时难度。这可能以人时来衡量。
维护努力（简称Em）：未来维护这个功能需要多少努力？（这包括通过实现这个功能而增加的维护整个程序的任何努力。）这会复杂化整个系统的维护吗？这是一个随时间增加的金额。与实现努力类似，这很可能以人时来衡量。
我们试图确定的是实现合意性（简称D）。这回答了“我们是否应该做这个？”和“实现这个的优先级应该是什么？”的问题。
方程的最简单形式是： D = (Pv * Vi) / (Ei + Em)
或者，用英语来说：实现合意性与价值概率和实现潜在价值成正比，与总努力（包括实现努力加上维护努力）成反比。
然而，这个简单形式的方程缺少一个关键因素：时间。我们实际上想知道的是当时间趋近于无穷时这个方程的极限，这给了我们真正的实现合意性。所以让我们从逻辑角度来看：
实现努力是一次性成本，从不改变，所以基本上不受时间影响。
实现价值可能随时间增加或减少，取决于功能。这是不可预测的，因此为了这个方程，我们可以假设它是一个不随时间变化的静态值（尽管如果您的情况不是这样，请记住这个因素）。甚至可以认为维护努力实际上是“维持这个确切价值水平所需的努力”，这样价值确实会随时间保持完全固定。
价值概率，作为一个概率，随着时间趋近于无穷而趋近于1（100%）。
维护努力，基于时间，随着时间趋近于无穷而趋近于无穷。
乍一看，这可能听起来好像设计是无望的，因为维护变成无限努力——一个没有任何潜在价值可以超越的金额——而且似乎必须考虑每一种可能性，因为给定无限时间，概率似乎表明每一种可能性都会发生。然而，这些陈述并不真实，因为您必须考虑这两个项目增加的速率。
如果维护的基本努力非常小，那么即使时间推移，它也会保持很小。您可以说任何设计决策或功能上都有一个“维护系数”，这决定了维护努力随时间积累的速度。
就价值概率而言，如果它是一个非常小的数字，它可能保持很小直到数千或数百万年过去——所以如果维护努力以高速率增加，那么它将轻易超过价值概率，并且实现合意性将随着时间趋近于无穷而趋近于零。
这个方程实际上告诉我们的是，就时间而言，要平衡的最重要因素是价值概率与维护努力。如果价值概率高而维护努力低，那么合意性仅取决于实现潜在价值与实现努力——产品经理可以轻松做出的决策。如果价值概率低而维护努力高，实现的唯一理由将是近乎无限的实现潜在价值。
这有趣地表明了为什么编程语言和开发框架的小改进会导致最终产品的巨大变化——因为维护努力的微小减少可以对实现合意性产生巨大变化。否则会被产品经理视为不可能而丢弃的功能成为基本设计计划的一部分。抛光UI变得更有合意性，因为它需要更少的实现和维护努力。
最后，我认为这最准确和真实地传达了为什么简洁性如此重要——因为简洁性决定了上面我谈到的“维护系数”。维护简洁代码所涉及的努力随时间增加非常缓慢——有时如此缓慢，以至于在您的一生中永远不必投入任何维护努力。
关于这个方程还有很多可以说的。您对此有什么想法？有没有人关于如何数值计算实现价值，或者它是否可以分解为一组其他可数值计算的因素？您对此有任何要说的，我都感兴趣。
-Max
评论
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，这可能是要考虑的事情。不过，通常，“单个项目”是明确定义的，而且我必须 personally 做出的大多数决策很容易通过将自己限制在手头的因素来判断，我用自己的判断为每个单独决策单独确定。 衡量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年的人。 我叙述这个轶事是因为所有那些完成的人都吹嘘他们如何通过“本能”、巧妙地等完成。您知道大学生如何吹嘘。但然后，大学编程一点也不像主要的软件开发活动。 嗯，我不再定期编程，但指挥一个卑贱的机器奴隶的魅力仍然吸引着我。我浏览了您之前的帖子，您似乎说的 exactly 与我曾经相信的相反。但嘿，您是真正的热门人物。
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年的成本 much, much less than 100万美元。
Max Kanat-Alexander 说：2010年12月13日上午11:37 嗯， true，通货膨胀发生，但我们 mostly 谈论努力，而通货膨胀背后的一般想法之一是投入生产的努力量总是得到 adequate 补偿。所以，无论现在一个月程序员时间成本多少，它在2100年将花费“相同”，即使那个“相同”金额是 much larger 数量的美元。所以最终，那个因素在考虑功能开发合意性时无关紧要。 -Max
cazare bran 说：2011年1月13日上午7:15 维护努力..您应该 always 维护它（在我看来）
Jenny 说：2011年1月15日上午5:18 IMHO，通货膨胀 only 发生在供应链的原始来源受到影响时。其次，像Max说的，一些xyz金额的“价值”将 always 与几十年甚至几世纪后它具有的“价值” directly proportional。那是因为努力是相同的！ 和平，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-Alexander 7月28日 真的很兴奋地宣布我将在2025年开发者生产力工程峰会上发表其中一个主题演讲。我将谈论什么造就了伟大的开发者体验。我自1995年以来一直在技术领域工作，并且自2004年以来几乎全职从事开发者体验。关于如何使开发者体验伟大，有一些基本的、普遍的真理，我将尽力在我有时间内覆盖尽可能多的内容。很希望在那里见到您。:) 阅读更多 131 11 分享
Max Kanat-Alexander 6月27日 我目前认为，AI代理可以成功生成的输出数量和质量取决于：
- 模型的质量。
- 代理的质量。
- 输入的质量（如提示或其他上下文）。
- 代理可以独立运行的确定性、客观验证的质量。 我目前认为，除非您是模型开发者，否则最重要的部分是“确定性、客观验证”。 简单来说，如果您告诉AI做某事，它需要某种方式能够自行验证它做了正确的事。在软件中，这通常意味着运行测试、linter等，如果系统做了错误的事就会失败。 这意味着您的测试和验证工具越好，您从模型得到的输出就越好。不仅仅是测试数量。它们必须是好的测试，具有智能断言和好的错误消息。 这也意味着代理成功涉及思考如何将任务分解成可以各自通过自动化测试、linter等客观验证的单独部分。 作为笔记，输入的质量也很重要并在我们的控制之下。如果我们编写更好的文档和更清晰的代码，代理会做得更好。令人惊讶的是，几乎一切帮助人类编写代码的东西也帮助代理。 阅读更多 25 10 分享
Max Kanat-Alexander 6月4日 技术债务有价值的想法 mostly 是一个神话。当您做出糟糕的软件工程决策时，它将在几小时、几天或几周内减慢您的速度。那是上限。许多人认为需要几个月或几年才能看到在软件设计上偷工减料的影响，但那 simply 不真实。它几乎立即开始。做正确事的成本通常是几小时，也许一天，而且您几乎总是立即 recover 那个时间。也就是说，做对通常花费与做错相同的时间。“等等，什么？那怎么可能？我们偷工减料是为了节省时间！”它几乎总是结果根本不节省您时间！它使处理变更更加混乱。它使代码审查更长。它在测试期间以更混乱的方式失败，需要更长时间调试。它几乎从不节省您实际时间。 偶尔，您的路径中有一些“岩石”如此巨大，您 simply 无法移动它。没有人应该花费三个月设计一个新工具，只是为了您可以一次交付一个一天的功能。但那是技术债务决策的 tiny, tiny 部分。 这变得更疯狂，因为如果您在过程中做对一切（您总是重构系统，使其看起来像是设计来做 exactly 它现在做的事情），那么一切在整个过程中保持相对容易。但如果您偷工减料，一切变得复合性地更加困难，以至于您生成“岩石”没有人可以移动。不像复杂性是某种线性事物，您可以 later 回去投资线性时间修复。您绝对可以使自己陷入如此糟糕的境地，以至于您公司中