为什么我反对用代码当量考核程序员
在不少团队中，“代码当量”仍然被作为工程师绩效或贡献的重要参考指标：
代码行数、提交次数、改动文件数，甚至周报里的新增 LOC。
这些指标看起来客观、可量化、易统计，但作为老开发，我越来越明确地认为：
代码当量无法衡量程序员的真实价值，
甚至会在长期内系统性地伤害工程质量和团队判断。
这不是情绪化的反对，而是基于工程实践与软件工程研究得出的结论。
一、为什么“代码当量”会被反复使用？
先承认一个现实：
代码当量之所以存在，并不是因为它科学，而是因为它省事。
- 不需要理解业务复杂度
- 不需要理解系统架构
- 不需要参与技术决策
- 一个统计脚本就能给出结果
在管理成本和认知成本都很低的情况下，它自然会被采用。
但问题在于：
“好统计”与“衡量得当”，从来不是一回事。
二、代码当量在工程上到底错在哪里？
1. 它把“写代码的行为”等同于“创造价值”
在真实的软件工程中，高价值工作往往意味着：
- 减少重复
- 抽象共性
- 删除冗余
- 重构历史技术债
- 用更少的代码承载更复杂、更稳定的能力
而代码当量考核隐含的前提却是：
写得越多，贡献越大
这会直接产生反向激励：
- 不敢删代码
- 不愿重构
- 抽象和通用能力“性价比低”
- 系统复杂度被不断放大
最终，代码量在增长，
但系统的可维护性和工程质量却在下降。
2. 它对不同工程角色天然不公平
如果以代码行数作为主要衡量标准，那么以下高价值工作会被系统性低估：
- 架构设计
- 性能瓶颈定位
- 线上故障排查
- 公共组件重构
- 技术债清理
越接近系统核心、越承担风险的人，
越难在“代码当量”中表现得好。
这并不是执行问题，而是指标方向本身就错了。
三、量化代码贡献价值的研究，真正想说什么？
在软件工程研究领域，有一项被频繁引用的工作：
Quantifying the Development Value of Code Contributions
这项研究经常被简单理解为“支持量化代码贡献”，
但如果认真阅读，它想表达的恰恰相反。
1️⃣ 它首先明确反对的，就是“代码当量”
研究非常清楚地区分了两个概念：
- Activity（活动量）：发生了多少开发行为
- Value（价值）：这些行为对系统产生了什么影响
代码行数、提交次数、修改文件数，
只能反映 activity，而无法反映 value。
2️⃣ 它真正关心的问题是：代码在系统中的“位置和影响”
这项研究并不关心“谁写了多少代码”，
而是把视角转向了系统本身，提出了一个本质性的问题：
如果删除这段代码，整个系统会损失多少能力？
因此，它强调的不是数量，而是：
- 代码是否处在关键调用路径
- 是否被大量模块依赖
- 是否成为后续功能的基础
- 是否放大了其他开发者的生产力
📌
一个被多个核心模块依赖的十几行代码，
其工程价值，可能远高于上千行局部逻辑。
3️⃣ 它试图纠正的，是“用简单指标评价复杂系统”的习惯
研究本身也非常克制地指出：
- 工程价值高度依赖上下文
- 难以用单一数字精确表达
- 量化只能作为辅助理解，而非自动裁决
换句话说，它不是在提供一个“更高级的考核工具”，
而是在提醒：
任何脱离系统上下文的简单量化指标，
都必然在奖励错误的工程行为。
四、为什么代码当量考核会伤害团队，而不仅是个人？
当一种考核方式长期存在，团队会逐渐“适应”它：
- 工程决策开始服务于指标
- 重构、抽象和清理技术债被视为“收益不高”
- 优秀工程师减少主动承担复杂问题
最终，团队往往得到的是：
- 看起来持续增长的代码量
- 不断上升的维护成本
- 越来越脆弱、难以演进的系统
这是工程能力的退化，而不是效率的提升。
五、作为程序员，我的立场是什么？
我认为，一个负责任的技术负责人，至少应该明确三点：
- 不把代码数量作为绩效核心指标
- 不鼓励用“多写”替代“写对”
- 明确肯定：删代码、降复杂度、本身就是贡献
如果一定要量化，更值得关注的应当是：
- 问题复杂度与风险承担
- 系统稳定性和可维护性的变化
- 技术债是否得到缓解
- 是否让他人的开发工作变得更容易
这些指标也许不够“整齐”，
但方向是正确的。
结语
工程的价值，从来不是“写了多少”，
而是“少了你，这个系统会变成什么样”。
当一种考核方式，需要工程师牺牲系统质量，
才能在指标上表现得更好时，
它考核的已经不是工程能力，而是迎合指标的能力。
反对代码当量考核，并不是反对评估，
而是拒绝用错误的方式评估复杂的工程价值。