研发效能度量:破解千行代码缺陷率引发的“血案”

本文主要介绍了研发效能度量的概念和分类,用系统化方法去破解千行代码缺陷率引发的事故,最后提出研发效能度量的系统性方法论

研发效能度量:破解千行代码缺陷率引发的“血案”

本文共计2500字,建议阅读时间:5~6分钟。

阅读本文你将收获:

1、搞清楚度量的概念和分类

2、用系统化破解“血案”

3、研发效能度量的系统方法

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

01 度量的分类和定义

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

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

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

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

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

02 从代码缺陷度量案例讲起

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

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

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

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

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

03 系统化破解“血案”

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

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

  • 平平无奇工程师 A 的千行代码缺陷率虽然落在安全范围,但每需求或每故事点代码行数 / 当量却异常偏高,说明代码规模有冗余;从缺陷停留时间看,一般需要很长时间才能定位并解决问题,维护成本确实偏高;进而从软件工程质量的角度看,A 的代码中可能有大量可复用逻辑没有被抽象,架构上也有优化的空间;从评审环节看,A 的代码要经过的平均评审轮次也可能偏高——综合起来,虽然工程师 A 不一定会被揪着修复缺陷,但可能需要在设计模式或架构设计方面补补课。
  • 大牛工程师 B 的评价涉及对“缺陷”的多维度理解,如果同时参照后续测试中的故障和线上的事故,那么就能说明 B 的代码质量确实过硬,没有理由被责令加强自测;相反,如果缺少数据支撑,碰上不了解情况的领导反而会百口莫辩。
  • 成长中的工程师 C,因为数据呈现出实际的不足,这本身有什么问题呢?团队如果有抵触“技术提升阶段的阵痛”的文化,只一味掩盖或隐藏“阵痛”,又如何能够改善呢?C 的技术追求需要团队的认可与支持,但在代码缺陷率方面的提升空间同样应该暴露出来。这不仅是对团队工作成果负责,也能为 C 的成长提供反馈和指引。

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

04 研发效能度量的系统方法

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

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

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

作者介绍:

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

思码逸 Merico 研发效能分析平台,致力于帮助研发团队解决研发效率、研发质量和人才发展三大痛点,提升研发效率与软件工程质量;

如果您想要与思码逸团队交流,欢迎在网站留下联系方式,我们将在24小时内回复。

与先进研发团队并肩

“软件工程在工业生产中越来越重要。一方面,软件供应链快速演进,软件研发越来越复杂;另一方面,市场的快速变化对研发能力提出各种新的要求。而思码逸作为客观的研发效能平台,立足于对软件开发给出创新性的解释,并尝试将研发效能指标标准化。这对由管理者视角、业务视角、人员视角等更多维度更加全面地看待开发过程有很大帮助。”

Mars Sun

腾讯CODE平台产品负责人

“看清组织研发过程、合理有效地进行研发效能度量是牵引组织研发效能提升的关键。思码逸实现了深入代码语义的AST分析能力,引入代码当量将常规的基于代码行的相关研发效能度量方式提升到了一个新的高度,并通过代码层面的分析提供了研发人员的技术栈相关的标签数据,为组织研发选型提供有力的数据支撑,在行业内有很强的借鉴意义!”

杨永强

原滴滴出行代码团队技术负责人

“相信很多产品技术团队把研发效能提升列为重要的目标。然而,到底什么是好的研发效能,却很少有人能够表达清楚,而代码度量指标种类繁多且相对浅层。如何有效对程序员的工作合理量化测量,思码逸团队围绕每次代码提交对应的抽象语法树的变化进行有效评估,去除了代码中的一些干扰和噪音,为我们提供了新的思路和相对准确的一种测量基础。”

唐洪山

原京东科技研发效能部

“思码逸研发效能平台的专业性令人兴奋,非常适合中国快速发展的互联网软件企业使用。很好的帮助我们解决了团队和项目快速增加过程中遇到的研发效能度量、研发质量规范和人才组织发展的问题。后期的咨询和落地解决方案针对性强,问题分析和解决专业、高效。”

应阔浩

自如基础架构部总监

“在越来越多的企业把数字化转型作为核心战略落地主要抓手的大背景下,思码逸作为基于源代码并扩展至项目管理领域的研发效能平台分析工具,能够为企业数字化转型提供明显助力。和讯网在和思码逸合作共创的2年时间里,2020年主要集中于降本增效领域(提升下限),当年技术部的年度绩效位列全公司第一;2021年主要集中于价值达成领域(提升上限),当年技术部被公司评为年度优秀团队。”

杨扬

和讯网CTO

“开发人员状态有起伏是很正常的。采用思码逸的研发效能度量工具,我们不仅能及时发现表现优秀的开发者并给予激励,也能快速发现工作有待改善的开发者,给他们提供精准的指导与帮助,推动整个团队共同进步。”

朱文雷

长亭科技CTO

“思码逸在代码度量层面给出了创新性的解释,给技术管理者带来全新的研发效能度量提升思路和指标抓手工具,看清团队研发效能的短板,知道该往什么地方提升和改进。结合历史数据、行业数据的比对,让管理者、开发者可以看到努力的成果,并且用数据说话,研发团队日益精进。”

周彦斌

云货优选 研发部门负责人

“研发成果的度量可以说是一个世界性难题,开发者的工作之间内容不同、起点不同、用户不同、代码质量不同,既难以简单量化,也难以横向比较。思码逸作出了一个非常有意义的尝试,它一方面找到了有效的研发效能度量方法,另一方面打通了企业边界来开展数据比较,为研发数字化变革提供了一个非常有意义的新角度。”

谢超平

索贝数码副总裁/总工程师

在数字化的浪潮里,研发效能的高低是企业的核心竞争力。我们面对的产品研发都是脑力工作者,研发效能的度量也变的更复杂和有挑战性。思码逸的深度分析系统,用代码当量来更科学的评估开发的工作量,有效避免人为对代码量的干扰。通过MARI模型产出分析报告,帮助我们在公司内研发效能的推进和落地提供新的思路和方法。

谢超平

王蕾 贝壳工程效率负责人

长期以来,我们一直努力在复杂的市场环境中保持和不断提升研发效率及质量。思码逸为我们提供了重要的量化工具,较传统量化方式更客观和实用。目前思码逸的量化结果已经成为我们评价和提高研发效能的重要组成部分。

谢超平

妙盈科技联合创始人&CTO 刘涛

我们的客户

打开研发管理黑盒,数据驱动研发效能
立即试用
立即预约
在线客服
扫码添加咨询微信
售前电话
在线客服
免费试用
扫码添加咨询微信
长按二维码下载

取消