AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

破解千行代码缺陷率引发的“血案”:研发效能度量是一把标尺吗?

  • 2021-09-02
  • 本文字数:2765 字

    阅读完需:约 9 分钟

破解千行代码缺陷率引发的“血案”:研发效能度量是一把标尺吗?

人们常常认为软件研发度量为管理者提供了一把标尺,可以简单丈量出团队乃至个人的表现,但这个隐喻背后其实包含了对研发效能度量的一些误解。

 

度量分两种,一种是物理度量,一种是统计度量。

 

物理度量追求极致精确,测定目标物理量的接近绝对精确的数值。从秦始皇统一度量衡,到如今普遍使用的激光测距仪,物理学家已经将距离测定推进到了原子级,把质量测定推进到至少 10 的 27 次方分之一克。

 

而统计度量是通过观察样本,对目标统计量做出一种近似但科学的推断。比如,父母希望知道孩子的发育情况,那么可以参考国家儿童体格发育调查报告。其中的度量就是卫生部门对各个年龄和地区儿童的身高、体重进行大范围抽样,计算出他们的分布和均值等统计量。

 

大家经常引用彼得 · 德鲁克的名言,“you can't manage what you can't measure”(你如果无法度量就无法管理),但这里的度量到底是什么样的含义呢?鉴于物理课从初中开始就是主科,而统计学可能是大学里挂科最多的课程之一,大家对度量的朴素理解往往是偏向物理度量的。而当我们建立了上述两类区分,不难看出,管理学里讲的是统计度量——它对所谓“精确”的要求、对结果的解读都与物理度量有本质不同。

 

当我们谈论研发效能度量时,我们谈论的是统计度量——这是一个对正确理解和管理研发效能有很大影响但却常被忽视的基础性认知。管理学中的度量,包括研发效能度量,追求的不是绝对精确,不是在任何情况下没有反例,而是数据中反映出来的共性规律和潜在问题。对统计度量的使用,需要团队和管理者进行更多系统思考。物理度量简单直接,统计度量则需要辅以分析和调研。

从缺陷度量案例讲起


下面我们通过一个案例,具体理解研发效能度量的统计意义和系统思维。腾讯技术专家茹炳晟老师在文章《研发效能度量引发的血案》中举了一个用“千行代码缺陷率”度量代码质量的反例。

 


针对这个案例,我们想做以下几点补充:

 

首先,虽然代码行数和代码质量之间不存在因果性,但这并不会让“度量的大前提”失效,因为相关性足以支撑统计度量的现实意义:我们都希望软件缺陷少,因为缺陷很可能会影响用户使用,阻碍产品的价值实现,带来更多测试和开发成本;而缺陷数量和代码规模相关,所以要想获得对缺陷情况的全面认知,必然会综合考虑两者的关系,否则就会变成“多干多错、少干少错”。

 

其次,从千行代码缺陷率推导出“我们不相信你能够写出高质量的代码”、“我们不鼓励技术提升阶段的阵痛”和“我们欢迎那些平庸的程序员”这些错误价值观的根本原因,是没能理解统计度量固有的灰度。缺乏度量会使效能问题无法被发现,但度量时套用错误的“理工科思维”,试图依赖单一标尺得出精确结论,甚至是削足适履,可能更加危险。团队如果囿于这样的思维,那么换任何其他的度量指标都是枉然。下一节我们会展开阐述系统思维如何破解这里的问题。

 

最后,降低统计度量中的噪音,设计制衡机制,对度量指标的合理使用非常重要。茹老师提到深度代码分析指标“开发当量”,可通过计算抽象语法树(AST)的复杂度来估计工作量,消除源代码级别的噪音干扰(如换行、注释等)。如果没有类似制衡机制,有人就容易抵制不住走捷径的诱惑;反过来说,不能因为担心有人“在错误的地方花费更多时间和精力”而不做制衡,因噎废食。实际上,当与系统博弈的成本大于通过正确行为获益的成本,大家就会被引导到正确的行为上。

系统化破解“血案”


代码简洁、缺陷少、可维护性好的大牛被认为是测试不充分、工作不饱和,在技术提升阵痛期的工程师被批代码质量不高,平庸的工程师反而乐得逍遥——与其说这是指标的原罪,不如说是缺乏系统思维导致的恶果。我们经常担心某些度量指标的“负向牵引作用”,但“负向牵引”是如何产生的呢?

 

让我们用系统思维重新思考一下前面的案例:

 

  • 平平无奇工程师 A 的千行代码缺陷率虽然落在安全范围,但每需求或每故事点代码行数/当量却异常偏高,说明代码规模有冗余;从缺陷停留时间看,一般需要很长时间才能定位并解决问题,维护成本确实偏高;进而从软件工程质量的角度看,A 的代码中可能有大量可复用逻辑没有被抽象,架构上也有优化的空间;从评审环节看,A 的代码要经过的平均评审轮次也可能偏高——综合起来,虽然工程师 A 不一定会被揪着修复缺陷,但可能需要在设计模式或架构设计方面补补课。

  • 大牛工程师 B 的评价涉及对“缺陷”的多维度理解,如果同时参照后续测试中的故障和线上的事故,那么就能说明 B 的代码质量确实过硬,没有理由被责令加强自测;相反,如果缺少数据支撑,碰上不了解情况的领导反而会百口莫辩。

  • 成长中的工程师 C,因为数据呈现出实际的不足,这本身有什么问题呢?团队如果有抵触“技术提升阶段的阵痛”的文化,只一味掩盖或隐藏“阵痛”,又如何能够改善呢?C 的技术追求需要团队的认可与支持,但在代码缺陷率方面的提升空间同样应该暴露出来。这不仅是对团队工作成果负责,也能为 C 的成长提供反馈和指引。

 

在复杂体系的度量中,任何单一指标被过度宽泛地解读、被过度简化地归因、被过度粗暴地使用,都是危险的。而控制这类风险,确保度量的牵引力不跑偏,需要通过系统化设计才能实现。数据扮演了驱动的角色,但需要组织动起来,这正是“数据驱动”软件工程的要义。

研发效能度量的系统方法


为了让软件效能度量在合适的土壤中生根发芽,我们建立了一套 MARI(measure-analyze-review-improve,即度量-分析-调研-改进,读作“码睿”)四步循环方法框架,帮助团队避坑。该方法的系统性不仅体现在多维指标共同构成度量体系,也体现在度量和后续实践的紧密结合。度量如果只止步于数字,就很难避免“为了度量而度量,为了提升而提升”的教条主义。



研发效能的度量和提升实践可以归纳为上图的闭环:从特定的认知需求出发,通过度量获得客观数据,通过分析定位潜在的问题,通过调研挖掘问题本质,通过改进解决问题。这样层层推进,持续循环,获取自反馈,才能让度量有响应、有落地。MARI 方法可以帮助团队体系化地认知研发效能度量,避免简单粗暴地误用。

 

本文阐述了研发效能度量的统计意义和系统思维,分享了我们对这些底层逻辑的理解,以及怎样在完整框架的支持下实现度量的价值落地。后续的几篇内容已经在筹备中,将详细展开具体的度量指标体系和 MARI 实践方法。非常期待与关心研发效能的朋友们多多交流、互相学习!

 

作者介绍:

 

任晶磊,清华大学计算机系博士,前微软亚洲研究院研究员,斯坦福大学、卡内基梅隆大学访问学者;现任思码逸 CEO,通过打造基于深度代码分析技术的研发大数据平台,以数据驱动软件工程,助力企业和开发团队提升研发效能。在程序分析、软件工程领域具备多年前沿研究经验,多篇论文发表在 FSE、OSDI 等顶级国际学术会议上,参与过微软下一代服务器架构的设计与实施,也是一位积极的开源贡献者。近期作为专家组成员参与《软件研发效能度量规范》标准编制。

2021-09-02 18:446386

评论 7 条评论

发布
用户头像
感谢分享,很有收获!
2022-04-12 21:07
回复
用户头像
统计度量固有的灰度
2021-09-06 10:35
回复
用户头像
太理想化,不切实际。之前一篇文章我就吐槽过,这个不想再费口水。还是那句话:程序员是艺术家,你无法给一个艺术家打分,也不需要管理。
2021-09-06 10:07
回复
软件开发是一门工程,也是行业几十年来业已形成的认知。它的艺术性并不妨碍工程性。你看运动员们打球算艺术吧,但联盟选球员不看数据吗?今天运动员们用多少数据分析技术呀
2021-09-07 16:49
回复
少来这里评价运动员,那些都是帮助运动员提升运动水平用的,打球能叫艺术?请问你对艺术了解多少?那要是这样做饭也是艺术,吃饭也是艺术。
请问千行代码故障率能给程序员带来什么价值?试问管理岗有没有衡量管理水平的参数呢?少在这里给人分三六九的价值关美化说辞。如果给人打分有用,就不会有爱因斯坦,如果能给人打分这个世界就不会有爱情。数据分析别用错了地方。
2021-09-08 14:06
回复
又进入了另一方面极端。的确是艺术
2022-01-14 10:31
回复
用户头像
一切不以业务价值作为度量的效能衡量都是耍流氓
2021-09-03 13:58
回复
没有更多了
发现更多内容

模块一

Geek_2ce415

爱番番微前端框架落地实践

百度Geek说

前端

GaussDB(DWS) NOT IN优化技术解密:排他分析场景400倍性能提升

华为云开发者联盟

数据库 GaussDB(DWS) 排他分析 NOT IN

Redis io多线程

C++后台开发

redis 后端开发 Linux服务器开发 C++后台开发 单线程

解锁户外降温黑科技,图拉斯新品发布会完美收官

极客天地

一图详解java-class类文件原理

华为云开发者联盟

Java JVM class 类文件

弱网优化,GCC 动态带宽评估算法(内附详细公式)

融云 RongCloud

通信系统 链路 网络管理

Java中的线程到底有哪些安全策略

华为云开发者联盟

Java 线程 高并发 线程安全 并发容器

钱卫宁:开源是培养数据库人才的关键|OceanBase 数据库大赛访谈

OceanBase 数据库

oceanbase 数据库大赛

CRM系统帮助企业有影响力的营销

低代码小观

CRM 客户关系管理 企业管理系统 CRM系统 客户关系管理系统

英特尔On产业创新峰会:脚踏实地挖掘每一分性能潜能,着眼未来保证PC产业可持续发展

科技新消息

Spring Cloud Alibaba 开源之夏,最后 7 天倒计时

阿里巴巴云原生

阿里云 云原生 spring cloud alibaba 开源之夏

Java中观察者模式与委托,还在傻傻分不清

华为云开发者联盟

Java 观察者模式 委托 事件执行者

2022年第1季度中国网络零售B2C市场交易规模达16988.5亿元

易观分析

网络零售

Jmeter高手进阶-脚本增强

伤心的辣条

Python 程序人生 软件测试 IT 自动化测试

前端工程化之FaaS SSR方案​

百度Geek说

前端

龙蜥开发者说:我的操作系统之路,坚持从实践中来,到实践中去 | 第6期

OpenAnolis小助手

Linux 开源 操作系统 龙蜥社区 龙蜥开发者说

LSM树读写放大问题及KV分离技术解析

移动云大数据

HBase LSM树

最佳实践 | 用腾讯云AI人脸融合实现云毕业照推广活动小程序

牵着蜗牛去散步

腾讯 技术实践 腾讯云AI 人脸融合 云毕业照

宜搭小技巧|海量数据管理难?这招帮你事半功倍

一只大光圈

钉钉宜搭

加盟共享洗车多少钱?投入大吗?

共享电单车厂家

加盟共享洗车 自助洗车加盟费用

互联网出海企业数据库选型问答实录

OceanBase 数据库

云数据库 oceanbase 互联网出海

重磅发布 | Serverless 应用中心:Serverless 应用全生命周期管理平台

阿里巴巴云原生

阿里云 Serverless 云原生 应用中心

为什么越来越多人选择自助式洗车

共享电单车厂家

自助洗车加盟 车白兔自助洗车 自助式洗车

自建Gitlab迁移工具使用指南

阿里云云效

云计算 阿里云 gitlab 代码迁移 代码库

共享自助洗车多少钱一次?怎么收费

共享电单车厂家

自助洗车加盟 自助洗车多少钱一次 共享自助洗车多少钱 自助洗车怎么收费

大前端技术的边界在哪里?

博文视点Broadview

6元自助洗车既能省钱还能赚钱?

共享电单车厂家

自助洗车加盟 6元自助洗车 车白兔自助洗车

开放报名 | Serverless 技术进阶研读班,碎片时间提升技术新方式

阿里巴巴云原生

阿里云 Serverless 云原生 研读版 活动报名

Hoo研究院 | 币圈后浪—PRISM

区块链前沿News

Hoo

密码学系列之:PKI的证书格式表示X.509

程序那些事

Java 密码学 程序那些事 5月月更

破解千行代码缺陷率引发的“血案”:研发效能度量是一把标尺吗?_文化 & 方法_任晶磊_InfoQ精选文章