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

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

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

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

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

更新代码覆盖率以行为单位.根据定义,执行的代码通常必须比从未执行的代码更少腐烂.要准确测量bitrot,您需要进行覆盖率分析以充当阻尼器.