反向杰文斯悖论

# mht.wtf 来源： https://mht.wtf/post/jevons/ ## 逆向杰文斯悖论 当一种资源的成本下降，但该资源的总支出反而上升时，就出现了杰文斯悖论。听起来总支出应该随着价格下降而下降，但成本的降低使得在相同预算内*使用更多*成为可能，并开启了新的使用类别：那些以前因为资源成本而净收益为负的事物，突然间变成了净收益为正[1](https://mht.wtf/post/jevons/#user-content-fn-sign)。 一个典型的例子是旧车和油价。如果汽油很贵，你会坐公共交通上班，会骑自行车去朋友和家人那里，每天走路去杂货店，这样每次都不至于太重。如果油价下跌，突然就值得开车去各处以节省时间。你可以大宗购物，拜访更远的朋友和家人，甚至可以找一份*通勤距离更长*的新工作，因为这现在在经济上可行了。 杰文斯悖论在编程中也常被引用，无论成本是金钱还是时间。如果你的构建和测试套件非常慢，你可能会在构建*那个*夜间构建时整夜运行它。如果它非常快，就没有必要限制为每天一次，你可以在每次提交时都进行完整的构建和测试套件运行。你甚至可以在提交之前在本地运行，这意味着更多的使用。这不仅仅是加速构建和测试套件，它与夜间构建有着根本性的不同。当然，你的 CI 账单会增加。 这些都是众所周知的，但我意识到这个效应也反向起作用：**如果一种资源的成本*上升*，该资源的总支出可能会下降**。甚至可能一路降到零！我不知道这是否有专门名称，所以我称它为“逆向杰文斯悖论”，尽管它听起来不像常规杰文斯悖论那样矛盾。 假设你负责一个大型软件项目。如果你通过要求多级审查、错综复杂的 Jira 工单、一大群需要签字批准的人以及其他繁文缛节来让修改代码变得困难，你实际上可能会扼杀掉一整类变更，比如“小重构”的 PR。对代码库进行小改动的成本如此之高，以至于对单个开发者来说，做出这样的改动变成了净负收益。它不再值得付出努力，所以他们不再去做。这当然对代码库的健康状况是灾难性的。这也是一种根本性的差异，而不是速率上的边际变化。代码库得不到同样的渐进改进流；即便以更慢的速度也没有，改进干脆完全停止了。 感谢阅读。 1. 如果你支付`$1.00`去按一个按钮，而按按钮会付给你`$0.99`，你会按零次。如果你反而得到`$1.01`，你会一直按。[↩](https://mht.wtf/post/jevons/#user-content-fnref-sign) 本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可 (http://creativecommons.org/licenses/by-sa/4.0/)