version-control - bitrot 有任何可接受的尺寸吗？

Question

每个现代源代码控制系统都可以切分程序的历史。有许多工具可以静态和动态地分析代码。什么样的数学公式可以让我将文件中的事件量与该软件的部署数量相结合？我们发现即使一个程序完成了所有的单元测试，它也需要比我们在升级时预期的更多的工作。这种类型的测量应该是可能的，但是坐下来思考它的单位让我难住了。

更新:如果某些东西被发送到测试机器，我可以看到它的标记不那么烂。如果某些东西被发送到所有测试盒，我可以看到它得到一个新的标记。如果有东西投入生产，我可以点头并减少它的bitrot分数。如果它的文件中有很多事件并且它永远不会被发送到任何地方，我就会把它搞砸。不要专注于代码假设我需要的任何数据都在手边。

什么样的提交分析(提交评论(如下所述)或提交之间的时间)是适用的公平数据？

更新:我认为维度分析可能只是基于年龄。相对来说就困难一些了。旧代码很烂。每行代码的平均年龄仍然只是时间的度量。较大的源模块是否比更小、更复杂的源模块腐烂得更快？

更新 代码覆盖率以行来衡量。根据定义，经常执行的代码必须比从未执行的代码更糟糕。要准确测量 bitrot，您需要覆盖分析来充当阻尼器。

Answer 1

非常有趣的思路!

一、什么是 比特腐烂？ Software Rot维基百科上的文章收集了几点:

环境变化:运行时变化

未使用的代码:使用模式的变化

很少更新的代码:通过维护更改

重构:一种阻止比特腐烂的方法

作者 Moore's Law , delta(CPU)/delta(t)是每 18 到 24 个月的常数因子 2。由于环境包含的不仅仅是 CPU，我认为这只是环境实际变化的一个非常弱的下限。单位:OPS/$/s，每秒每美元的操作数随时间的变化
delta(users)/delta(t)很难量化，但从新闻中“知识时代”一词的出现频率来看，我想说用户的期望也呈指数级增长。通过看 $/flops的发展基础经济告诉我们，供给增长快于需求，摩尔定律成为用户变化的上限。我将使用 function points (“信息系统向用户提供的业务功能量”)作为需求的度量。单位:FP/s，所需功能点随时间的变化
delta(maintenance)/delta(t)完全取决于组织，通常在发布前、快速修复和集成重大更改时非常高。各种措施的变化，如 SLOC , Cyclomatic Complexity或者随着时间的推移实现的功能点可以用作这里的替代品。如果可能的话，另一种可能性是票务系统中的错误流失。随着时间的推移，我将继续使用已实现的功能点。单位 = FP/s，实现的功能点随时间的变化
delta(refactoring)/delta(t)可以用花费的时间来衡量 不是 实现新功能。单位 = 1，随着时间的推移重构所花费的时间

所以bitrot会是

             d(env)     d(users)     d(maint)        d(t)
bitrot(t) = -------- * ---------- * ---------- * ----------------
              d(t)        d(t)        d(t)        d(refactoring)

             d(env) * d(users) * d(maint)
          = ------------------------------
                d(t)² * d(refactoring)

与 OPS/$/s * FP/s * FP/s = (OPS*FP²) / ($*s³) 的组合单位.

这当然只是维基百科文章已经说过的非常强制的伪数学符号:bitrot 源于环境的变化、用户需求的变化和代码的变化，而通过花时间重构来缓解它。每个组织都必须自己决定如何衡量这些变化，我只给出非常笼统的界限。