写点什么

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

  • 2020-01-13
  • 本文字数:2986 字

    阅读完需:约 10 分钟

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

本文最初发布于 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)在GitPrimeVelocity中都是很突出的功能。代码搅动作为一种指标的失败在于对它的解释不具有一惯性。关于代码搅动是如何进入这个列表的,GitPrime 自己的博文“代码搅动的6个原因以及如何应对”提供了一个极好的参考。GitPrime 列举的原因有:需求不明确、利益相关者犹豫不决、难题、原型设计、优化和参与不足。


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



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


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

小结

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


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


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


查看英文原文


The 4 Worst Software Metrics Agitating Developers in 2019


2020-01-13 15:462730

评论 4 条评论

发布
用户头像
一直欠技术债,一直挖坑让别人填,一直把自家垃圾往别人家扔,是得到外行领导赏识的有效方法。
2020-01-15 14:08
回复
你是华为的吧
2020-01-19 16:49
回复
用户头像
这是个历史难题,如何评价软件开发人员绩效
2020-01-14 10:30
回复
用户头像
应该用解决了什么问题来评估。技术可以有更多的音量,起码要知道为什么要做这个
2020-01-14 09:24
回复
没有更多了
发现更多内容

江苏气象AI算法挑战赛亚军比赛攻略_DontMind队

阿里云天池

阿里云 AI 算法

价值创造未来:财务规划与资源管理

智达方通

企业管理 资源管理 全面预算

Flink物理分区概念与分类详解

木南曌

flink 实时计算

AI 数据观 | TapData Cloud + MongoDB Atlas:大模型与 RAG 技术有机结合,落地实时工单处理智能化解决方案

tapdata

Tapdata Cloud 工单处理 大型语言模型LLM 检索增强技术RAG MongoDB Atlas

苹果挖走大量谷歌人才,建立神秘人工智能实验室;李飞飞创业成立「空间智能」公司丨 RTE 开发者日报 Vol.197

声网

【深入浅出Spring原理及实战】「开发实战系列」重新回顾一下异常重试框架Spring Retry的功能指南和实战

洛神灬殇

spring Spring retry 重试机制 spring-retry

企业选择MES系统是选择现成的OR定制开发?

万界星空科技

生产管理系统 mes 万界星空科技 定制开发MES

品高虚拟化后端存储的发展演进

品高云计算

软件测试学习笔记丨测试用例基础概念

测试人

软件测试

首届云原生编程挑战赛总决赛亚军比赛攻略(ONE PIECE团队)

阿里云天池

Serverless 云原生

【参赛总结】第二届云原生编程挑战赛-冷热读写场景的RocketMQ存储系统设计 - Nico

阿里云天池

RocketMQ 云原生

云原生专栏丨基于K8s集群网络策略的应用访问控制技术

inBuilder低代码平台

云原生 #k8s

MES生产管理系统:私有云、公有云与本地化部署的比较分析

万界星空科技

服务器 云服务 私有云 mes 万界星空科技

Web3 游戏周报(4.28 - 5.04)

Footprint Analytics

gamefi web3

【深入浅出Spring原理及实战】「工作实战专题」叫你如何使用另类操作去实现Spring容器注入Bean对象 (1)

洛神灬殇

Java spring 框架 Bean处理

Partisia Blockchain 生态zk跨链DEX上线,加密资产将无缝转移

股市老人

GreptimeDB 助力国家电网数字换流站打造稳定高效的时序数据底座

Greptime 格睿科技

时序数据库 国产化 智慧电网 国家电网

Xilinx ZYNQ的应用开发介绍

芯动大师

开发板 驱动 ZYNQ

成为一名架构师,你必须具有“战略意图”

快乐非自愿限量之名

架构 软件开发

ETL如何执行Java脚本

RestCloud

Java 脚本 ETL 数据集成工具

一键自动化博客发布工具,用过的人都说好(segmentfault篇)

程序那些事

人工智能 工具 程序那些事 openai 自动化工具

直播预告|第一批 Vision Pro 开发者开始弃坑了吗? 本周六一起听听三位 XR 开发者的真实想法!

声网

【深入浅出Spring原理及实战】「开发实战系列」Spring-Cache扩展自定义(注解失效时间+主动刷新缓存)

洛神灬殇

spring Spring Cache 缓存控制 缓存能力

Partisia Blockchain 生态zk跨链DEX上线,加密资产将无缝转移

BlockChain先知

《自动机理论、语言和计算导论》阅读笔记:p428-p525

codists

编译原理

mybatis使用多参数查询

百度搜索:蓝易云

云计算 Linux 运维 mybatis 云服务器

docker攻略,希望能帮助到大家对docker的理解

阿里云天池

Docker 镜像

Partisia Blockchain 生态首个zk跨链DEX现已上线

石头财经

这些年,我们发展出了多少种愚蠢的“程序员工作成绩”衡量指标?_语言 & 开发_Bill Harding_InfoQ精选文章