度量代码稳定性的源代码度量标准？

Question

考虑到软件是如何在发布周期(实现、测试、错误修复、发布)期间开发的，我认为应该能够在代码库中看到代码行中的一些变化模式；例如，在项目接近尾声时，如果代码变得更加稳定，应该看到每个时间单位修改的代码行数较少。

例如，人们可以看到，在项目的前六个月，平均每天有200行代码，而在最后一个月，每天有50行代码，而在最后一周(就在产品DVD发布之前)，根本没有更改代码行(代码冻结)。这只是一个例子，根据特定团队采用的开发过程，可能会出现不同的模式。

无论如何，是否有任何代码度量标准(关于它们的任何文献？)使用每单位时间修改的代码行数来度量代码库的稳定性？如果一个项目正在取得进展，或者它还远未准备好发布，它们是否有用呢？是否有任何工具可以从版本控制系统中提取此信息并生成统计信息？

Answer 1

迈克尔·费瑟所描述的一个衡量标准是"活动类集“。

他用那些“封闭”的班级来衡量增加的班级数量。将类闭包描述为：

类在从该日期到现在不再发生进一步修改的日期结束。

他用这些方法创建了这样的图表：

两条线之间的距离越小，越好。

您可以将类似的度量应用于您的代码库。类的数量很可能与代码行数相关。甚至有可能将其扩展到包含每类度量的代码行，这可能会改变图形的形状，如果您有一些大的单块类。

Answer 2

只要有相对一致的特性映射到类，或者文件系统，您就可以将类似葫芦的东西连接到您的版本控制系统中，很快就可以了解大多数开发的重点所在(因此代码的哪些部分是最不稳定的)。

这假设您有一个相对整洁的代码库。如果代码库是一个泥球，那么本质上，您将看到由于相互依赖而正在处理的每个小部分。尽管如此，也许这本身(在处理特性时的集群)是代码基础质量的良好指示。

它还假设您的业务和开发团队作为一个整体在开发中有某种方式分离特性(不管是版本控制中的分支，还是一次一个特性，不管怎样)。例如，如果您在同一分支上处理三个主要特性，则此方法将产生毫无意义的结果，因为您手上的问题比代码稳定性更大。

不幸的是，我没有文献来证明我的观点。它完全基于我在好代码库(而不是很好的代码库)上使用gource的经验。

如果您使用的是git或svn，并且您的gource版本是>= 0.39，那么它就像在项目文件夹中运行gource一样简单。

Answer 3

使用修改行的频率作为代码稳定性的指标至少是值得怀疑的。

首先，随时间分布的修改行，高度依赖于项目的软件管理模型。不同的管理模式有很大的差异。

第二，这个假设中的伤亡还不清楚--是因为软件的稳定性导致修改行的数量减少，还是仅仅因为最后期限到期，开发者决定现在不做一些修改，而是在发布后进行修改？

第三，当引入新功能时，大多数行都会被修改。但是新特性并不会使代码不稳定。这取决于开发人员的技能和设计质量。另一方面，即使是严重的错误也可能通过很少的行修改来修复--在这种情况下，软件的稳定性显著提高，但更改的行数并不太大。