Question

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

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

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

更新：我认为维度分析可能只是基于年龄。相对于那更难一点。旧代码很烂。每行代码的平均年龄仍然只是时间的度量。更大的源模块是否比更小，更复杂的源模块更快？

更新代码覆盖率以行数衡量。根据定义，执行的代码通常必须比从未执行的代码更少腐烂。要精确测量bitrot，您需要进行覆盖率分析才能充当阻尼器。

Answer 1

非常有趣的思路！

首先，比特是什么？维基百科上的Software Rot文章收集了几点：

环境变化：运行时的变化
未使用的代码：使用模式的变化
很少更新的代码：通过维护进行更改
重构：一种阻止bitrot的方法

按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源于环境的变化，用户需求的变化和代码的变化，而花费的时间则减少了关于重构。每个组织都必须自己决定如何衡量这些变化，我只给出了非常一般的界限。

Answer 2

我不同意Charlie：源代码的轻微重构会导致非常大的Hamming distances，并且无法很好地衡量代码被逻辑修改的程度。

我会考虑查看提交注释的长度。对于给定的程序员，相对较长的提交注释通常表明他们对代码进行了重大更改。

Answer 3

最简单的答案怎么样？

foreach (file in source control){
  file.RotLevel = (Time.Now - file.LastTestedOrDeployed)
}

如果文件尚未部署（生产或测试机器）很长时间，它可能与“现实”不同步。环境可能已更改，即使文件未更改，它也可能不再起作用。所以在我看来，这是一个简单而准确的公式。为什么要让它更复杂？涉及多个变化似乎只会增加不确定性。如果最近修改了一个文件，是否意味着它已被更新以反映环境的变化（这使其“更少腐烂”），或者添加了新功能（增加了出错的风险，从而使其成为“更腐烂“）？对文件的修改可能意味着什么。

我能想到的唯一明确的因素是“自从我们上次验证文件工作以来有多长时间？”

Answer 4

我想起了Evidence Based Scheduling。提出一组合理的指标来表示bitrot（它的实际值和特定变化减少了多少）。然后根据以后花费的时间确定它们的准确程度。提出这个数字和规则可能很复杂。

Answer 5

显而易见的答案是否定的。 BItrot没有任何可接受的尺寸。

Answer 6

单位测试次数与总代码行的反比例？

Answer 7

考虑两种可能的措施：编辑差异，如汉明或瓦格纳距离;和信息论熵。

Answer 8

如果你真的有兴趣深入研究这个，那里有一些研究。我正在研究一篇文章中的概念，该文章前一段时间研究了Organizational Structure on Software Quality的影响。我最终在脑海中提出了这些想法，但你可能会发现它具有启发性。

Answer 9

由于我们不关心有效的代码，我会查看对文件所做的更改次数（不是更改的大小，文件更改的频率）以及修复了多少错误这些更改加上针对该文件记录的打开错误的数量。结果应该是一个数字越大，文件越腐烂。

经常更改（配置等）而不修复大文件的文件将不会显示，因为等式的错误部分会很低。带有大量开放错误的文件将显示为文件，其中更改通常会导致新的错误。更改*错误修正号应该随着时间的推移而受到侵蚀（因为我们不关心旧的热点）。

Answer 10

代码覆盖和单元测试的唯一问题是单元测试只测试它们最初设计用于测试的内容，并且根据定义，它们是代码，并且容易出现困扰常规代码的相同功能软件。（他们只对他们所写的东西有好处，过了一段时间，这还不够）

但高质量的单元测试显然会提供一些保护。

所以这些是我软件腐败的重要因素：

外部数据接口点数（extDataIntfPts）
- 数据质量/错误处理，单元测试（codeQuality）
- 对OS / VM等底层实现的依赖性。（osDep）
- 外部实现接口点的数量，例如插件。（extIntfPts）
- 代码的复杂性/简单的代码量（linesOfCode）

当一个系统在生产中时，随着它收集的数据集的增长，它会接触到更多种类的数据输入。根据定义，这会将代码库暴露给更多的边缘情况和序列。

这可以通过数据处理，错误处理和单元测试的质量来缓解。

还有系统运行的底层环境的移动目标。缓和此问题的一种方法是将应用程序放入VM中。

如果系统实现了插件，我可以看到随着更多插件的开发，代码库面临更大的失败机会。

复杂的代码！=优雅的代码。如果它很优雅，那可能很简单。我在这里简单地指出，代码越多，测试的可能性就越小，但我认为它可以被转换。

所以，这是我的等式：

bitrot=((linesofcode/codeQuality)*(extDataInfPts+(osDep/change)+extIntfPts)*numberOfSecondsDeployed)

判断codeQuality可能涉及单元测试中代码覆盖率的指标。您可以针对它运行静态分析程序以确定潜在的错误，这也可能是一些帮助。我的意思是，在某些时候，它很难得分，因为多线程代码的权重应该比POJO重得多。是的，应该考虑进行重构，但只有在有证据证明软件腐烂的情况下才会进行重构。

最后，这是一门伪科学。这是我对伪科学的贡献。

Answer 11

真正的bitrot（不是软件腐烂）具有物理存储量*时间的尺寸。

Bitrot是由存储介质中杂质的放射性衰变引起的。

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

11 个答案: