本文最初发布于GitClear博客，经原作者授权由InfoQ中文站翻译并分享。

只要有计算机程序员，就会有愚蠢的指标来衡量他们。这篇文章的目的是让2020年少一点愚蠢。今年，我们希望让经理们对技术有足够的理解，使他们能够看到“提交计数”之类的度量指标的不足之处。在编制下面的列表时，我们将重点放在了“2019年在现实世界中经常使用”且“会对开发人员绩效评估带来误导”的指标。

公平地说，在我们将讨论的这些糟糕的指标中，有许多都含有丰富的信号。如果不是因为噪音过多，那么这些指标可能会告诉你一些有趣的事情。对于“代码搅动”这个指标，一个最相近的类比可能是：如果你走进一个房间，里面有25个无线电台在通过一墙的音箱播放节目，那么就有大量的信号！但你能指望从中得到什么呢？大概什么都没有。用于证明决策合理性的数据源越嘈杂，决策的结果就越武断，对公司长期福祉的损害就越大。

第一个指标最简单，也最可悲。

代码行（LoC）

原始代码度量™️……这让我们倒退了几十年。这个指标将一个信号放入了大量的噪音中。更具体地说，根据GitClear对大约100万个开源提交的分析，以下是LoC中一些最严重的污染：

饼图中用到的术语和方法的说明

如上所示，本质上，代码行大约有70%是噪音。更糟糕的是，在开源代码库中，大约30%的提交最终会被丢弃，而不会被合并到主干中，因此，从这些提交得到的任何LoC都会增加噪音。如果LoC本身有30%的信号，考虑到一般的商业库中清洗掉的提交，要将其减少一半，这就意味着这个指标有80%多是噪音。

根据一个80%是噪音的度量指标来做决策听起来很糟糕。但是，LoC还可以更糟糕，因为我们还没有考虑到在实现新特性时LoC会出现尖峰。鼓励快速添加代码会滑向被技术债务搞得一团糟的代码库。更不用提在CSS文件中编写的一行代码与在Java文件中编写的一行代码的工作量有很大的不同。考虑到CSS倾向于产生简短、重复的代码行，一般的开发人员可能在编写一行Java、Python或Ruby代码的时间内可以编写10行CSS。因此，根据LoC指标，“最有价值的开发人员”往往是添加最多CSS、空白和第三方库的人。

由于所有这些原因，在这一大堆最糟糕的开发人员指标中，代码行最突出。虽然深入挖掘，它确实隐藏着一丝信号，但你很难再找到一个被外来噪音污染得更严重的度量指标。

提交计数

与代码行一样，人们在GitHub及其他地方长期将“提交计数”作为一个度量指标来使用很大程度上归功于它相对容易提取。但是，它确实比LoC有优势。首先，它不容易受到噪音的影响，因为这些噪音都是一些琐碎的行更改。它可以解决LoC一半的问题。其次，如果开发人员在2-3天内没有提交，这通常是一个信号，说明他们可能被卡住了。目前为止，一切都还好。

不幸的是，作为软件度量的“提交计数”的实际效用仅此而已。虽然LoC是一个被噪音破坏的信号承载指标，但实际上，提交计数从一开始就没有信号。为什么？因为，从概念上讲，提交只不过是开发人员工作过程中的一个“保存点”。开发人员多久会保存他们的工作？这要看个人喜好。如果你使用“提交计数”作为指标来比较开发人员（正如GitPrime的UI所鼓励的那样），那么你实际上是鼓励他们培养一种个人偏好，在每次编写完一行代码时进行提交。

当然，说这会导致团队开发人员每次更改一行代码都会提交代码，是一种极端的想法。但是，如果开发人员决定每小时提交一次工作，而不管他们从事的是什么工作，又该怎么办呢？有责任心的开发人员会避免这种（完全合乎逻辑的）策略，以避免激怒他们的队友。但你希望让你的开发人员处于这样的位置吗？如果你是一名努力工作的开发人员，正在努力解决尽可能多的Jira问题，如果你知道，通过更频繁地保存工作，你那些懒惰的同事将在提交计数排行榜上超过你，你会作何感想？

如果开发人员知道自己的经理会认真对待这个指标，那么提交计数就会在他们中间制造一种有害的氛围。编程人员可以每小时提交一次，这很容易。不好的激励会导致不好的结果。

拒绝利用这一最具游戏价值的度量指标的开发人员将会不断地离开，不知道他们如何落后于那些不那么细心的同行。

解决的问题，即“交付速度”

这个指标比其他两个指标更有效，因为它关联到一个有意义的输出：在Jira或Github之类的问题跟踪系统中解决的问题。到目前为止一切顺利——至少它度量的是一个有意义的数量。现在，让我们在现实世界中试一下。

如果你比较最近关闭的10个问题中最大和最小的任务，它们之间的实现时间有多大差异？我们先中断一下，让你可以思考一下，检查下自己的数据，从而确认答案，这应该只需要2分钟…

在大多数团队，这个差距可能是10倍或更多。例如，查看我们最近在Jira上解决的十个问题，其中最快的一个需要15分钟。最长的已经持续了两周，目前仍在进行中。如果一个工程师负责的领域多是小型工单（如QA倾向于提交大量的小型用户界面工单），这对于后端开发人员来说就是一个大问题，因为他们需要处理一个为期两周的基础设施修改。UI开发人员是否就因为他们恰好在一个小工单更多的领域而更有价值？当然不是。因此，中短期来看，这个度量指标可以很好地跟踪开发人员设法获得简单工单的程度。

如果我们将“解决的问题”与“故事点”结合起来使用，就可以提高“解决的问题”这个指标的质量，但是这种方法有它自己的缺点。

代码搅动，亦即“效率”

这是这个糟糕的指标集合中最现代化的度量指标。代码搅动（Code churn）在GitPrime和Velocity中都是很突出的功能。代码搅动作为一种指标的失败在于对它的解释不具有一惯性。关于代码搅动是如何进入这个列表的，GitPrime自己的博文“代码搅动的6个原因以及如何应对”提供了一个极好的参考。GitPrime列举的原因有：需求不明确、利益相关者犹豫不决、难题、原型设计、优化和参与不足。

为了阐明每一项的含义，我们把这六个原因画在了一个有坐标的图表上：

那么，当代码搅动变得严重时，你是按下了应急按钮，还是踩下了油门？答案很复杂，因为有很多根本不同的原因导致代码搅动。从上图可以看出，在这些原因里，三个主要源于开发人员的原因看起来实际上都带来了好的结果——也就是说，大多数公司都从早期优化过的原型化产品中获益。“解决难题”通常是朝着一个大胆的目标前进时取得进展的必要条件。

但是，如果代码搅动经常带来积极的结果，那么为什么它的反面“效率”是GitPrime使用的核心指标之一呢？当然，其他三个原因是不受欢迎的。参与不充分、利益相关者犹豫不决和需求不明确将降低生产力。因此，如果我们试图衡量产品经理的工作，“效率”是一个非常有用的度量指标。

小结

如果我们试图度量开发人员的工作，那么最好选择一个不会影响优化代码的度量指标。

考虑到2020年伊始上述指标仍被认为是可行的，这证明管理者仍然有许多机会来改进指标—>激励—>团队所取得的长期成果。值得赞扬的是，促使经理人利用这些指标的直觉是合理的。他们知道，最好的企业利用数据做出最佳决策。但这在很大程度上取决于数据的好坏。当你信任提交计数之类的指标时，可能会比完全不使用数据的情况更糟（例如让两个团队互相竞争）。不管公司的规模有多大，都不要再自欺欺人地认为上面的度量指标可以揭示出有关开发团队工作的一些深刻的东西。

那么，亲爱的读者，你们公司是用什么来衡量你的成绩的呢？欢迎在评论中留言。

查看英文原文：
The 4 Worst Software Metrics Agitating Developers in 2019

创作场景

这些年，我们发展出了多少种愚蠢的“程序员工作成绩”衡量指标？