代码预算

天真的答案是它不花钱。字节是免费的-或尽可能接近免费。但这一定要花些钱。毕竟，输入需要花费时间，对吗？因此，这使我们进入了“代码经济学”的第一个规则：代码行的成本是根据我们花在代码上的时间来衡量的。

天真的答案是，代码行的经济价值是应用程序的价值（可以通过各种方式衡量）除以总代码行（LOC）。如果您每月从一千行代码中赚取$ 10,000，则每行会带来$ 10。

但这显然是不正确的。我们知道可以使用一千，一万或十万个LOC编写同一应用程序。应用程序为人们做的事情-它的价值-以及编写它所需的代码量？它们根本不相关。这将我们带到“代码经济学”的第二条规则：代码行毫无价值。它仅在某些可部署应用程序中具有价值。该应用程序是经济价值的最小单位。 （实际上，它是UX流程，但是就我们今天的目的而言，一个应用程序支持一个UX流，用户可以从中找到与之交互的价值。）

应用程序的价值可以直接衡量。是的，有时它会变得更加复杂，例如，如果应用程序的业务目的是应用程序内购买或推荐，但是有时会赚钱，我们可以将这些钱追溯到应用程序中。

一行代码的成本如何？这只是我们花时间输入的时间吗？这显然是错误的。即使只在脑海中，您也必须进行设计。您必须进行测试。您必须部署它。实际上，一旦您开始考虑，花在一行代码上的钱就没有限制了。如果您的应用程序成功，那么您可能会花费一生的时间来维护这行代码-时不时地查看它，进行调整，更改其使用方式。

当然，大多数代码行都可以正常工作，或者它们永远无法提供足够的价值来使任何人再次为它们烦恼。 （无经济价值=无技术债务）但是，假设您足够了解编写具有价值的应用程序，那么该应用程序中的每一行代码都有潜在的无限成本。

因此，价值来自于应用程序大小的块，而成本与我们用于制作该应用程序的微小部分有关-很大程度上在我们的控制之下。

我们有一种财务方法来处理价值有限但可能受到无限限制的事物。我们使用预算。我下个月可以出去买价值500美元的无糖泡泡糖（我喜欢这种东西），但我不知道。我每月有10美元的预算，而且我坚持执行。那不是因为泡泡糖严重浪费了我们的财务。因为小事加起来。没有预算，我就没有合理的办法让我的妻子和我讨论对我们重要的事情。预算并不重要。关于它所驱动的价值的讨论是不可替代的。

到目前为止，在我们的讨论中，实际上没有理由选择一组预算数字来代替另一组预算数字。我们应该将应用程序限制为一百万行代码吗？一百？我们不知道。我们可以放心地说两件事。一，给定相同的值，更多的代码等于更多的成本。第二，我们对它的戳入越多，代码行总是失控。这就得出了《代码经济学》第三条规则的结论：限制使用编程解决问题的成本的唯一方法是任意限制人们为解决问题而需要进行心理操作的代码数量。

在某种程度上，这是常识。我们已经做了很多年了。我们只是没有明确指出。共享的库，框架，行业标准以及许多其他东西都存在，以限制人们为解决问题而必须进行精神操作的代码量。

那为什么我们没有成功呢？为什么当今大多数程序员不能使用四到五行代码来完成工作？

因为代码行总是随着我们戳的越多而增长。当HTTP协议首次出现时，是否需要网页？您打开了一个终端，并通过telnet输入了少量命令。景气，这是您的网页。现在，很容易就有10到20种不同的标准和库，这些标准和库与过去需要10秒钟的工作有关。从现在开始的五十年中，将有40个标准。相同的值，更多的代码。价值保持不变，代码成本不断增加。

我想提出一个我刚刚制定的完全随机的规则：任意限制用于解决问题的代码行，并编写应用程序，以免再碰它

而且，由于我正在编造东西，所以编写微服务的人的2000-200-20规则怎么样？无论使用微服务必须解决什么问题，您都可以解决20个微服务。每个微服务都可以用不超过200行的唯一代码编写。

但是，等等，我听到你说。那永远都行不通！好的，因此在所有这些微服务中，共享库中可以包含2,000行代码。您可能碰到的任何东西都算作代码。

除了说预算似乎总是武断的，我不会捍卫自己的编造规则，而且创建如此小的预算以至于无法完成工作是不合适的。我不相信我在这里做到了-但我可能错了！如果愿意，可以使用其他预算。地狱，如果我在乎。但是要使用预算。

大多数程序员可能都不认为这样的预算是公平的或可行的。而且我认为很好。这让我着迷，并表明我们在培训和社交程序员方面缺乏一致性。

我还建议必须发生的新事情：代码预算讨论。是的，丹尼尔，您的WhizzBang小部件很棒，但是它使用了500行代码，而这500行我们现在无法负担。

哇！我不想听到有人真的这么说吗！成本控制，在一个编程团队中。想象一下！接下来会发生什么？我不知道！

某些问题不需要很多代码吗？某些应用程序（事实上，大多数应用程序）是否要求我们一次又一次地与他们联系，以使其与不断变化的用户需求保持一致？

两种说法都是正确的。对于复杂的事情，我们编写组件。这些组件具有描述它们的执行测试，并在多个地方使用/共享。他们使用/共享的次数越多，获得的效果越好。这意味着组件只是另一个项目。这也意味着，如果您没有多个团队使用您的组件，那么您就没有一个组件。组件的创建应该是团队之间的决定，并且涉及一个全新的项目。毕竟，它们既具有成本又具有价值。

随着业务需求的变化回来重新调整应用程序怎么样？假设您当前发布的版本具有价值-顺便说一下，这是一个很大的假设-我认为您必须对其进行时间限制。三个月的时间来验证该应用程序是否正确。之后？当然，您编写了一个新应用。有了预算，我们谈论的并不是什么大的努力，您已经生活在这个领域中了，重新思考事情是件好事。代码预算和时间表可以防止“第二系统综合症”。 （我认为我们因第二系统综合症而偏离了轨道，但我离题了）

本文的某些部分是完全编造的。我试图指出这些。还有一些部分是建立在数十年的编码解决方案和观察团队工作经验的基础上的。我一遍又一遍地看到，聪明的人和创造性的约束会发生真正的酷事。否则，确实会发生愚蠢的事情，因为没有限制，这会导致所有自行车脱落。