用于衡量代码稳定性的源代码指标？

考虑到在发行周期（实现，测试，错误修复，发行）中软件的开发方式，我认为人们应该能够看到在代码库中更改过的代码行中的某种模式。例如，在项目结束时，如果代码变得更稳定，则应该看到每单位时间修改的代码行更少。

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

无论如何，是否有任何代码度量标准（有关其文献资料？）使用每单位时间的代码修改行数来衡量代码库的稳定性？如果项目到达某个地方或者距离发布尚很遥远，它们是否对感觉有用？是否有任何工具可以从版本控制系统中提取此信息并生成统计信息？

迈克尔·费瑟（Michael Feather）所描述的一种度量是“ 活动集 ”。

他测量了相对于“封闭”类别增加的类别数量。将类关闭描述为：

从该日期到现在为止，该类的关闭日期尚未发生任何进一步的更改。

他使用这些度量来创建如下图表：

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

您可能可以对您的代码库采取类似的措施。类的数量可能与代码行的数量相关。甚至有可能将其扩展为合并每个类度量的代码行，如果您有一些大型整体类，则可能会改变图形的形状。

只要功能到类的映射相对一致，或者就此而言，文件系统，您就可以将gource之类的东西挂接到版本控制系统中，并很快了解大多数开发的重点（因此代码的哪一部分最不稳定）。

假设您的代码库相对整洁。如果代码库是一团糟，那么由于相互依存关系，您基本上会看到每个小部分都在进行。就是说，也许它本身（使用功能时的聚类）很好地表明了代码库的质量。

它还假定您的业务团队和开发团队总体上具有某种将开发中的功能分开的方法（无论是版本控制中的分支，一次是一个功能，无论如何）。例如，如果您正在同一分支上使用3个主要功能，则此方法将产生无意义的结果，因为与手头的代码稳定性相比，您面临的问题更大。

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

如果您使用的是git或svn，而您的gource版本是> = 0.39，则与在项目文件夹中运行gource一样简单。

使用修改的行的频率作为代码稳定性的指标至少是有问题的。

首先，修改后的生产线随时间的分布在很大程度上取决于项目的软件管理模型。不同的管理模式存在很大差异。

第二，这个假设中的人员伤亡还不清楚-是由于软件的稳定性导致的修改行数减少，还是仅仅是由于截止日期到期而开发人员决定不立即进行某些更改，而是在更改之后进行更改。发布？

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

健壮性是与指令集的正确功能有关的术语，而不是与用于表达这些指令的文本的数量，详细程度，简洁性，语法正确性有关。

确实语法很重要并且必须正确，但是除此以外的任何其他内容，因为它与指令的期望功能有关，通过查看指令的“指标”类似于通过阅读茶叶底部的图案来绘制您的未来。你喝杯茶。

坚固性通过测试来衡量。单元测试，冒烟测试，自动回归测试；测试，测试，测试！

我对您的问题的回答是，您正在使用错误的方法来寻求稳健性之一的答案。这是一条红色的鲱鱼，代码行比代码占用行更有意义。您只有在测试代码是否正在执行您要求的代码时，才能知道代码是否按照您的要求执行。

请重新使用适当的测试工具，并避免代码度量的神秘性。

最好的祝愿。