当前，对研发人员进行量化的绩效考核，是业界难题。软件用户很难了解程序员的开发工作，而每个程序员个体其实也缺乏全局信息以及对每个人贡献的了解。那么，谁又能来决定价值收益的分配呢？
一种思路是通过提交次数（NOC，Number of Commits）或代码行数（LOC，Line of Commits），比如 GitHub 就是通过提交次数给项目的开发者排名，这种方式操作简单，但是只能衡量代码的数量，无法准确衡量代码价值，而且这个统计方式会被代码的空行、注释、个人习惯等干扰。
另一种思路是使用 OKR 等通用管理工具，对项目和业务结果进行考核，结果导向，缺点是考核方式不够精细、研发过程可见度低、高度依赖团队成员的主观判断。
开源社区价值难以分配
事实上，除了项目创始人和极少数核心开发者可以通过开源项目获得一些利益以外，大部分开发者对于项目的贡献程度难以度量，这导致了开源项目所产生的价值难以分配到这部分人手中，这些利益包括社区获得的捐赠、项目商业化经营所得等。
与歌曲、电影、书籍等发行物的原创作者拥有明确的收益分成比例不同，大部分由团队研发的软件（无论是开源软件还是商业软件）很难将其收益分配给所有参与该软件研发的人员。清华大学计算机科学与技术博士、前微软研究院研究员任晶磊指出，造成这一现状的原因可以用经济学中的两个概念来解释，即信息不对称与契约成本。
如何合理衡量开发者的贡献？
从上世纪八九十年代开始，人们常常用代码行数 LOC 来衡量开发者在一个软件项目中的贡献，这种衡量方式无论在开源社区还是商业公司中都曾被广泛采用，甚至延续至今。
直到2018年，思码逸CEO和CTO在软件工程领域顶级国际学术会议FSE- 软件工程基础国际会议2018上发表了《关于量化代码贡献的开发价值》的论文，测量代码的相对重要性，代表了该领域的最新进展。12月，思码逸CTO在伯克利发表《Quantifying the Development Value of Code Contribution》；通过团队的努力，衡量开发者修改代码的工作量的指标“代码当量”也从此诞生了，与代码行数（LOC）、提交个数（NOC）等简单指标相比，基于抽象语法树（AST）计算的代码当量能更准确地反应修改代码的工作量。
以思码逸Merico研发团队推出的一种新的量化指标“代码当量”为例，“代码当量（ELOC）”可以用来替代 LOC。
ELOC 不是统计源代码层面的信息，而是评估源代码编译成的抽象语法树的复杂度。这样自然避免了源代码中注释、空行、换行等噪音。同时，对代码抽象语法树中的编辑类型、节点类型、函数内重复代码进行了加权计算，能够更加合理地反映代码工作量。
代码当量的基础计算过程如下：
1.分别将修改前的代码和修改后的代码解析为抽象语法树（AST）。
•使用tree diff算法计算将修改前的AST转换成修改后的AST的编辑脚本（Edit Script）。编辑脚本里包括四种对树的编辑操作：插入、删除、移动、更新。
•对于被编辑的抽象语法树节点，根据它的节点类型和编辑操作类型，分别进行加权计算。
•最后，对所有被编辑的节点的加权结果进行求和，即为这次修改的代码当量。
算法图示
下图简单演示了这个过程如何从代码的修改计算出代码当量的数值。
两者实例演示分析对比
代码行数很容易因为简单的修改而显著增加。比如下面的代码变动，尽管代码修改后本质并没有发生变化，这个修改仍会产生1行添加和4行删除。
而单纯的格式变化对AST没有影响，此段代码修改前后AST是相同的，因此其代码当量为0。
代码行数不擅长检测代码块的移动。比如下面的代码变动，简单地交换类中函数的顺序会产生4行添加和4行删除。
但是从抽象语法树的角度，这次修改只是改变了myMethod()函数对应节点在其父节点下的顺序，该节点本身未发生任何修改。因此修改myMethod()的代码当量为0。
代码行数无法区分不同性质的代码的工作量。考察以下Python代码，它的功能是在给定的字典中找到对称对。测试数据test_cript和实际功能函数find_sym_pairs()贡献了相等数量的行数（7行），这当然不能反映编写这两段代码所付出的不同的工作量。
但是通过为每个AST节点类型分配不同的权重，可以对不同类型AST节点的编辑操作进行更合理的评估，更合理的量化开发过程中的工作量。
思码逸Merico通过代码当量等技术度量与分析数据，在评估开发者工作时不再单纯统计代码行数，而是聚合开发过程中的代码交付效率、交付质量、故障恢复时间、交付成本、社区贡献度等可视化数据，帮助企业研发团队客观评估、定位并快速解决研发过程的问题，主要面向企业或开发团队的管理者。
而在开发者侧，他们的产品也能帮助开发者更加客观地复盘自己的开发过程，补足技能树上的短板，同时也能够充分体现个人工作的价值，从一定程度上消除行业“内卷”。
通过这些商业化的尝试，一方面帮助研发团队在实际场景中不断打磨提升技术，另一方面也使量化开发数据逐渐被市场采纳，成为研发日常中的基础设施。