维护的几何模型

# 维护的几何模型 来源：https://entropicthoughts.com/geometric-model-of-maintenance geometric-model-of-maintenance.jpg James Shore提出，编写代码所花费的每"人-月"，在第一年会产生10天的维护工作（https://www.jamesshore.com/v2/blog/2026/you-need-ai-that-reduces-your-maintenance-costs），此后每年还会产生5天。如果按字面理解，这是一个基于*阈值*的维护诱导模型，它之所以有趣，恰恰是因为它极其简单。 如果能证明它是正确的，那将非常有用。Shore关于机器人生成代码影响的论点并不依赖于具体数字，因此他的数字来自一个假设的众智聚合，而非实际数据。但在这里我们不需要任何假设——我们有工具叫git。 ## 验证阈值维护模型（https://entropicthoughts.com/geometric-model-of-maintenance#testing-the-threshold-model-of-maintenance） 假设我们有办法将每次提交标记为"新开发"或"维护"（https://entropicthoughts.com/cheaper-llm-labeling）。那么我们就可以统计每月各类提交的数量。[1] 这篇文章假设必要的维护都得到了执行；如果某项维护没有被执行，那是因为从整体用户的角度来看，它并不是严格*必要*的。我知道很多人会反对这个假设，因为他们认为必要的维护并未被执行，但请暂时放下怀疑。如果某样东西一直没有被修复，你仍然继续使用这款软件，那那样东西对你留下来当用户来说到底有多*必要*？ 或者更好的做法是，统计一个月内处理了多少复杂度（https://entropicthoughts.com/lines-of-code）。[2] 下面的图表展示了从tmux诞生之初到我撰写本文当天，投入到其开发中的累计工作量。 induced-maintenance-demand-01.svg 我们先看黑色曲线，它代表投入到tmux功能开发的工作量。从左到右： - 在仓库建立的第一个月，几乎从一开始就有几千行的功能开发工作。 - 从2008年到2010年，tmux的开发活动相当密集，每年约有30,000行新开发工作量。 - 此后新开发速度放缓，2010年到2026年之间，以相当稳定的节奏每年约8,000行的速度进行。 - 截至今天，tmux在其整个历史中累计约有超过230,000行的新开发工作量。 为了了解在维护上花费了多少工作量，我们对红色曲线做同样的分析。 - 维护在早期落后于新开发，但在2008年到2014年之间大致紧跟新开发的节奏。 - 此后，维护以每年30,000行工作量的速度增长，并持续到2022年。 - 然后又放缓到每年约10,000行。 - 截至今天，tmux累计约需430,000行的维护工作量。 换句话说，在投入tmux的总共约660,000行工作量中，只有大约三分之一用于新开发。这一比例随时间而变化，我们大致可以在项目历史中找到四个阶段。 - 2008–2010年：总工作量每年60,000行。其中约50%是维护。 - 2010–2014年：总工作量每年16,000行。其中约50%是维护。 - 2014–2022年：总工作量每年38,000行。其中约80%是维护。 - 2022–2026年：总工作量每年18,000行。其中约55%是维护。 这并不完全符合阈值模型所预测的维护比例持续上升的趋势。为了确认，我们还应进行目视检查。阈值模型的预测用红色虚线表示。[3] 注意，我们这里并不是用阈值模型来预测维护的*比例*，而是按其原始含义，将其应用于*绝对量*的维护需求。在Shore的原始应用中，他能够通过阈值模型预测维护比例，因为该模型被允许同时确定新开发的速率（通过固定的每月工作速率）。我们没有这样做，因为我们已经拥有tmux项目实际的新开发速率。将一个我们明知不符合事实的假设新开发速率强加给数据是没有意义的。 induced-maintenance-demand-02.svg 从2008年到2022年，简单的阈值模型确实相当准确地预测了tmux所需的维护量。但阈值模型的指数性质意味着它的预测最终会超过实际执行的维护量。[4] 这意味着随着时间推移，模型的拟合效果可能会变差。 阈值模型对某些其他项目的拟合也不太好，通常会高估实际的维护量。例如，截至今天，维护工作占nginx总工作量的63%，但阈值模型认为应该是81%。其他被高估的项目包括Rust、VSCode和Go。 相反，该模型低估了Neovim所需的维护量。Neovim项目从一开始就是维护密集型的，在其整个历史中，83%的工作是维护，但阈值模型认为应该是70%。 然而，阈值模型更普遍的问题在于时机。这一点用Syncthing来说明最合适。 induced-maintenance-demand-03.svg 阈值模型得出的终身维护比例接近正确值（70%对实际的67%），但它完全跟不上实际的维护曲线。 辩护者可能会说，曲线跟不上的原因不是模型错误，而是Syncthing是一个决定提前集中进行大量维护的特例。不幸的是，Syncthing并不是唯一发生这种情况的项目，而且这实际上是阈值模型最大缺陷的症状。在新功能开发保持恒定水平的前提下，阈值模型预测维护会指数增长。[5] 但在我研究过的项目中，实际情况并非如此。 ## 几何模型（https://entropicthoughts.com/geometric-model-of-maintenance#a-geometric-model） 但也许我们可以通过改进模型来挽救它。原始阈值模型说，我今天在新开发上投入的100行工作量，将在直到永远的每一年中至少产生5行维护工作量。这可能不对，部分原因是因为旧代码往往更稳定，但也因为代码会被逐步重写——我今天写的100行代码五年后可能已经不存在了。 我们可以通过对新开发所诱导的维护采用几何衰减来修正阈值模型。如果选择与Shore提出的数字一致的参数，我们可以说维护从工作量的5%开始[6]，每月以3.6%的速度衰减。[7] 然而，这些数字得出的结果与我们已经看到的非常相似：维护曲线仍然无法追踪实际的维护量。 不过，我们可以选择其他数字。例如，如果维护从工作量的4%开始，每月以2.6%的速度衰减，我们得到的维护曲线就能相当好地追踪新开发曲线。这对维护需求较低的nginx效果很好： induced-maintenance-demand-04.svg 对于像tmux这样需要更多维护的项目，同样的数字就不行了。它们产生的曲线低估了所需的维护量。 induced-maintenance-demand-05.svg 我们可以让计算机为tmux选出产生最佳拟合几何曲线的数字。这恰好也是相同的4%初始值，但衰减率为1.4%而非2.6%。图形上如下所示： induced-maintenance-demand-06.svg 如果我们对所有有数据的项目都这样做，就会得到一组差异很大的数字。 | 项目 | 初始维护比例 | 衰减率 | |---|---|---| | nginx | 4% | 2.6% | | tmux | 4% | 1.4% | | Neovim | 20% | 3.8% | | Syncthing | 29% | 14% | | React Native | 7% | 3.2% | | Go | 3% | 0.7% | | VSCode | 48% | 19% | | Rust | 12% | 3.6% | 这些数字并不是为了告诉我们维护产生的因果机制。相反，它们是我们为了让几何曲线紧密追踪每个项目实际维护量而被迫挑选的*恰到好处*的数字。 我们可以用这些数字将维护曲线向前延伸十年，预测即使这些项目完全停止所有新开发，还需要多少维护。下面是nginx的情况。 induced-maintenance-demand-07.svg 该曲线表明nginx已经相当接近其当前的维护饱和点，如果现在冻结所有新开发，剩余的维护工作量很小。与tmux形成对比，将曲线延伸十年后，tmux距离维护曲线趋于平稳还有很长的路要走。 induced-maintenance-demand-08.svg 虽然能够复现项目的维护曲线很巧妙，但我们不应该将这些曲线投射到未来，因为这会让读者觉得这些曲线具有预测性，而实际上它们应该被视为描述性的。但是！这些图表表明，也许有一种更直观的方式来呈现这些数字，让它们对项目做出更易理解的说明。 ## 用几何模型刻画项目（https://entropicthoughts.com/geometric-model-of-maintenance#the-geometric-model-to-characterise-projects） 这里有一种解读几何模型数字的方式。对于一个几何衰减的级数，所有数值之和等于起始值除以衰减因子。在这个场景中，这个和表示相对于新开发工作量的总维护工作量。 | 项目 | 总维护量 | |---|---| | nginx | 1.5× | | Syncthing | 2.0× | | React Native | 2.1× | | VSCode | 2.5× | | tmux | 2.6× | | Rust | 3.2× | | Go | 4.3× | | Neovim | 5.3× | 这*太有意思了*。根据几何模型，在nginx上每小时的新开发工作，在项目的整个生命周期中会产生1.5小时的维护工作。这是这些项目中最低的数字。这可能意味着： - nginx的开发者只接受高质量的代码，因为后续几乎不需要维护，或者 - nginx运行在相当可预测的环境中，很少有假设会出错，因此也很少有假设需要修正。 在这个光谱的另一端可能是像Neovim这样的项目，每小时的新开发在项目整个生命周期中会产生超过五小时的维护工作。Neovim很可能需要适应各种各样的环境和工作流，各种边缘情况都会出现。 这难道已经是一个*非常*有用的拇指规则了吗？现在比如tmux的开发者就知道，每计划一小时的新开发，就需要预算大约2.6小时的维护工作。你也可以为自己的项目做同样的计算！即使你还没有将自己的项目历史拟合到曲线中（或者你根本没有项目历史可拟合），大约3小时看起来处于范围的中间位置，因此你可以假设每小时的新开发对应三小时的维护。 但你应该计划在什么时候进行这些维护？这是我们可以从几何模型中查询的另一个问题。 | 项目 | 消除时间 | |---|---| | Syncthing | 2年 | | VSCode | 2年 | | nginx | 4年 | | React Native | 5年 | | Rust | 6年 | | Neovim | 7年 | | tmux | 8年 | | Go | 13年 | 新开发所产生的维护需求随时间逐渐减少，因为代码中的bug被逐步修复。这张表中的*消除时间*是指一百行新开发工作量对应的维护需求降到每月少于一行所需的时间。 我们可以看出，有些项目相当快就完成了维护（Syncthing、VSCode），而另一些项目则需要更长时间来发现和解决bug（tmux、Go）。平均值为六年。 这就完成了一个规划指南：如果我们启动一个新项目，对于每小时的计划新开发，我们应该预算三小时的维护工作，分摊在六年内，按几何方式衰减。下面是一个方便的表格。 | | 计划的新开发：1天 | 1周 | 1个月 | |---|---|---|---| | 同年维护 | 10小时 | 6天 | 26天 | | 第2年 | 7小时 | 4天 | 18天 | | 第3年 | 5小时 | 3天 | 13天 | | 第4年 | 3小时 | 2天 | 9天 | | 第5年 | 2小时 | 1天 | 6天 | | 第6年 | 2小时 | 1天 | 4天 | 我实际上很惊讶，在这个平均情况下，仅仅与原始新开发同年产生的维护工作量就超过了新开发所需的时间。因此，一个一周的项目实际上不是一个一周的项目——即使只考虑同年内的维护，它也是两周的项目。（如果考虑所有由此产生的维护，它是一个四周的项目。） ## 进一步发展（https://entropicthoughts.com/geometric-model-of-maintenance#further-development） 虽然我确实认为这张表比什么都没有要好——甚至可能比很多人今天在做的要好——但几何模型并不现实。例如，它说一天的新开发和一个月的新开发具有相同的消除时间。它也没有考虑现有代码库的规模；我认为在已经很大的代码库上添加更多功能，应该比在小代码库上添加功能产生更多维护。 另一个困扰我的问题是，单位新开发所产生的总维护量在不同项目之间差异很大，消除时间也是如此。为了用几何模型进行规划，我们实际上应该为每个项目专门拟合这些值，而不是使用这些粗略的平均值。这些平均值恰好适用于Rust、VSCode这样的项目。对于Go、Syncthing、tmux和nginx来说，它们偏悲观。而对于Neovim这样的项目，它们仍然低估了所需的维护量。