有人问我“提高软件质量的最佳指标是什么?” (或类似的)一百万次,此博客文章是一个自私的省时工具,您可能正在阅读本文,因为您问了我一个类似的问题,并且我将您发送到这里。
首先,我不喜欢指标,我认为推荐的软件质量指标中有99%是纯垃圾。 话虽如此,但有一些指标可以帮助与我合作的团队,这些是我将分享的指标。
其次,应该使用指标来推动变化。 我认为,跟踪的指标与跟踪指标的原因明确相关是至关重要的,这样人们就不会只关注数字,而是关注观察数字将带来的好处。
良好的指标#1:为了能够进行重构,而不必担心破坏我们已经建立的内容,我们决定将单元测试的覆盖率提高到> 95%并对其进行测量。 如果不遵守该指标,构建将失败。
良好的指标#2:为了降低代码复杂性,提高可读性并使更改变得更容易,我们设置了一个限制并测量了每种方法的最大大小(15行)和循环复杂性(不记得数字了,但我认为是是<10)。 如果不遵守该指标,构建将失败。
良好的指标#3:为了持续交付低复杂性,易于测试的工作单元并帮助实现可预测性,我们开始测量用户故事从创建到生产的整个周期时间,目标是保持3到5天。 当我们获得了超过5天的用户故事时,我们回顾并检查了原因。
在上述3种情况下,重点是目标,数字是我们认为将推动变化并且可以随时更改的数字。
如果人们不明白为什么要编写单元测试,那么他们将在不保证重构能力的情况下实现单元测试覆盖,例如通过编写没有断言的伪测试。 我们永远不要将度量标准与我们测量某物的原因脱钩。
对我来说,这些是不错的指标。 如果您想看到一些不好的东西,请看我前一段时间写的这篇关于对抗性指标和交付团队的文章,这些文章并没有对他们的客户造成任何伤害。
http://mysoftwarequality.wordpress.com/2012/12/27/the-wrath-of-the-mighty-metric/
翻译自: https://www.javacodegeeks.com/2014/09/some-quality-metrics-that-helped-my-teams.html